> On Feb 25, 2015, at 4:14 AM, Ray Bellis <[email protected]> wrote:
>
>
>> On 25 Feb 2015, at 08:58, Stephane Bortzmeyer <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop