> On Feb 25, 2015, at 4:14 AM, Ray Bellis <ray.bel...@nominet.org.uk> wrote: > > >> On 25 Feb 2015, at 08:58, Stephane Bortzmeyer <bortzme...@nic.fr> wrote: >> >> I'm not sure they appear in a RFC. They are commonly used (see for >> instance <https://mex.icann.org/ar/file/22921/download/23075>) when >> discussing resolvers' behaviour. >> >> Let me suggest: >> >> Child-centric resolver: a DNS resolver which will replace, in its >> memory, the NS RRset and glue records obtained from the parent, by >> data from the authoritative servers of the zone they belong to. This >> is the proper behaviour. >> >> Parent-centric resolver: a DNS resolver which will keep in memory the >> NS RRset and glue records obtained from the parent, despite the fact >> it is non-authoritative. This is bad practice. > > This is my understanding of the terms too. > > However in the child-centric case this can cause problems when the NS set > held by the parent changes (i.e. the zone is redelegated) but the NS set in > the old set of servers isn't also updated. Such a child-centric resolver may > completely fail to notice the redelegation. > > Olafur has done a lot of work categorising this behaviour - the above is > similar to slide 4 in his deck from your link, but doesn't even require > DNSSEC for it to be a problem.
What I did was to look at what states resolvers are in regards to which set of NS records they fetch records from, I did most of this work while looking at DNS operator change/Redelegation. I never got around publishing the final results so here they are in short: Resolver types: Parent Centric: will only use NS from parent zone Strict Child Centric: will always fetch NS from one of the servers listed in parent NS set Accidental Child Centric: will overwrite parent NS with child one if it is included in answer (i.e. in Auth section) Sticky Child Centric: will reset the TTL of NS set every time it sees NS in Auth Section of answer from child zone Before “Minimal answers” became popular I did not realize the difference between Strict and Accidental Child Centric resolvers. Sticky resolvers are only a real problem in when three conditions are met, - domain has been relegated, - Old operator keep answering for the domain. - Old operator includes NS in Authority section. Notes: - The only times the resolver Centricity is an issue is when there is a difference in NS sets at parent and child. - In most cases Sticky CC Resolver is also a Accidental CC resolver, - In many cases Accidental Child Centric resolvers act like Parent Centric because the name severs operate in minimal-answer mode. Olafur ps: Trivia question why is Parent Centric never sticky? _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop