Subject: [DNSOP] Definitions of foo-centric

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 Feb 2015 14:21:54 -0800

Greetings again. People have asked us to define "delegation-centric", "child-centric", and "parent-centric" for draft-hoffman-dns-terminology. None of them are defined in RFCs, even though "delegation-centric" appears in RFCs 4956, 5155, and 7129. The terms are used in various places, so they seem like good candidates for the terminology document.

Proposals for definitions are welcome.

--Paul Hoffman

---

From: Mark Andrews <[email-masked]>
Date: Wed, 25 Feb 2015 09:47:53 +1100

In message <[email-masked]>, Paul Hoffman writes:
> Greetings again. People have asked us to define "delegation-centric", "child-cent
> ric", and "parent-centric" for draft-hoffman-dns-terminology. None of them are de
> fined in RFCs, even though "delegation-centric" appears in RFCs 4956, 5155, and 7
> 129. The terms are used in various places, so they seem like good candidates for 
> the terminology document.
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

delegation-centric - a zone which consists mostly of delegations to child zones.
the root zone and the com zone are examples of delegation-centric zones.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Wed, 25 Feb 2015 00:26:39 +0000

Delegation centric - for all labels below the apex, each owns an NS set.
(I.e., each is a cut point.)

I’ve never heard the other terms, have no idea what they’d mean (out of
context).

On 2/24/15, 17:21, "Paul Hoffman" <[email-masked]> wrote:

>Greetings again. People have asked us to define "delegation-centric",
>"child-centric", and "parent-centric" for draft-hoffman-dns-terminology.
>None of them are defined in RFCs, even though "delegation-centric"
>appears in RFCs 4956, 5155, and 7129. The terms are used in various
>places, so they seem like good candidates for the terminology document.
>

---

From: Edward Lewis <[email-masked]>
Date: Wed, 25 Feb 2015 00:37:05 +0000

>the root zone and the com zone are examples of delegation-centric zones.

Not arguing, but to raise a point - my response was “all” and Mark’s is
“most.”

There’s a subtly to the different that bothers me.  Can’t quite express it.

Back when designing the DNSSEC, we were tempted to distinguish between
(what I recall the term to be there) widely delegated zones from others.
We decided to ditch that because when designing the protocol, when you
make that distinction, you have to build into the protocol a way to make
the distinction - that opened up a large set of issues.  More or less, for
simplicity, we discarded that distinction.

I guess what I’m poorly saying, the term and definition should be given in
some fixed context.

(Recall BIND’s delegation-only designation as a response to a wildcard in
a TLD.  Later that backfired a bit when DNSSEC was added to TLDs.
DNSSEC’s NSEC/NSEC3 records “broke” the rules for delegation-only.)

---

From: Mark Andrews <[email-masked]>
Date: Wed, 25 Feb 2015 12:09:34 +1100

> There’s a subtly to the different that bothers me.  Can’t quite express it.

There are tld that allow records at what would be the delegation point.
There are also tld have the nic in the zone, etc. 

delegation-only are a subset of delegation-centric

> DNSSEC’s NSEC/NSEC3 records “broke” the rules for delegation-only.)

More we failed to add the necessary exceptions for the DNSSEC records
types that exist at the parent side of a zone cut / empty node.

Mark

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 25 Feb 2015 09:26:47 +0100

On Wed, Feb 25, 2015 at 12:26:39AM +0000,
 Edward Lewis <[email-masked]> wrote 

> (I.e., each is a cut point.)

In that case, many TLDs (for instance .fr and .de) won't be
delegation-centric.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 25 Feb 2015 09:58:17 +0100

On Wed, Feb 25, 2015 at 12:26:39AM +0000,
 Edward Lewis <[email-masked]> wrote 
 a message of 139 lines which said:

> I’ve never heard the other terms, have no idea what they’d mean (out
> of context).

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.

---

From: Ray Bellis <[email-masked]>
Date: Wed, 25 Feb 2015 09:14:53 +0000

> On 25 Feb 2015, at 08:58, Stephane Bortzmeyer <[email-masked]> wrote:
> 

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.

Ray

