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 <[email protected]> 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 > [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
