Subject: Re: Two more NSEC++ proposals

From: Ben Laurie <[email-masked]>
Date: Fri, 01 Apr 2005 11:10:18 +0100

Edward Lewis wrote:
> At 16:14 -0500 3/31/05, Samuel Weiler wrote:
> 
>> Proposal 1:
>>
>>    One could also create a delegation within the zone to keep these
>>    names in one place:
> 
> 
> It is not wise to propose a new TLD in a protocol document.

What TLD? None was proposed that I can see.

>> Proposal 2:
> 
> 
>>    The authoritative server keeps a table of these and selects the
>>    right one, along with its RRSIG, whenever needed.
> 
> 
> This is broken on so many levels.  For one, database coherency.

Why?

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Edward Lewis <[email-masked]>
Date: Fri, 1 Apr 2005 06:31:20 -0500

>What TLD? None was proposed that I can see.

"The zone" -> it that's the root, the "create a delegation" is a new 
TLD.  This has been raised before.

>>  This is broken on so many levels.  For one, database coherency.

For one, this breaks the RRSet rules in RFC 2181.

You have authoritative servers giving different RRs for the same 
(OWNER, TYPE, CLASS) triple.

What's a cache to do?  It's not going to combine them...
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Achieving total enlightenment has taught me that ignorance is bliss.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 01 Apr 2005 12:45:59 +0100

> TLD.  This has been raised before.

I don't think the root cares about enumeration :-)

> You have authoritative servers giving different RRs for the same (OWNER, 
> TYPE, CLASS) triple.
> 

Cache's are already supposed to store negative responses against the 
query triple, so I don't see why this is an issue?

Cheers,

Ben.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 1 Apr 2005 10:33:47 -0500

>I don't think the root cares about enumeration :-)

A zone is a zone is a zone.  DNS is one protocol.  We can't survive dialects.

>Cache's are already supposed to store negative responses against the query
>triple, so I don't see why this is an issue?

RFC 2181.  RRSets, RRSets, RRSets.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Ben Laurie <[email-masked]>
Date: Fri, 01 Apr 2005 16:37:44 +0100

> A zone is a zone is a zone.  DNS is one protocol.  We can't survive 

Hmmm. RFC 2782?

>> query

5.3. DNSSEC Special Cases

    Two of the record types added by DNS Security (DNSSEC) [RFC2065]
    require special attention when considering the formation of Resource
    Record Sets.  Those are the SIG and NXT records.  It should be noted
    that DNS Security is still very new, and there is, as yet, little
    experience with it.  Readers should be prepared for the information
    related to DNSSEC contained in this document to become outdated as
    the DNS Security specification matures.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 1 Apr 2005 11:02:42 -0500

>>  A zone is a zone is a zone.  DNS is one protocol.  We can't 

What about it?  (If you are referring to "Name" vs. the owner name, 
see the comments in the current version of the wcard draft.)

>    the DNS Security specification matures.

The point is that in 2181 we finally realized the sanctity of the 
RRSet and formalized it.  A fundamental principle is that no matter 
where you ask the global DNS for (QNAME, QTYPE, QCLASS) you should 
get the same RRSet in response.  Of course, given things like the 
finite speed of light, there will be times where propagation delays 
cause schisms.  That's life when you deal with loosely coupled 
systems.  (There's a lot to understand about the tradeoffs of loosely 
coupled and tightly couple system design.  10-15 years ago we had a 
lot of tightly coupled distributed applications products that have 
migrated to using loosely coupled underlayers, including DNS - which 
is why you see 2782, 3401-4, etc.  This is too large a topic to cover 
here.)

Telling the authoritative servers to answer differently *at the 
source* for an RRSet - granted one not asked for in this case, but 
one expected in a name error response - is not even giving the basic 
principle of coherency a chance.

You see Vixie's reply to changing the search algorithm.  Don't go 
lightly into suggesting changes there, even if the wcard is proposing 
a change to CNAME at *.    Yeah, there's a subjective line between 
what's okay to diddle with and what's not.  Because it's subjective, 
it's difficult to relay what the criteria are.

2181 is right to be afraid of DNSSEC.  There were two DNSSEC's after 
that.  But even DNSSEC has to stay within the bounds of the spirit of 
DNS lest DNSSEC kill DNS off.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 01 Apr 2005 23:33:30 +0100

Edward Lewis wrote:
> What about it?  (If you are referring to "Name" vs. the owner name, see 
> the comments in the current version of the wcard draft.)

It creates new TLDs, that's what about it. We seem to have survived the 
experience.

> The point is that in 2181 we finally realized the sanctity of the RRSet 
> and formalized it.  A fundamental principle is that no matter where you 
> ask the global DNS for (QNAME, QTYPE, QCLASS) you should get the same 
> RRSet in response.  Of course, given things like the finite speed of 
> light, there will be times where propagation delays cause schisms.  
> That's life when you deal with loosely coupled systems.  (There's a lot 
> to understand about the tradeoffs of loosely coupled and tightly couple 
> system design.  10-15 years ago we had a lot of tightly coupled 
> distributed applications products that have migrated to using loosely 
> coupled underlayers, including DNS - which is why you see 2782, 3401-4, 
> etc.  This is too large a topic to cover here.)
> 
> Telling the authoritative servers to answer differently *at the source* 
> for an RRSet - granted one not asked for in this case, but one expected 
> in a name error response - is not even giving the basic principle of 
> coherency a chance.
> 
> lightly into suggesting changes there, even if the wcard is proposing a 
> change to CNAME at *.    Yeah, there's a subjective line between what's 
> okay to diddle with and what's not.  Because it's subjective, it's 
> difficult to relay what the criteria are.
> 

The proposal does not cause you to get different RRSets depending on 
where you make the query. I'm totally missing what your problem is here.

