feat(aws): enable support for NAPTR records

[alexbakker-quandago]

What does it do ?

Since ef62107, it is now possible to enable support for NAPTR records in the AWS provider. This patch does so and adds some tests for it.

Closes #5003

Motivation

We'd like to be able to create NAPTR records in Route53 using external-dns.

More

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

[linux-foundation-easycla[bot]]

The committers listed above are authorized under a signed CLA.

• :white_check_mark: login: woltere / name: Wolter Eldering (28d47dcfe79540bae6cf0052ecc51ba8235369c2)

[k8s-ci-robot]

Welcome @alexbakker-quandago!

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. :smiley:

[k8s-ci-robot]

Hi @alexbakker-quandago. Thanks for your PR.

I'm waiting for a github.com 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.

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]

Could you share similar results for this PR #5085 (comment). Need to make sure it works.

[ivankatliarchuk]

/ok-to-test

[ivankatliarchuk]

I'm not too sure actually about this PR. Extnernal-dns and AWS supports NAPTR records https://github.com/kubernetes-sigs/external-dns/issues/5003

On hold as missing evidences that currently not working.

/hold

[coveralls]

Pull Request Test Coverage Report for Build 20173145831

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 78.688%

---

Totals
Change from base Build 20163464704:	0.0%
Covered Lines:	16013
Relevant Lines:	20350

---

💛 - Coveralls

[ivankatliarchuk]

I dig a bit more in details of issue 5003. Current PR in description does not match the problem explained in the issue. So this need to be addressed first.

[alexbakker-quandago]

Without this patch you'll run into the problem reported in #5003. As described there, initial creation of the NAPTR record succeeds, but on subsequent passes you'll keep getting the following error:

time="2025-12-13T11:04:59Z" level=debug msg="Desired change: CREATE REDACTED NAPTR" profile=default zoneID=/hostedzone/REDACTED zoneName=REDACTED.
time="2025-12-13T11:04:59Z" level=error msg="Failed submitting change (error: operation error Route 53: ChangeResourceRecordSets, https response error StatusCode: 400, RequestID: REDACTED, InvalidChangeBatch: [Tried to create resource record set [name='REDACTED.', type='NAPTR'] but it already exists]), it will be retried in a separate change batch in the next iteration" profile=default zoneID=/hostedzone/REDACTED zoneName=REDACTED.

[ivankatliarchuk]

I’m not denying the issue. What’s mainly missing are the configuration manifests and steps to easily reproduce it, along with evidence that the fix actually works. It’s not that I don’t trust the unit tests, but we do need some form of smoke testing to confirm the behaviour and to ensure we can reproduce it on our side when needed. Also, the title and description are a bit misleading.

[alexbakker-quandago]

Sure, no problem. #5003 already describes steps to reproduce, but here's a more precise version:

• Start external-dns with the following arguments:

  --log-level=debug
  --log-format=text
  --interval=1m
  --source=service
  --source=ingress
  --source=crd
  --policy=sync
  --registry=txt
  --txt-owner-id=some-owner
  --txt-prefix=extdns-%{record_type}-
  --domain-filter=your-zone.example.com
  --provider=aws
  --zone-id-filter=REDACTED
  --managed-record-types=A
  --managed-record-types=AAAA
  --managed-record-types=CNAME
  --managed-record-types=NAPTR
  --managed-record-types=SRV
  --aws-zone-match-parent
  --aws-assume-role=arn:aws:iam::REDACTED:role/REDACTED
  

• Create a DNSEndpoint with an NAPTR record. For example:

  apiVersion: externaldns.k8s.io/v1alpha1
  kind: DNSEndpoint
  metadata:
    name: test-naptr
    namespace: default
  spec:
    endpoints:
    - dnsName: test.your-zone.example.com
      recordTTL: 180
      recordType: NAPTR
      targets:
      - 50 50 "S" "SIPS+D2T" "" _sips._tcp.test.your-zone.example.com.
      - 100 50 "S" "SIP+D2U" "" _sip._udp.test.your-zone.example.com.
  

• Watch external-dns create the record
• On the next passes, look for errors similar to:

  time="2025-12-13T11:04:59Z" level=debug msg="Desired change: CREATE REDACTED NAPTR" profile=default zoneID=/hostedzone/REDACTED zoneName=REDACTED.
  time="2025-12-13T11:04:59Z" level=error msg="Failed submitting change (error: operation error Route 53: ChangeResourceRecordSets, https response error StatusCode: 400, RequestID: REDACTED, InvalidChangeBatch: [Tried to create resource record set [name='REDACTED.', type='NAPTR'] but it already exists]), it will be retried in a separate change batch in the next iteration" profile=default zoneID=/hostedzone/REDACTED zoneName=REDACTED.
  

Regarding the title and description: They're formulated like this because NAPTR support in the AWS provider seemed so broken before ef621078c2b9ea9fa6f26e3446e9cf4507ea8176 and this patch, that I didn't expect anyone to be using it. After this patch, NAPTR support becomes usable, hence why I called it "enabling" NAPTR support. I'm happy to change it if you have a suggestion for a more fitting title though.

[ivankatliarchuk]

/unhold

[ivankatliarchuk]

Most likely in follow-up worth to add endpoint validation for this record type https://github.com/kubernetes-sigs/external-dns/blob/0d6c5e25359c661a075297807270ff37b748a417/endpoint/endpoint.go#L427

[alexbakker-quandago]

Just to make sure I understand correctly: You'd like me to do that in a follow-up pull request?

[ivankatliarchuk]

Probably make sense to do it in another PR.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mloiseleur

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

The pull request process is described here

Needs approval from an approver in each of these files:

• ~~OWNERS~~ [mloiseleur]

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