[dns-operations] OpenDNS, Google, Nominet - New delegation update failure mode

[Brian Somers]

FWIW, OpenDNS/Umbrella/Cisco will use the glue to look things
up and won’t explicitly ask the authority for its own NS record.

However, if we’re asked for an NS record by a client, we’ll lookup
& return the authoritative answer and that answer will trump the glue.
We’ll never serve glue to a client.

One of the problems with caching NS records is that you’ve got to be
careful that you don’t let them keep re-asserting their own presence
in the cache (by repeating their RRset in the AUTH section every time
you talk to them).  We do *force* their eventual TTL decay, but
for frequently queried domains, the original glue TTL is *not* honoured
due to the authoritative RRset trumping it!

This may be what was happening for shopdisney.co.uk...

> On Apr 2, 2020, at 1:41 PM, Paul Vixie <paul at redbarn.org> wrote:
> 
> On Thursday, 2 April 2020 20:12:50 UTC Puneet Sood via dns-operations wrote:
>> ,,,
>> 
>> Google Public DNS is “parent-centric”—meaning that it only uses the
>> name servers that are returned in the referral responses from the
>> parent zone name servers, and does not make NS queries to this child
>> zone. So updating the parent delegation to include both NS sets will
>> help with Google Public DNS resolution.
>> 
>> ...
> 
> this is concerning, so, two questions:
> 
> would you change this parent-centrism or or when you implement QM?
> 
> when you receive NS RRs from the authority, perhaps as part of an NXD 
> response, do you ignore them?
> 
> if you process a stub query asking for NS, do you return the set you received 
> during iteration?
> 
> -- 
> Paul
> 
> 
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations