Subject: Re: NSEC synthesis and the NSEC Next Domain Name field

From: Ben Laurie <[email-masked]>
Date: Fri, 11 Jun 2004 10:00:52 +0100

Don Stokes wrote:
> What happens if you get:
> 
> 	x.example. 	NSEC 	x.example. ...

That proves that x.example. does exist and doesn't prove that anything 
doesn't exist.

Cheers,

Ben.

-- 
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: Roy Badami <[email-masked]>
Date: Fri, 11 Jun 2004 11:15:21 +0100

>>>>> "Ben" == Ben Laurie <[email-masked]> writes:

    >> x.example.  NSEC x.example. ...

    Ben> That proves that x.example. does exist and doesn't prove that
    Ben> anything doesn't exist.

I thought it proves that nothing else in the zone exists.  The
canonical ordering is circular, so if the next RR is yourself, it
means there are no other RRs...

      -roy

---

From: Ben Laurie <[email-masked]>
Date: Fri, 11 Jun 2004 11:34:49 +0100

> means there are no other RRs...

You may be right.

---

From: Don Stokes <[email-masked]>
Date: Fri, 11 Jun 2004 22:41:29 +1200

Ben writes:
>    >> x.example.  NSEC x.example. ...>

>means there are no other RRs...

but if there's nothing (else) there, the current drafts say there
shouldn't be an NSEC record.  NSEC records should show up only when
there's something to talk about...

I wasn't being very clear, and was conflating two separate issues.  So
I'll have another go.  Assume that one wishes to generate static NSEC
records for all names that do exist, but without a traversable NSEC
chain.  Assume too that we want to do authenticated denial on the fly
for those that don't.

Firstly, for the names that DO exist, what should I put in the Next
Domain Name field of the NSEC record to say, "this is the NSEC record
for the name you asked for, but this NSEC does not cover any other
possible record"?

Secondly, if I am to generate signed negative responses on the fly to
cover names that DO NOT exist, what would those records look like?  Can
we fudge NSEC in some way to provide on-the-fly authenticated denial,
(and allow for that capability within DNSSEC-bis), or do we need some
kind of "signed NXDOMAIN" response in DNSSEC-ter?

-- don

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 10 Jun 2004 21:21:37 -0400

I would suggest the next domain name be the apex - indicating it is the last
canonical name in the zone.

Yes, it isn't true, but caches should be fabricating non-existance responses
for non-authoritative data anyway.

Scott

----- Original Message ----- 
From: "Don Stokes" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, June 10, 2004 7:32 PM
Subject: NSEC synthesis and the NSEC Next Domain Name field

>
> Folks,
>
> If one is to synthesise NSEC records, either online, or staticly in
> "NSEC white lies" the recent draft put it, what should one place in the
> Next Domain Name field of the NSEC record?
>
> As things stand, it appears that given a name "x.example.", then the
> very next name that could be created in given the canonical ordering
> rules would be "\001.x.example.".
>
> However, that doesn't sit nicely (although this might not be a problem)
> when x.example is a delegation; one doesn't really want "fake" NSEC
> records pointing at subdomains that don't exist, e.g.
>
> x.example. NS ns1.example.com.
> NS ns2.example.com.
> NSEC \001.x.example. NS RRSIG NSEC
>
> as \001.x.example is out of bailiwick.  The "next" name at the same
> level as x.example would be "x\001.example.".
>
> What happens if you get:
>
> Could replaying that NSEC record be used to (e.g.) forge a denial of
> y.example.?
>
> What I'm looking for is a standard, canonical way of saying, "this name,
> and only this name, does not exist", preferably without reference to
> other data.
>
> Is this a special case for the NSEC Next Domain Name field, or can it
> reliably be fudged?  Could the field be given a value that meant "there
> is no next domain name field; this NSEC only refers to the name
> queried"?
>
> -- don
>
> --

---

From: Ben Laurie <[email-masked]>
Date: Fri, 11 Jun 2004 15:34:17 +0100

> for non-authoritative data anyway.

"shouldn't", surely?

I was also coming to the conclusion that a pair of records of the form:

x.example. NSEC example.
example. NSEC x.example.

could be used to deny anything (except example. or x.example.), without 
causing other problems - apart, of course, from giving an attacker a 
method of denying any name's existence.

Or would just:

example. NSEC example.

suffice?

Cheers,

Ben.

---

From: Derek Atkins <[email-masked]>
Date: Fri, 11 Jun 2004 10:34:58 -0400

> for non-authoritative data anyway.

That unfortunately enables replay attacks if a "bad cache" gets
in your path or an attacker can guess your query txn id.

> Scott

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Robert Elz <[email-masked]>
Date: Wed, 30 Jun 2004 15:20:02 +0700

Date:        Fri, 11 Jun 2004 11:32:43 +1200
    From:        Don Stokes <[email-masked]>
    Message-ID:  <[email-masked]>

I haven't been reading the list for the past few weeks, and am attempting
to catch up.

  | as \001.x.example is out of bailiwick.  The "next" name at the same
  | level as x.example would be "x\001.example.".

This is a minor point, but I saw this, and didn't see it corrected (though
I have not yet read all of the messages since this one), and I'd like to
try and avoid one more piece of DNS folklore being developed, that everyone
"simply knows" but which is incorrect...

The "next" name in this sense from x.example would be \000.x.example
not \001.x.example - or if you prefer, \000.x.example sorts between
x.example and \001.x.example.

The same is true for x\000.example (wrt x.example and x\001.example
of course).

There's nothing in the DNS spec that prohibits the use of the nul
character in labels, and 0 is clearly < 1 (but greater than absent).

kre