---

From: Ray Bellis <[email-masked]>
Date: Wed, 25 Feb 2015 09:20:14 +0000

> On 25 Feb 2015, at 09:14, I wrote:
> 

I need to correct that:

Olafur identified a third set called "child-sticky".  It's that group that has the problem I described above, not the "child-centric" ones.

Ray

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 25 Feb 2015 10:20:04 +0100

On Wed, Feb 25, 2015 at 09:14:53AM +0000,
 Ray Bellis <[email-masked]> wrote 
 a message of 30 lines which said:

> 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.

Yes, this is the "phantom domains" attack. Let me amend the suggested
definition:

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 (but note that a resolver MUST re-check from
the parent at some interval, to avoid "phantom domains").

And this is the opportunity to define phantom domains:

Phantom domain: a domain which was delegated but is no more, and is
still "active" in some resolvers because they did not check the parent
yet.

---

From: Tony Finch <[email-masked]>
Date: Wed, 25 Feb 2015 11:13:20 +0000

> In that case, many TLDs (for instance .fr and .de) won't be

I think delegation-centric means the vast majority of entries in the zone
are delegations, as a weaker form of deletation-only which requires every
entry to be a delegation.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty, Forth, Tyne, Dogger, Fisher, North German Bight: Westerly
backing southerly 5 or 6, increasing 6 to gale 8 later. Moderate or rough,
occasionally very rough in Forties and Fisher. Rain later. Good, becoming
moderate.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 25 Feb 2015 13:02:55 +0000

On 2/25/15, 4:20, "Ray Bellis" <[email-masked]> wrote:
>
>Olafur identified a third set called "child-sticky".  It's that group
>that has the problem I described above, not the "child-centric" ones.

Having never heard the term before, “sticky” is far more descriptive than
“centric.”  (Whether it is a good idea or not.)

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 25 Feb 2015 08:38:40 -0500

> On Feb 25, 2015, at 4:14 AM, Ray Bellis <[email-masked]> wrote:
> 
> 

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?

---

From: Havard Eidnes <[email-masked]>
Date: Wed, 25 Feb 2015 15:03:48 +0100 (CET)

> the parent at some interval, to avoid "phantom domains").

Hmm.

Firstly, isn't this "child-centric resolver" / "parent-centric
resolver" simply an euphemism papering over the more distinct
"correctly" and "wrongly" implemented resolver?  A correctly
implemented resolver implements the DNS authority model, and to do
that requires that the resolver replaces non-authoritative cached data
with more authoritative data whenever it is obtained.  The perhaps
most prominent example of non-authoritative data is the copy of the NS
RRset from the child zone which exists in the parent zone.

Secondly, let me re-formulate that other part.  I thought this is
rather a matter of properly letting the NS RRset expire from the
cache, and not use the cached and soon-to-expire NS RRset to re-fetch
the child NS RRset, but that instead the NS RRset needs to be
re-fetched from the parent zone before subsequently possibly
overriding that with new authoritative information from one of the
(possibly new) child name servers, since the domain can have been
re-delegated in the mean time.

This all said without taking DNSSEC into consideration...

> still "active" in some resolvers because they did not check the
> parent yet.

Again, I'd simply call a resolver allowing this situation to persist
to be "wrong/buggy".

Best regards,

- Håvard

---

From: Edward Lewis <[email-masked]>
Date: Wed, 25 Feb 2015 15:38:39 +0000

On 2/25/15, 9:03, "Havard Eidnes" <[email-masked]> wrote:

>"correctly" and "wrongly" implemented resolver?

That’s my thought exactly.  (But that doesn’t mean the terms needn’t be
given definitions.)

>A correctly
>with more authoritative data whenever it is obtained.

To put a sharper point on this, this is documented as “trustworthiness” in
“Clarifications to the DNS Specification” [RFC 2181] inside section 5.4.1
on “Ranking Data."

I’ve seen a case of a resolver that favored the parent NS set over a child
NS set (and glue), which led to a cache poisoning event.  A delegation
that was transferred forgot to remove the glue records in the TLD, an
apparently disgruntled employee aware of this left the company, registered
a new domain that made use of the glue record.  (I’m omitting details to
make this quick.)  The net result is that the caches following this model
quickly favored the stale glue over the fresh authoritative answer,
victimizing the registrant.

