This is what I see with diagnostics turned up:

$ dig +bufsize=16384 +cd +dnssec shopdisney.co.uk @test-resolver
....
shopdisney.co.uk.       0       IN      TXT     "shopdisney.co.uk 
categorization: None"
shopdisney.co.uk.       0       IN      TXT     "cache_get shopdisney.co.uk/A: 
ttl=0 cache_flags=0x0 (NOTFOUND)"
shopdisney.co.uk.       0       IN      TXT     "cache_get shopdisney.co.uk/NS: 
prefixlen=0 ttl=87746 cache_flags=0x1 (HAVEDATA)"
shopdisney.co.uk.       0       IN      TXT     "RESOLVER: shopdisney.co.uk IN 
NS ns1.disneyinternational.net"
shopdisney.co.uk.       0       IN      TXT     "RESOLVER: shopdisney.co.uk IN 
NS ns2.disneyinternational.net"
shopdisney.co.uk.       0       IN      TXT     "RESOLVER: shopdisney.co.uk IN 
NS ns3.disneyinternational.net"
shopdisney.co.uk.       0       IN      TXT     "RESOLVER: shopdisney.co.uk IN 
NS ns4.disneyinternational.net"
shopdisney.co.uk.       0       IN      TXT     "cache_get 
ns3.disneyinternational.net/A: prefixlen=0 ttl=27772 cache_flags=0x1 (HAVEDATA)"
shopdisney.co.uk.       0       IN      TXT     "cache_get 
ns3.disneyinternational.net/AAAA: prefixlen=0 ttl=27772 cache_flags=0x1 
(HAVEDATA)"
shopdisney.co.uk.       0       IN      TXT     "cache_get 
ns4.disneyinternational.net/A: prefixlen=0 ttl=27772 cache_flags=0x1 (HAVEDATA)"
shopdisney.co.uk.       0       IN      TXT     "cache_get 
ns4.disneyinternational.net/AAAA: ttl=0 cache_flags=0x0 (NOTFOUND)"
shopdisney.co.uk.       0       IN      TXT     "cache_get 
ns1.disneyinternational.net/A: prefixlen=0 ttl=27772 cache_flags=0x1 (HAVEDATA)"
shopdisney.co.uk.       0       IN      TXT     "cache_get 
ns1.disneyinternational.net/AAAA: prefixlen=0 ttl=27772 cache_flags=0x1 
(HAVEDATA)"
shopdisney.co.uk.       0       IN      TXT     "cache_get 
ns2.disneyinternational.net/A: prefixlen=0 ttl=27772 cache_flags=0x2241 
(HAVEDATA)"
shopdisney.co.uk.       0       IN      TXT     "cache_get 
ns2.disneyinternational.net/AAAA: ttl=0 cache_flags=0x0 (NOTFOUND)"
shopdisney.co.uk.       0       IN      TXT     "tx shopdisney.co.uk/A 
clientsubnet=enabled zone=shopdisney.co.uk level=0"
shopdisney.co.uk.       0       IN      TXT     "Sending EDNS0 with bufsize 
1410 and the DO bit"
shopdisney.co.uk.       0       IN      TXT     "Sending 45 bytes to 
[2001:500:94:1::144]:53 using UDP, timeout 350ms"
shopdisney.co.uk.       0       IN      TXT     "Received EDNS0 with bufsize 
4096 and the DO bit"
shopdisney.co.uk.       0       IN      TXT     "AUTH server 2001:500:94:1::144 
returned REFUSED - abandoned"
shopdisney.co.uk.       0       IN      TXT     "Sending EDNS0 with bufsize 
1410 and the DO bit"
shopdisney.co.uk.       0       IN      TXT     "Sending 45 bytes to 
208.78.70.144:53 using UDP, timeout 350ms"
shopdisney.co.uk.       0       IN      TXT     "Received EDNS0 with bufsize 
4096 and the DO bit"
shopdisney.co.uk.       0       IN      TXT     "AUTH server 208.78.70.144 
returned REFUSED - abandoned"
shopdisney.co.uk.       0       IN      TXT     "Sending EDNS0 with bufsize 
1410 and the DO bit"
shopdisney.co.uk.       0       IN      TXT     "Sending 45 bytes to 
204.13.250.144:53 using UDP, timeout 350ms"
shopdisney.co.uk.       0       IN      TXT     "Received EDNS0 with bufsize 
4096 and the DO bit"
shopdisney.co.uk.       0       IN      TXT     "AUTH server 204.13.250.144 
returned REFUSED - abandoned"
shopdisney.co.uk.       0       IN      TXT     "Sending EDNS0 with bufsize 
1410 and the DO bit"
shopdisney.co.uk.       0       IN      TXT     "Sending 45 bytes to 
[2001:500:90:1::144]:53 using UDP, timeout 350ms"
shopdisney.co.uk.       0       IN      TXT     "Received EDNS0 with bufsize 
4096 and the DO bit"
shopdisney.co.uk.       0       IN      TXT     "AUTH server 2001:500:90:1::144 
returned REFUSED - abandoned"
shopdisney.co.uk.       0       IN      TXT     "Sending EDNS0 with bufsize 
1410 and the DO bit"
shopdisney.co.uk.       0       IN      TXT     "Sending 45 bytes to 
204.13.251.144:53 using UDP, timeout 350ms"
shopdisney.co.uk.       0       IN      TXT     "Received EDNS0 with bufsize 
4096 and the DO bit"
shopdisney.co.uk.       0       IN      TXT     "AUTH server 204.13.251.144 
returned REFUSED - abandoned"
shopdisney.co.uk.       0       IN      TXT     "Sending EDNS0 with bufsize 
1410 and the DO bit"
shopdisney.co.uk.       0       IN      TXT     "Sending 45 bytes to 
208.78.71.144:53 using UDP, timeout 350ms"
shopdisney.co.uk.       0       IN      TXT     "Received EDNS0 with bufsize 
4096 and the DO bit"
shopdisney.co.uk.       0       IN      TXT     "AUTH server 208.78.71.144 
returned REFUSED - abandoned"
shopdisney.co.uk.       0       IN      TXT     "No authoritative answers for 
shopdisney.co.uk/A"
....
shopdisney.co.uk.       0       IN      TXT     "servfail shopdisney.co.uk/A”
….

