NOTAUTH with external-dns via rfc2136

[CRASH-Tech]

I'm trying get external-dns works via rfc2136, it's strange error. With other DNS servers it wokrs ok.

external-dns logs:

level=info msg="Bad dns.Client.Exchange response: ;; opcode: UPDATE, status: NOTAUTH, id: 36701\n;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0\n\n;; QUESTION SECTION:\n;.\tIN\t SOA\n"
level=error msg="RFC2136 update failed: bad return code: NOTAUTH"

DNS logs:

[2023-10-06 14:01:48 UTC] [10.171.120.201:53167] [UDP] QNAME: ; QTYPE: SOA; QCLASS: IN; RCODE: NotAuth; ANSWER: []

I have created zone, and allow AXFR and dns update for all hosts. Where did I go wrong?

[ShreyasZare]

Thanks for the post. The Not Authoritative (NotAuth) response code is sent by the DNS server only when the zone was not found, or is disabled, or is not of primary type.

Can you confirm if the exact primary zone exists and is enabled?

[CRASH-Tech]

Thanks for the post. The Not Authoritative (NotAuth) response code is sent by the DNS server only when the zone was not found, or is disabled, or is not of primary type.

Can you confirm if the exact primary zone exists and is enabled?

Yes, it's a primary zone, I was try to update with cli tool "nsupdate", and it's work. But external-dns try to get SOA and fail.

[ShreyasZare]

Thanks for the post. The Not Authoritative (NotAuth) response code is sent by the DNS server only when the zone was not found, or is disabled, or is not of primary type. Can you confirm if the exact primary zone exists and is enabled?

Yes, it's a primary zone, I was try to update with cli tool "nsupdate", and it's work. But external-dns try to get SOA and fail.

I replied in haste, apologies. The log entry being made is inadequate to find out the reason for failure. Will update the logging in next release to include more details to help with debugging such cases.

The NotAuth response code can also come due to TSIG auth failure issues. If you can run packet capture then the TSIG error code will indicate the exact issue. Will make sure the next update logs the TSIG error code to avoid running packet capture.

You can also just double check the TSIG key name, shared secret and algorithm configured in the DNS server and the RFC 2136 client.

Let me know if you were able to fix this or if you need help with analyzing the packet capture response.

[CRASH-Tech]

Thanks for the post. The Not Authoritative (NotAuth) response code is sent by the DNS server only when the zone was not found, or is disabled, or is not of primary type. Can you confirm if the exact primary zone exists and is enabled?

Yes, it's a primary zone, I was try to update with cli tool "nsupdate", and it's work. But external-dns try to get SOA and fail.

I replied in haste, apologies. The log entry being made is inadequate to find out the reason for failure. Will update the logging in next release to include more details to help with debugging such cases.

The NotAuth response code can also come due to TSIG auth failure issues. If you can run packet capture then the TSIG error code will indicate the exact issue. Will make sure the next update logs the TSIG error code to avoid running packet capture.

You can also just double check the TSIG key name, shared secret and algorithm configured in the DNS server and the RFC 2136 client.

Let me know if you were able to fix this or if you need help with analyzing the packet capture response.

Hello, there is no difference, with or without TSIG. Zone is exists, and dnsupdate allowed, I have checked it with manual nsupdate - works There is tcpdump

[ShreyasZare]

Hello, there is no difference, with or without TSIG. Zone is exists, and dnsupdate allowed, I have checked it with manual nsupdate - works There is tcpdump

Thanks for the details. Do you have "\<root>" or "xfix.org" zone on the DNS server? If you have "xfix.org" then the response is correct since the DNS server is not authoritative for "\<root>" zone.

[CRASH-Tech]

Thanks for the details. Do you have "" or "xfix.org" zone on the DNS server? If you have "xfix.org" then the response is correct since the DNS server is not authoritative for "" zone.

I have primary zone xfix.org, no 'root' (what is it? :)) powerdns also have only xfix.org zone, and works.

[ShreyasZare]

Thanks for the details. Do you have "" or "xfix.org" zone on the DNS server? If you have "xfix.org" then the response is correct since the DNS server is not authoritative for "" zone.

I have primary zone xfix.org, no 'root' (what is it? :)) powerdns also have only xfix.org zone, and works.

The zone name in the update request (see screenshot below) is supposed to be the domain name of the zone that is to be updated as per RFC 2136.

It seems that either the update client is misconfigured or non-compliant. It seems that powerdns is accepting such requests for some reasons and figuring out which zone the update request is based on the update records which is a non-standard process.

Can you share which update client is being used here?

[CRASH-Tech]

Can you share which update client is being used here?

https://github.com/kubernetes-sigs/external-dns

I see, that message is without correct zone set, I don't know, who needs to be corrected, external-dns, or dns-server

[CRASH-Tech]

May be accept updates with root domain is a good hack for dns server

[ShreyasZare]

Can you share which update client is being used here?

https://github.com/kubernetes-sigs/external-dns

From their page, it looks like the RFC 2136 support they have is "Alpha" which means it is "Community provided with no support from the maintainers apart from reviewing PRs." as it is mentioned.

I see, that message is without correct zone set, I don't know, who needs to be corrected, external-dns, or dns-server

The external-dns implementation needs to be fixed in this case. There is an entire section in RFC 2136 on how to process the update request. The server is supposed to validate if the update records belong to the zone so if the zone is always root then it would always validate.

Its also obviously buggy since there are certain records like NS which can be in both parent and child zone. Lets say you have test.example.com and example.com zones on the same DNS server, and the update request want to add NS record to test.example.com then which zone should the DNS server choose if it has to figure out without the correct zone specified in the request?

I would suggest that you post an issue on the external-dns repo regarding this.

[CRASH-Tech]

Can you share which update client is being used here?

https://github.com/kubernetes-sigs/external-dns

From their page, it looks like the RFC 2136 support they have is "Alpha" which means it is "Community provided with no support from the maintainers apart from reviewing PRs." as it is mentioned.

I see, that message is without correct zone set, I don't know, who needs to be corrected, external-dns, or dns-server

The external-dns implementation needs to be fixed in this case. There is an entire section in RFC 2136 on how to process the update request. The server is supposed to validate if the update records belong to the zone so if the zone is always root then it would always validate.

Its also obviously buggy since there are certain records like NS which can be in both parent and child zone. Lets say you have test.example.com and example.com zones on the same DNS server, and the update request want to add NS record to test.example.com then which zone should the DNS server choose if it has to figure out without the correct zone specified in the request?

I would suggest that you post an issue on the external-dns repo regarding this.

Thank you for reply, I will create issue to external-dns, or maybe PR with fix.