Escaped double quotes of target prevents creation of TXT, NAPTR and CAA records with DNSEndpoint

[jstudler]

What happened: It is not possible to create NAPTR, TXT or CAA records using DNSEndpoint custom resource on both AWS and PowerDNS because double quotes are sent escaped to AWS/PowerDNS. While the API responses in the examples below are based on AWS, the same problem applies to PowerDNS.

What you expected to happen: It should be possible to create NAPTR, TXT or CAA records using the DNSEndpoint CR.

How to reproduce it (as minimally and precisely as possible):

With quotes AWS will return an error because the NAPTR record is not in a RFC 2915 compliant and external dns escaped the quotes.

apiVersion: externaldns.k8s.io/v1alpha1
kind: DNSEndpoint
metadata:
  name: examplednsrecord-naptr
spec:
  endpoints:
  - dnsName: naptr.example.com
    recordTTL: 180
    recordType: NAPTR
    targets:
    - 1 1 "U" "123" "regular" myentry.example.com

Error:

time="2023-10-04T11:45:50Z" level=error msg="Failure in zone example.com. [Id: /hostedzone/____________] when submitting change batch: InvalidChangeBatch: [Invalid Resource Record: 'WARNING problem: NAPTRRRDATARegexpAndReplacementError (NAPTR record can have only one field in regexp and replacement) encountered with '1 1 \"U\" \"123\" \"regular\" myentry.example.com'']\n\tstatus code: 400, request id: ab86ccb1-3484-42f7-b7bc-794805f286c3"

Without quotes AWS will return an error because the NAPTR record is not in a RFC 2915 compliant.

apiVersion: externaldns.k8s.io/v1alpha1
kind: DNSEndpoint
metadata:
  name: examplednsrecord-naptr
spec:
  endpoints:
  - dnsName: naptr.example.com
    recordTTL: 180
    recordType: NAPTR
    targets:
    - 1 1 U 123 regular myentry.example.com

Error:

time="2023-10-04T11:41:20Z" level=error msg="Failure in zone example.com. [Id: /hostedzone/____________] when submitting change batch: InvalidChangeBatch: [Invalid Resource Record: 'FATAL problem: NAPTRRRDATANotValid (Invalid NAPTR record) encountered with '1 1 U 123 regular myentry.example.com'']\n\tstatus code: 400, request id: a1617559-42a9-48da-9f05-fa047f1c4291"

Single quotes are as well not RFC 2915 compliant and don't work with AWS.

apiVersion: externaldns.k8s.io/v1alpha1
kind: DNSEndpoint
metadata:
  name: examplednsrecord-naptr
spec:
  endpoints:
  - dnsName: naptr.example.com
    recordTTL: 180
    recordType: NAPTR
    targets:
    - 1 1 'U' '123' 'regular' myentry.example.com

Error:

time="2023-10-04T11:55:20Z" level=error msg="Failure in zone example.com. [Id: /hostedzone/____________] when submitting change batch: InvalidChangeBatch: [Invalid Resource Record: 'FATAL problem: NAPTRRRDATANotValid (Invalid NAPTR record) encountered with '1 1 'U' '123' 'regular' myentry.example.com'']\n\tstatus code: 400, request id: affb55e8-8706-49e7-bc51-4fabc8a12752"

The same applies to all NAPTR, CAA and TXT records on both AWS and PowerDNS providers. Potentially, other providers are affected as well.

With TXT records, it is probably a different topic since the entire content should be enclosed in double quotes and not only certain fields.

Anything else we need to know?:

Problem: Some records – NAPTR, CAA and TXT – require double quotes for some of the fields. The Kubernetes API JSON returns spec.endpoints.targets as string where double quotes are escaped. The double quotes are sent escaped to the Provider APIs. However, some providers (e.g. PowerDNS or AWS) require RFC-compliant resource record data which means one must add the double quotes to these fields. The current behaviour does not allow creation of TXT, NAPTR or CAA records.

Affected record types:

• NAPTR records require double quotes for the third, fourth and fifth field (https://en.wikipedia.org/wiki/NAPTR_record)
• CAA records require double quotes for the third field (https://en.wikipedia.org/wiki/CAA_record)
• TXT records require double quotes (https://en.wikipedia.org/wiki/TXT_record)

For NAPTR, AWS returns 400 and the following error (without quotes, with single quotes, with double quotes):

Invalid Resource Record: 'FATAL problem: NAPTRRRDATANotValid (Invalid NAPTR record) encountered with '1 1 U 123 regular myentry.example.com''
Invalid Resource Record: 'FATAL problem: NAPTRRRDATANotValid (Invalid NAPTR record) encountered with '1 1 'U' '123' 'regular' myentry.example.com''
Invalid Resource Record: 'WARNING problem: NAPTRRRDATARegexpAndReplacementError (NAPTR record can have only one field in regexp and replacement) encountered with '1 1 \"U\" \"123\" \"regular\" myentry.example.com''

For TXT, AWS returns 400 and the following error:

Invalid Resource Record: 'FATAL problem: InvalidCharacterString (Value should be enclosed in quotation marks) encountered with 'bla bla a.b.c.d.org''

For CAA, AWS returns 400 and the following error:

Invalid Resource Record: 'FATAL problem: CAARRDATAInvalidValue (Invalid value) encountered with 'Value is not inside quotation mark ca.example.net''

Related issues:

• Feature Request: Possibility to create additional (types of) DNS records through CRDs #555
• Make DNSEndpoint CRD GA #2941
• Add support for TXT records through the DNSEndpoint resource #2936

Environment:

• External-DNS version (use external-dns --version): v0.13.6
• DNS provider: aws / pdns

[jstudler]

Hey @ffledgling @jhoch-palantir @ottoyiu @tariq1890 @Raffo @anandsinghkunwar @matusf
Question to you since you contributed to the PowerDNS provider: Would you encourage fixing this in the pdns provider so ExternalDNS with PowerDNS supports NAPTR? If you support that this is being implemented in the provider, I can look into the implementation.

[anhadjaisingh]

Heyo @jstudler I no longer have access to @ffledgling (Github 2FAC lockout) and I haven't actively used this setup in over 4 years, so I'm not really the best person to fix this anymore. You might want to find someone who still uses this setup, I think @jhoch-palantir no longer does, @anandsinghkunwar might?

That said, if my memory serves correctly, this just looks like a serialization/deserialization issue along the long chain from YAML -> Materialized Spec -> Kubernetes Scheduler -> external-dns -> powerdns-provider -> powerDNS. I feel like I ran into this issue with CNAME records as well. Getting it right is somewhat tricky and fixing it for just one family of records might break it for the rest unless handled with care.

If you feel up to it, please submit a code-fix and one of the maintainers of the parent external-dns repo can help get this merged.

[anandsinghkunwar]

Hey @jstudler, I don't look into this setup anymore. As @anhadjaisingh pointed out perhaps one of the core maintainers of the repo can get your PR merged if you're up for it.

[jstudler]

Hey @anhadjaisingh & @anandsinghkunwar,
Thanks for your replies. I will look into it and try to propose a fix in the upcoming months.

[jstudler]

Update: It seems that External DNS prevents trailing dots in a RR target (https://github.com/kubernetes-sigs/external-dns/blob/master/source/crd.go#L191-L201) while the NAPTR RFC requires it (https://datatracker.ietf.org/doc/html/rfc2915). So by removing the trailing dot in the CR (see issue description above), External DNS would not refuse the endpoint anymore but then it would also not be RFC compliant anymore.

#4212 fixes the issue

[hobti01]

Just to confirm: CAA record creation for AWS was not implemented? (I see no PRs with CAA creation) and no const for CAA in

external-dns/endpoint/endpoint.go

Line 30 in 1ceaf79

const (

From what I can tell:

• NAPTR for PowerDNS is fixed in Fixing NAPTR support #4212
• Quotes in the value should "just work" therefore CAA should "just work"? I recall attempting this without success but no longer have the config or messages.

[jstudler]

Yes, I think CAA records should work – at least in the context of the PR you referenced. The description of this issue here is not accurate because some of the PowerDNS/ExternalDNS log messages led to a false conclusion that the quotes would be the issue. The problem for this issue was actually that ExternalDNS prevented a trailing dot for all records which is a must for NAPTR. So if CAA record creation does not work, it's likely a different underlying problem.