> 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

Reply via email to