Re: [ncc-services-wg] #107164 - Re: [usersnap][ripe-database] - Syncupdates during "domain" object creation or update check are caching DN[...]
Hello, that doesn't make any sense. In reported case, zone delegation was just missing on authoritative nameserver. After issue was fixed at DNS server, *your* server was still caching *negative* answer and refusing object creation (even zone was created on our nameserver). There's no reason to simulate "client behavior" by caching some results locally (and delay object creation just due to that). Current behavior leads to false-positives during object creation/update and causes misleading error messages for web-updates end-users. DNS servers should be queried always directly while checks are performed during object creation/update to provide accurate (real) data.
From my perspective this is a bug in current implementation of DNS-related checks at NCC side.
With regards, Daniel On 08/02/2018 02:16 PM, RIPE NCC Support wrote:
##- Please type your reply above this line -##
Ticket (107164) has been updated. To add additional comments, reply to this email.
*Anand Buddhdev* (RIPE NCC Support)
Aug 2, 14:16 CEST
Hi Daniel,
Some checks query DNS servers directly, but others use a caching resolver (especially checks that resolve name server names to IP addresses). This simulates the behaviour of a client more accurately. There is no way around this, except to wait for the TTL of the old records to expire, and then you can try to create or update your domain object again.
Regards, Anand Buddhdev RIPE NCC
This email is a service from RIPE NCC Support. [3QKYYW-RE09]
Hello Daniel, Thanks for explaining your case in some more detail. I see now that you're referring to queries for a reverse zone against authoritative name servers. We use Zonemaster as the back-end for performing pre-delegation checks. It *does* query authoritative name servers directly to look up SOA and NS records. However, Zonemaster has a built-in caching window of 5 minutes. If one requests the exact same test of Zonemaster within a 5-minute window, then it does not run the test, but returns the previous result. This is a rate-limiting feature, that avoids overwhelming the Zonemaster server in case someone submits lots of checks to it with the same parameters. We do not consider this to be a bug at all. If you would like to discuss this further, please follow up on the support ticket, without a Cc: to the NCC Services working group. If you would like to discuss this publicly in a working group anyway, then I suggest you do it on the DNS working group mailing list. Regards, Anand Buddhdev RIPE NCC On 02/08/2018 14:45, Daniel Suchy wrote:
Hello, that doesn't make any sense. In reported case, zone delegation was just missing on authoritative nameserver. After issue was fixed at DNS server, *your* server was still caching *negative* answer and refusing object creation (even zone was created on our nameserver).
There's no reason to simulate "client behavior" by caching some results locally (and delay object creation just due to that). Current behavior leads to false-positives during object creation/update and causes misleading error messages for web-updates end-users. DNS servers should be queried always directly while checks are performed during object creation/update to provide accurate (real) data.
From my perspective this is a bug in current implementation of DNS-related checks at NCC side.
With regards, Daniel
On 08/02/2018 02:16 PM, RIPE NCC Support wrote:
##- Please type your reply above this line -##
Ticket (107164) has been updated. To add additional comments, reply to this email.
*Anand Buddhdev* (RIPE NCC Support)
Aug 2, 14:16 CEST
Hi Daniel,
Some checks query DNS servers directly, but others use a caching resolver (especially checks that resolve name server names to IP addresses). This simulates the behaviour of a client more accurately. There is no way around this, except to wait for the TTL of the old records to expire, and then you can try to create or update your domain object again.
Regards, Anand Buddhdev RIPE NCC
This email is a service from RIPE NCC Support. [3QKYYW-RE09]
participants (2)
-
Anand Buddhdev -
Daniel Suchy