Creating SRV record with content string instead of individual component fields

Developers API
1

For Workers & Pages, what is the name of the domain?

What is the error number?

9101

What is the error message?

[{Code:9101 Message:weight is a required data field. ErrorChain:} {Code:9101 Message:port is a required data field. ErrorChain:} {Code:9101 Message:target is a required data field. ErrorChain:}]

What is the issue or error you’re encountering

I’m trying to use the API to create SRV records with the content field, rather than individual data components. The docs and the API seem to be in disagreement.

What steps have you taken to resolve the issue?

I have tried referring to the documentation, which suggests I should be able to do this: Cloudflare API | DNS › Records › SRVRecord

content: string Optional
Priority, weight, port, and SRV target. See ‘data’ for setting the individual component values.

And all the fields for ‘data’ say optional as well. (See screenshot)

What are the steps to reproduce the issue?

This command, with API token and domain replaced:

$ curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records" \n
--header "Authorization: Bearer $API_TOKEN"
--header "Content-Type: application/json"
--data '{"type": "SRV", "name": "_service._tcp.example.com", "content": "1 5 25565 example.com", "ttl": 120}'

gives the above error, indicating that individual components are required, but for simplicity in my code I just want to use the content string. It is already formatted like Cloudflare expects for SRV records.

It seems like the documentation is wrong, or the API is erroneously requiring the optional fields. But something isn’t right either way.

Screenshot of the error

Screenshot From 2025-03-20 07-49-50.png
Screenshot From 2025-03-20 07-49-50.png854×392 44.1 KB

2

For the SRV type of the DNS records, the Name, Priority, Weight, Port and Target fields are required. Have you tried adding them?

Obviously as it seems. Thank you for notice. We’ll ping the Developers to review and update this as soon as possible.

A bit confussing is if you’re doing SVCB per RFC, otherwise trying the SRV type.

Below one works fine for me:

curl -X POST "https://api.cloudflare.com/client/v4/zones/MY_ZONE/dns_records" \
     -H "X-Auth-Email: MY_EMAIL" \
     -H "X-Auth-Key: MY_API_KEY" \
     -H "Content-Type: application/json" \
     --data '{
       "type": "SRV",
       "name": "_test._tcp.mydomain.hr",
       "ttl": 1234,
       "data": {
         "priority": 10,
         "weight": 10,
         "port": 12345,
         "target": "provider.com"
       }
     }'

Could be confussing the part “data” inside “data” as JSON body while sending it via cURL or Postman, otherwise some other language you’re using.

I am not sure about this one :thinking:

For an SRV record, Cloudflare does not use the content field. Instead, we must use the data field to specify properties like priority, weight, port, and target. This is how SRV records are structured.

Despite we do see content field when we list DNS records and filter by the SRV type via API.

{
  "result": [
    {
      "id": "ID",
      "name": "_autodiscover._tcp.domain.hr",
      "type": "SRV",
      "content": "0 443 cpanelemaildiscovery.cpanel.net",
      "priority": 0,
      "proxiable": false,
      "proxied": false,
      "ttl": 1,
      "data": {
        "port": 443,
        "priority": 0,
        "target": "cpanelemaildiscovery.cpanel.net",
        "weight": 0
      },
      "settings": {},
      "meta": {},
      "comment": null,
      "tags": [],
      "created_on": "DATE",
      "modified_on": "DATE"
    },
  ]
    ...
    ,
    "success":true,
    "errors":[],
    "messages":[],
    "result_info": {
        "page":1,
        "per_page":100,
        "count":X,
        "total_count":X,
        "total_pages":1
    }
}

For SRV records, we need to use the data field instead of content. This is because SRV records in DNS have multiple properties (priority, weight, port, and target) that must be specified in a structured way, which is done via the data field. However, when we create or update SRV records, we must provide these attributes separately in the data field, not as a single string in content.

Could be I am wrong.

Let’s see if we could get some reply from someone at :orange: in the meantime with more feedback and correction why is it like that, if so.

1 Like
4

Thanks for the reply!

Well, yes; I know that works… but it involves me having to parse a string into its components, which is tedious and error-prone, and adds complexity to the code. Why deserialize, then reserialize (then have Cloudflare deserialize, and reserialize again!) the values, when we can just pass the content string around?

That is a bit confusing that it is in the documentation then.

(I know you are not the person who has power to fix this, so the following complaint isn’t directed toward you. :slight_smile: ) It’s quite frustrating that this DNS API, which documents the use for a content field, does not actually accept it, especially when DNS zone files represent all the structured data as opaque strings at the end of the day.

Thank you. I appreciate that you verified that something is amiss. My hope is that the API functionality can be fixed to reflect the abilities described by the documentation. It would be great if content could actually be used, so help keep code simple and reduce errors.

2 Likes
5

@fritex Did you hear back from the dev team at all about whether/when they’ll fix the API?

1 Like
6

also struggling with this one too, but my issue is with keeping the state in sync and not executing changes. i can’t define both the content/data fields in hcl but the plan always returns both.