Subject: Re: [DNSOP] Why 2 caches? draft-fujiwara-dnsop-resolver-update-00

From: Edward Lewis <[email-masked]>
Date: Mon, 14 Nov 2016 07:31:51 +0000

I'm a little confused to the feedback, so I'm asking for some clarification.

On 11/14/16, 11:27, "DNSOP on behalf of Ondřej Surý" <[email-masked] on behalf of [email-masked]> wrote:

>I think this is a technical detail best left to the software vendors and it should be removed from the draft.

My question/suggestion is in reaction to this passage in the draft "proposes updated resolver algorithm that separate authoritative data cache that is answered to stub resolvers and delegation cache" and some other responses suggesting that having two caches might be troublesome.

Are you saying that how this is implemented is to be left up to the software developer?  If so, I agree with that.  But I am not sure you if are commenting on my "why it can't it be done this way" comment.  Either way, my comment is not to overly specify how.

>As a side note, having a (platform-sized) pointer for each RR in the RR-cache is a huge bloat...

I hadn't claimed by idea was good. ;)  It was the first alternative that came to mind.
    
>If we were to design RFC1034/1035 again I would say that NS records are more close to DS.

Hmmm.  I'm not sure I understand what you mean by "more close."  I was going to say that for DNSSEC, we found it tricky to find two data sets with the same owner/class/type having two sources and so had to dance around the split responsibilities for the NS set.  But then we invented NSEC which is features two set with the same owner/class/type but two authorities (as opposed to sources) also, except that this time (NSEC and then NSEC3 and any proposed updates) the RDATA was distinctly different.

If I were to redo what was in the base definitions, I would have used different type codes for the set above the cut and the set below the cut - but not for NSEC/NSEC3/etc.  I don't have a neat generalization, but, in summary having the NS set above and below, and having glue not marked as such in the type code (GLUEA or GLUEAAAA) is, I don't know, suboptimal in retrospect.

>The predictability of resolver behavior.

Yes, there's work needed to do, both NS sets (at a cut) are needed in tandem.

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 14 Nov 2016 09:01:40 +0100 (CET)

----- Original Message -----
> From: "Edward Lewis" <[email-masked]>
> To: "Ondřej Surý" <[email-masked]>
> Cc: "dnsop" <[email-masked]>
> Sent: Monday, 14 November, 2016 08:31:51
> Subject: Re: [DNSOP] Why 2 caches? draft-fujiwara-dnsop-resolver-update-00

> My question/suggestion is in reaction to this passage in the draft "proposes
> updated resolver algorithm that separate authoritative data cache that is
> answered to stub resolvers and delegation cache" and some other responses
> suggesting that having two caches might be troublesome.
> 
> Are you saying that how this is implemented is to be left up to the software
> developer?  If so, I agree with that.

Yes :)

> But I am not sure you if are commenting on my "why it can't it be done this way"
> comment.  Either way, my comment is not to overly specify how.
> 
> Hmmm.  I'm not sure I understand what you mean by "more close."  I was going to
> say that for DNSSEC, we found it tricky to find two data sets with the same
> owner/class/type having two sources and so had to dance around the split
> responsibilities for the NS set.  But then we invented NSEC which is features
> two set with the same owner/class/type but two authorities (as opposed to
> sources) also, except that this time (NSEC and then NSEC3 and any proposed
> updates) the RDATA was distinctly different.

Yep, I understand why it was left alone, and it's ok that way.

> If I were to redo what was in the base definitions, I would have used different
> type codes for the set above the cut and the set below the cut - but not for
> NSEC/NSEC3/etc.  I don't have a neat generalization, but, in summary having the
> NS set above and below, and having glue not marked as such in the type code
> (GLUEA or GLUEAAAA) is, I don't know, suboptimal in retrospect.

Sure.

> Yes, there's work needed to do, both NS sets (at a cut) are needed in tandem.

Are they?  What is child-NS needed for?

Ondrej
--
 Ondřej Surý -- Technical Fellow
 --------------------------------------------
 CZ.NIC, z.s.p.o.    --     Laboratoře CZ.NIC
 Milesovska 5, 130 00 Praha 3, Czech Republic
 mailto:[email-masked]    https://nic.cz/
 --------------------------------------------

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 14 Nov 2016 20:10:50 +0900

> On Nov 14, 2016, at 5:01 PM, Ondřej Surý <[email-masked]> wrote:
> 
> 
I was designing it today I would have a different RR type in parent and child, and the parent type should be able to hold glue record contents. 

> Are they?  What is child-NS needed for?

That is what the NS set that the resolver should use, the one in parent is just a hint. 
All good resolvers should use the Parent as hint as to find the child one, once the resolver has the 
child one toss the one from the parent. 
I know this is one extra query which is almost free as it can be done in parallel with the query for real data. 

Olafur

---

From: Edward Lewis <[email-masked]>
Date: Mon, 14 Nov 2016 21:33:21 +0000

On 11/14/16, 20:10, "Olafur Gudmundsson" wrote:
>On Nov 14, 2016, at 5:01 PM, Ondřej Surý wrote:
>
>All good resolvers should use the Parent as hint 
>as to find the child one, once the resolver has 
>the child one toss the one from the parent. I know
>this is one extra query which is almost free as 
>it can be done in parallel with the query for real
>data. 

Both NS sets are needed when the differ.  There are a few states in which the two differ, that is when there are changes going on.  Changes might be
legitimate or results of abuse.

When both sets agree, then of course only one is needed, but one does not know they agree until you have both.

The importance of the child NS is to allow the child admin to bring on a name server before it has a chance to get the parent admin to update their zone.  In some cases, a parent has a policy of only updating the NS set to the child set.  The reasons include the parent avoiding starting a lame delegation and to make it easier to verify what the child admin intends to do.

There's the conceptual driver, that once the parent delegates to the child, the child decides everything including what nameservers they use.  This "works" up to the point of worrying about zone hijacking, yet another example of how "abuse of the network" wasn't considered in the original designs.  So this driver is less relevant now than it used to be.