---

From: Edward Lewis <[email-masked]>
Date: Sun, 3 Apr 2005 10:18:42 -0300

At 23:33 +0100 4/1/05, Ben Laurie wrote:

>It creates new TLDs, that's what about it. We seem to have survived
>the experience.

No, we haven't.

In the past a similar proposal was floated (for separating the hashes 
from the zone contents).  The outcome was that we decided that the 
data in the tree, or the "shape of the tree" should be constrained by 
the protocol definition.  I haven't found any pointers to this 
discussion, so I'll add the following two items:

There is document being floated by the IAB 
(draft-iab-dns-choices-00.txt, expiring on April 11), in particular a 
section 3.2 called "Add a prefix to the owner name."

There is a policy bound body whose job it is to decide the shape of 
the DNS tree, it is ICANN.  If you get a taste of ICANN you will see 
the difference between protocol engineering and data policy.

>The proposal does not cause you to get different RRSets depending on where
>you make the query. I'm totally missing what your problem is here.

It seems to me it does.  I ask for foo.example and get back "example. 
NoNames A B" and then I ask for bar.example and get "example. NoNames 
C D".  Which is it?  Which RRSet is the one?

IMHO, messing with the search algorithm is going to burn us.  It's 
not just the problem at the authoritative servers, but at the caches 
and anyother element that is concerned with persistence of DNS data.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Ben Laurie <[email-masked]>
Date: Sun, 03 Apr 2005 15:07:33 +0100

>> It creates new TLDs, that's what about it. We seem to have survived

We haven't? So are you saying RFC 2782 should be abolished?

> from the zone contents).  The outcome was that we decided that the data 
> in the tree, or the "shape of the tree" should be constrained by the 
> protocol definition.  I haven't found any pointers to this discussion, 
> so I'll add the following two items:
> 
> There is document being floate draft-iab-dns-choices-00.txt, expiring on April 11), in particular a 

We're obviously in red herring city here. What does this have to do with 
  the discussion?

> There is a policy bound body whose job it is to decide the shape of the 
> DNS tree, it is ICANN.  If you get a taste of ICANN you will see the 
> difference between protocol engineering and data policy.

Hah. If you want me to swallow this FUD, you're going to have to dig up 
some evidence.

>> where
> NoNames A B" and then I ask for bar.example and get "example. NoNames C 
> D".  Which is it?  Which RRSet is the one?

These are different queries. The principle you were worried about was this:

"A fundamental principle is that no matter where you ask the global DNS 
for (QNAME, QTYPE, QCLASS) you should get the same RRSet in response."

It does not seem to me that this principle is violated.

> IMHO, messing with the search algorithm is going to burn us.  It's not 
> just the problem at the authoritative servers, but at the caches and 
> anyother element that is concerned with persistence of DNS data.

As already discussed, we already require caches to only serve cached 
negative responses in response to identical queries. NSEC++ does not 
change this.

Cheers,

Ben.

---

From: Edward Lewis <[email-masked]>
Date: Sun, 3 Apr 2005 12:25:57 -0300

>We haven't? So are you saying RFC 2782 should be abolished?

Please read the wcard draft and see the text it currently has.  I 
don't know what else you may be referring to.

I.e., RFC 2782 doesn't propose using prefixes as a way to solve DNS 
problems.  It proposes them as a way to solve an application's 
problems.  That's the comment about the RFC mixing specification and 
use case.

>>  There is document being floate draft-iab-dns-choices-00.txt, expiring
>>on April 11), in particular a section 3.2 called "Add a prefix to the owner
>>name."
>

Red herring?  This document is germane as the first proposal is to 
separate all of the hashes by "creat[ing] a delegation within the 
zone to keep these names in one place."  That sounds like what the 
draft, section 3.2 is arguing against - shaping the tree for a 
particular purpose.

BTW, you can't "delegate within a zone".  I assume the intention is 
to "create a subdomain within the zone".

>>  There is a policy bound body whose job it is to decide the shape of the DNS
>>tree, it is ICANN.  If you get a taste of ICANN you will see the difference
>>between protocol engineering and data policy.
>

E.g., the recommendation issued this week by the US National Academy 
of Sciences on the DNS and Internet Navigation.  From a presentation 
I attended last week, the recommendation was to limit the addition of 
new entries in the root because of all of the manual review of the 
zone.

E.g., the amount of diligent review studying the deployment of DNSSEC 
in the root zone.  Discussions toward this end have taken years.

Does this clear up any uncertainty of the scale of the problem?  Well 
the problem of doing this for the root?

>>No Names A B" and then I ask for bar.example and get "example. NoNames C D".
>>Which is it?  Which RRSet is the one?
>
>"A fundamental principle is that no matter where you ask the global DNS for
>(QNAME, QTYPE, QCLASS) you should get the same RRSet in response."
>

True, but think of it from the side of the recipient of the data. 
When I am presented with different values for the same owner name, 
type, and class, I'm not going to hold both.

>As already discussed, we already require caches to only serve cached negative
>responses in response to identical queries. NSEC++ does not change this.

I'm not sure of this...you are still proposing to pass inconsistent 
data through the DNS.

Remember that what's in a protocol message is the issue (or an 
issue), not how implementations store the data.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Ben Laurie <[email-masked]>
Date: Sun, 03 Apr 2005 17:25:14 +0100

Edward Lewis wrote:
> I'm not sure of this...you are still proposing to pass inconsistent data 
> through the DNS.

_I'm_ not proposing anything! I'm discussing someone else's proposals.

Cheers,

Ben.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 4 Apr 2005 10:55:02 -0300

>_I'm_ not proposing anything! I'm discussing someone else's proposals.

The royal "you."

;)