feat(provider/cloudflare): add SRV and NAPTR record support

[bayazee]

What does it do?

Fixes SRV record creation/update in the Cloudflare provider (today fails with HTTP 400 / error 9101) and adds NAPTR support.

Cloudflare's API needs structured Data for SRV and NAPTR. Upstream sends the canonical target as flat Content, which CF rejects. This routes both through cloudflare-go's typed batch union members (dns.SRVRecordParam, dns.NAPTRRecordParam for POST; dns.BatchPutSRVRecordParam, dns.BatchPutNAPTRRecordParam for PUT). The records carry structured Data and go through the same batch endpoint as every other record type.

On read-back, cloudflare-go v5.1.0 leaves RecordResponse.Data nil on List (see cloudflare/cloudflare-go#4300). The new srvContent / naptrContent helpers re-decode the raw JSON to recover the structured data, then rebuild the canonical content. The fallback can be revisited when the SDK is upgraded.

Fixes #5551. Refs #4751.

Smoke test

Tested against a real Cloudflare zone, one batch chunk, 6 records (SRV + NAPTR + A + 3 TXT registry records).

Before, on upstream master:

level=warning msg="Batch DNS operation failed ... 400 Bad Request {... 9101,
  \"message\":\"... weight is a required data field.\" ... port is a required
  data field.\" ... target is a required data field.\" ...}, falling back to
  individual operations"
level=error   msg="fallback: individual CREATE failed: ... 9101 ... weight is
  a required data field, port is a required data field, target is a required
  data field" action=CREATE content="10 5 5060 edge..." type=SRV
level=error   msg="Failed to do run once: soft error"

After, this branch:

level=info  msg="Changing record." action=CREATE type=SRV
level=info  msg="Changing record." action=CREATE type=NAPTR
level=info  msg="Changing record." action=CREATE type=A
level=debug msg="Submitting batch DNS records for zone ... (chunk 1/1): 0 deletes, 6 creates, 0 updates"
level=debug msg="Successfully submitted batch DNS records for zone ... (chunk 1/1)"

Re-reconcile (no churn, read-back path holds):

level=info msg="All records are already up to date"

Field changes (SRV port 5060 to 5061, NAPTR preference 20 to 25) and deletion both run through the same batch endpoint with no errors.

dig against 1.1.1.1 returns the expected records:

$ dig +short SRV   _sip._udp.<zone>
10 5 5060 edge.<zone>.
$ dig +short NAPTR <zone>
10 20 "S" "SIP+D2U" "" _sip._udp.<zone>.
$ dig +short A     edge.<zone>
192.0.2.1

Tests

Unit tests cover parsers, typed param builders, batch POST/PUT, chunk-retry, read-back, and end-to-end round-trip via the mock client. Package coverage 94.1%.

endpoint.ValidateNAPTRRecord is out of scope here. Happy to send a follow-up if you want it.

More

• Yes, this PR title follows Conventional Commits
• Yes, I added unit tests
• Yes, I updated end user documentation accordingly

/cc @ivankatliarchuk @mloiseleur

/kind feature
/kind bug

Related, stalled: #4754, #5569.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign szuecs for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

Welcome @bayazee!

It looks like this is your first PR to kubernetes-sigs/external-dns 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/external-dns has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @bayazee. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[ivankatliarchuk]

/ok-to-test

[coveralls]

Coverage Report for CI Build 27699082694

Warning

Build has drifted: This PR's base is out of sync with its target branch, so coverage data may include unrelated changes.
Quick fix: rebase this PR. Learn more →

Coverage increased (+0.8%) to 81.408%

Details

• Coverage increased (+0.8%) from the base build.
• Patch coverage: No coverable lines changed in this PR.
• 582 coverage regressions across 19 files.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

582 previously-covered lines in 19 files lost coverage.

Top 10 Files by Coverage Loss	Lines Losing Coverage	Coverage
traefik_proxy.go	124	67.93%
gateway.go	57	86.9%
gloo_proxy.go	51	74.37%
kong_tcpingress.go	44	50.0%
testutils/endpoint.go	34	56.36%
coredns/coredns.go	32	89.25%
skipper_routegroup.go	30	35.4%
cloudflare/cloudflare_batch.go	29	93.22%
cloudflare/cloudflare.go	26	92.97%
f5_transportserver.go	25	78.0%

---

Coverage Stats

Relevant Lines:	21391
Covered Lines:	17414
Line Coverage:	81.41%
Coverage Strength:	1458.59 hits per line

---

💛 - Coveralls

[mloiseleur]

This assertion is true and can be confirmed with a test like this:

func TestSRVNAPTRConverge(t *testing.T) {
	cases := []struct {
		name       string
		recordType string
		dnsName    string
		target     string
	}{
		{"SRV canonical", "SRV", "_sip._udp.bar.com", "10 5 5060 sip.bar.com."},
		{"SRV multi-space", "SRV", "_sip._udp.bar.com", "10  5  5060  sip.bar.com."},
		{"SRV no trailing dot", "SRV", "_sip._udp.bar.com", "10 5 5060 sip.bar.com"},
		{"NAPTR canonical", "NAPTR", "bar.com", `10 20 "S" "SIP+D2U" "" _sip._udp.bar.com.`},
		{"NAPTR multi-space", "NAPTR", "bar.com", `10  20  "S"  "SIP+D2U"  ""  _sip._udp.bar.com.`},
		{"NAPTR no trailing dot", "NAPTR", "bar.com", `10 20 "S" "SIP+D2U" "" _sip._udp.bar.com`},
	}
	for _, c := range cases {
		t.Run(c.name, func(t *testing.T) {
			updates := planUpdatesForTarget(t, c.recordType, c.dnsName, c.target)
			assert.Zero(t, updates, "record should converge; got %d update(s) on the second reconcile", updates)
		})
	}
}

To me, the root cause is that read-back rebuilds via miekg → single-space canonical; desired target keeps user's spacing . Plan diff never converges → a CF write every reconcile loop.

A possible fix could be in AdjustEndpoints: normalize SRV/NAPTR targets through the same miekg parse so desired == canonical read-back. Then they should actually converge.

Do you think you can fix it ? (and so improve UserXP & remove this part of the doc)

[bayazee]

@mloiseleur You are right and thanks for the test. Fixed in AdjustEndpoints as you suggested. Docs cleaned up. Added some tests.

Verified on a real CF zone. Before the fix and after.

Could you please check it again?