HTH
—
Brian

> On Apr 2, 2020, at 12:56 PM, Doug Barton <[email protected]> wrote:
> 
> Howdy,
> 
> I redelegated shopdisney.co.uk this morning. I can see that all of the 
> Nominet authorities are returning the correct new NS set, however I have a 
> number of reports of resolution failures. There are resolvers from OpenDNS, 
> Google, Virgin, O2, and others that are not finding any name servers at all, 
> and refusing to re-query. This is causing address record resolution failures 
> for users behind those resolvers.
> 
> What is odd to me is that earlier this week we cross-pollinated the old and 
> new zone files with both the old and new sets of name servers. I have seen 
> situations in the past where cutting cleanly from one set of name servers to 
> a completely different set has caused problems, so we take this extra step of 
> updating the zones so that no matter what point in the process we're at the 
> resolving name servers will always have at least one good set to query. It's 
> always worked for me in the past.
> 
> What's even more strange is that we also did shopdisney.it this morning, 
> having done the same preparation, and it's solid as a rock. It's only the 
> CO.UK name that is failing. When querying OpenDNS or Google directly I get 
> the same result when it fails:
> 
> dig @8.8.4.4 shopdisney.co.uk ns
> ; <<>> DiG 9.10.6 <<>> @8.8.4.4 shopdisney.co.uk ns
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1587
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;shopdisney.co.uk.            IN      NS
> 
> ;; Query time: 501 msec
> ;; SERVER: 8.8.4.4#53(8.8.4.4)
> ;; WHEN: Thu Apr 02 12:28:46 PDT 2020
> ;; MSG SIZE  rcvd: 45
> 
> The flags are the same for the OpenDNS servers.
> 
> Has anyone seen this happen before? I've seen plenty of cases where resolvers 
> have hung onto the old NS set for too long (following the parent TTL instead 
> of the child), which is why I have been adding both sets of name servers to 
> both zones in advance of the redelegation. But I have literally never seen a 
> case where a resolver not only has no NS records, but also will not re-query.
> 
> My first thought was that Nominet withdrew the delegation for a short period, 
> and the resolvers have a negative cache entry, but when doing the UAT this 
> morning I happened to catch the exact point at which they changed. In serial 
> number 1308977661 they had the old NS set, and in 1308977662 they had the new 
> one. So that doesn't seem to be the problem.
> 
> If anyone from OpenDNS and/or Google can take a look at a resolver that is 
> failing for shopdisney.co.uk and tell me what's in the logs I would deeply 
> appreciate it. Since I can't figure out what happened, I'm not sure how to 
> mitigate it for the next change.
> 
> In the past I've taken the intermediate step of also updating the parent 
> delegation to include both NS sets, which I plan to do for the next set of 
> updates just to be on the safe side, but given this fun new failure mode it's 
> not clear to me that even doing that will insulate us.
> 
> Any thoughts/help/advice welcome,
> 
> Doug
> _______________________________________________
> dns-operations mailing list
> [email protected]
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations


_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Reply via email to