Nevertheless, giving the practice a name will make it easier to explain to
someone why it’s a bad idea.

>  The perhaps

And/or the glue.

>>Phantom domain: ...

In operations, you have to deal with the bad a lot - in fact, by the very
nature of the bad being bad, you deal more with the bad than the good.
(The good is hidden under automation.)  Giving names to the bad is very
helpful for that reason.  (Root cause voice call recordings, staff
turnover, these are places where common terminology is helpful regardless
whether the term describes something good or something bad.)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 25 Feb 2015 16:44:52 +0100

On Wed, Feb 25, 2015 at 03:03:48PM +0100,
 Havard Eidnes <[email-masked]> wrote 

> Again, I'd simply call a resolver allowing this situation to persist

The important point is "to persist". A deleted domain can be a phantom
in every correct resolver until the TTL (of the *parent*) passes.

---

From: Havard Eidnes <[email-masked]>
Date: Wed, 25 Feb 2015 18:44:07 +0100 (CET)

> That's my thought exactly.  (But that doesn't mean the terms
> needn't be given definitions.)

...

> whether the term describes something good or something bad.)

Thanks, I understand and agree.

- Håvard

---

From: Mark Andrews <[email-masked]>
Date: Thu, 26 Feb 2015 07:18:18 +1100

In message <[email-masked]>, Olafur Gudmundsson 
writes:
> > 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 
>    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. 

   - 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 many cases Accidental Child Centric resolvers act like Parent 
> Centric because the name severs operate in minimal-answer mode. 
>  
>       Olafur

---

From: Mark Andrews <[email-masked]>
Date: Thu, 26 Feb 2015 07:30:50 +1100

> "correctly" and "wrongly" implemented resolver?

No. This can only happen if changes in nameservers are mis-manged.
All nameserver for a zone are supposed to serve the same content
"new" and "old" with differences only while the zone is waiting to
be transfered.  Just because lots of people just change the NS RRset
without ensuring that the zone content remains consistent doesn't
mean that it is right.

> re-delegated in the mean time.

There is nothing wrong with refreshing RRsets provided the zone is
being properly managed.
 
> - H=E5vard

---

From: Havard Eidnes <[email-masked]>
Date: Thu, 26 Feb 2015 09:44:09 +0100 (CET)

> without ensuring that the zone content remains consistent doesn't

This assumes that the new and old both collaborate in orchestrating a
tidy transfer of authority for the zone, and is something which
requires extra effort both by the new and old operators/owners.  I
would have thought that the old operator frequently has no incentive
to collaborate in this process, and sometimes the new operator also
doesn't have an incentive to alert the old one that he's moving to
take over responsibility for the zone in question.  I therefore think
that insistence that this is the only correct way to do things won't
neccessarily make it common practice, and therefore ignores reality.

> There is nothing wrong with refreshing RRsets provided the zone is

I think this ignores common practice.  Again: insisting that there is
a correct way and dismiss anything else as "you got what you lot asked
for" doesn't neccessarily make the "correct way" common practice.  Is
it your opinion that it's perfectly fine for a "child-centric"
resolver to become ~forever stuck with the old set of name servers for
a zone in the scenario sketched here earlier?

Best regards,

- Håvard

---

From: Ray Bellis <[email-masked]>
Date: Thu, 26 Feb 2015 09:03:11 +0000

> On 26 Feb 2015, at 08:44, Havard Eidnes <[email-masked]> wrote:
> 

Indeed, the reality is that most DNS hosts and their help desks are probably completely unaware of the child-sticky issue, and assume incorrectly that only the parent and the new child need to hold the new NS set.

Heck, I didn't even know that myself until Olafur described the issue a few years ago, even though I had previously spent over a decade running system operations and help desk for an ISP.

That said, I always took the view that you should cooperate as much as possible when a customer is leaving - a good experience there can help get the customer back if the new guys foul up.

Ray