Authoritative check for domain objects seems to cache nameserver response
Dear colleagues, When creating domain objects for reverse DNS delegation of a RIPE assigned inetnum or inet6num, I have observed behaviour where entering a nameserver not authoritative for the in-addr.arpa or ip6.arpa zone results in that nameserver being temporarily unable to be used for delegation. The interface keeps rejecting that particular nameserver for the reason of 'not being authoritative for <zone>', even if the nameserver's configuration has been updated accordingly. What I personally suspect is happening here is that the service on the backend of RIPE NCC's database has sent a DNS request to the specified nameserver, received a response, and cached it. I'm writing this email to ask a couple of questions: Is this intended behaviour? if it is, should it perhaps be changed? and if so, how should changes be implemented? I'm excited to hear back from you, especially as many colleagues within the networking space have expressed frustration from forgetting to configure their nameservers first or misconfiguring them and then having to wait a day or two to re-do the delegation. I had tried my best to search the db-wg list archives for a similar discussion before writing this entry but could find nothing of substance, please forgive me if this has been discussed before and perhaps decided on :) Best, -- Kjartan, AS51019 +354 784-0020 kjh14@hi.is
Hello Kjartan, We use Zonemaster (https://github.com/zonemaster/zonemaster/) to perform the nameserver checks when creating a domain object. The RIPE NCC runs a hosted service to perform these checks. Zonemaster does *not* cache individual DNS queries/responses, but it caches entire test results for 60 seconds. So if you submit the same test within 1 minute, Zonemaster will not perform a new test, but returns results from the previous test. Zonemaster uses the OS resolver for some things, such as hostname to IP address resolution. Other than that, Zonemaster does all its queries directly, without caching. You can also run a test manually: https://zonemaster.ripe.net/domain_check If you make a reconfiguration in a nameserver, this change should then appear in the domain check output. Regards Ed Shryane RIPE NCC
On 28 Jul 2023, at 17:33, Kjartan Hrafnkelsson - HI via db-wg <db-wg@ripe.net> wrote:
Dear colleagues,
When creating domain objects for reverse DNS delegation of a RIPE assigned inetnum or inet6num, I have observed behaviour where entering a nameserver not authoritative for the in-addr.arpa or ip6.arpa zone results in that nameserver being temporarily unable to be used for delegation. The interface keeps rejecting that particular nameserver for the reason of 'not being authoritative for <zone>', even if the nameserver's configuration has been updated accordingly.
What I personally suspect is happening here is that the service on the backend of RIPE NCC's database has sent a DNS request to the specified nameserver, received a response, and cached it.
I'm writing this email to ask a couple of questions: Is this intended behaviour? if it is, should it perhaps be changed? and if so, how should changes be implemented?
I'm excited to hear back from you, especially as many colleagues within the networking space have expressed frustration from forgetting to configure their nameservers first or misconfiguring them and then having to wait a day or two to re-do the delegation. I had tried my best to search the db-wg list archives for a similar discussion before writing this entry but could find nothing of substance, please forgive me if this has been discussed before and perhaps decided on :)
Best, -- Kjartan, AS51019 +354 784-0020 kjh14@hi.is --
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
participants (2)
-
Edward Shryane -
Kjartan Hrafnkelsson - HI