In message <cf207787-b876-4ad6-91d8-3b62da019...@ogud.com>, Olafur Gudmundsson
writes:
>
> > 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.
- Old operator continues to serve old zone content.
If the old operator becomes a temorary slave with the new zone
content or even just updates the NS RRset and associated address
records to match the new set of servers the traffic will be
pushed to the new servers.
The myth that allowing the zone to be transfered is in anyway a
a security issue actually makes changing nameservers harder as
the loosing server operator tends to be blocked from becoming
a temporary slave.
> 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
