EOL of 'Name-Related Data Fields on SRV (DNS) Records' is not applying

Hello, the SRV records I’m creating still requires me to specify ‘service’, ‘proto’ and ‘name’ in the data map, resulting in inconsistent of my Terraform scripts. Am I missing something here?

API deprecations · Cloudflare Fundamentals docs

The SRV records I manually created on Cloudflare web console, then I observe the network response from browser’s developer console (F12), the response also come with the ‘service’, ‘proto’ and ‘name’ in the data map, which these values do not present in another account.

Both SRV records are created manually on web console.

Hi @yanjinnloh!

You may be seeing differences in behavior across zones because this change is being rolled out on a per-zone basis until June 17, 08:00 UTC. However, creating SRV records using the new method (“name” field outside of the data map) should work correctly on all zones.

still requires me to specify ‘service’, ‘proto’ and ‘name’ in the data map

Could you elaborate on what happens if you omit these and instead send only the “name” outside of the data map? It should’ve been quite a while since any of these fields were required. The UI also does not send them anymore.

Zones to which this change has not yet been rolled out yet (i.e., that still support these data fields in request bodies as an alternative to the “name” field outside of the data map) will also still send these three data fields in response bodies. As the rollout progresses, those fields should disappear. Is that the inconsistent behavior you’re referring to?

Hi @janik1

The inconsistent part is about my Terraform scripts, with the new behavior, these data fields must not be passed in as I will be getting an error on Account 2:

Error: failed to create DNS record: SRV data fields 'service', 'proto' and 'name' are no longer supported. Please see <https://developers.cloudflare.com/fundamentals/api/reference/deprecations/#name-related-data-fields-on-srv-dns-records> for more information. (9000)

Then I proceed to remove these data fields in my Terraform scripts, but the moment I run the scripts to config on Account 1, it shows another error:

DNS Validation Error (Code: 1004).

It’s kind of confusing me about seeing two different behaviors here.

That shouldn’t happen!

A “DNS Validation Error” should always come with another error wrapped inside of it; is there any other message being shown?

Are you sure that the “name” field outside the data map (the same field that’s also used by non-SRV records) is set correctly? For example:

resource "cloudflare_record" "_sip_tls" {
  zone_id = var.cloudflare_zone_id
  name    = "_sip._tls.example.com" // <-- this needs to be set
  type    = "SRV"

  data {
    // ...
  }
}

Yes, I have my Terraform code as below:

resource "cloudflare_record" "test" {
  zone_id = data.cloudflare_zones.zone.zones.0.id
  name    = "_kerberos._tcp.${var.domain}"
  type    = "SRV"

  data {
    # service  = "_kerberos"
    # proto    = "_tcp"
    # name     = var.domain
    priority = 0
    weight   = 100
    port     = 88
    target   = local.host_name
  }
}

After that, I tried uncommenting those data fields and it run successfully.

Hi @janik1

Ignoring the Terraform issue at the moment,

this change is being rolled out on a per-zone basis until June 17, 08:00 UTC.

Is all I can do now just wait for the changes to apply on my account and zones?

Hi @yanjinnloh,

Thanks for the report. As it turns out, there’s an issue with the Terraform provider, where it sends all data fields to the API, even when they’re not actually set. This is causing the API to fail because the name built from the (now empty) data fields (i.e., an empty name) is invalid.

We’re aborting the rollout for now until this issue has been worked around.

  • The old configuration (deprecated fields present) should now be working again on all zones.
  • The preferred configuration (“name” outside of the data map set, all 3 deprecated data fields removed) should start working very soon (early next week at the latest) and continue to work from that point onward even as the rollout is restarted.

Sorry about that and thanks again for letting us know!

4 Likes

I am able to see the deprecated fields are appearing again on my Account 2 as the rollback going on.
Thank you for your help!

1 Like

Hi everyone, just a quick update: we’ve worked around the Terraform issue and removing the deprecated data fields now works as expected. We’re planning to restart the rollout soon, so please make sure your SRV records do have a name but don’t have any of the three deprecated data fields set. Here’s what that should look like:

resource "cloudflare_record" "example" {
  zone_id = var.zone_id
  name    = "_someservice._someproto.example.com"
  type    = "SRV"

  data {
    priority = 1
    weight   = 2
    port     = 3
    target   = "target.example.com"
  }
}

More information here. Thanks everyone!

Note: If Terraform continuously tries to remove these data fields again and again (since the API still sends them for zones to which this change hasn’t been rolled out yet), this can be worked around by continuing to set the deprecated data fields while ensuring they match the new name field. In that case, no error will be reported, even after the rollout. (Alternatively, these diffs can simply be ignored until the rollout completes in late July.)

2 Likes

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.