Subject: Re: zone-covering NSEC ranges -- "which is it?"

From: Paul Vixie <[email-masked]>
Date: Mon, 14 Jun 2004 21:48:20 +0000

> I had been assuming the second possible answer, given that RFC2535
> said (5.1):
> 
>    There is a potential problem with the last NXT in a zone as it
>    wants to have an owner name which is the last existing name in
>    canonical order, which is easy, but it is not obvious what name to
>    put in its RDATA to indicate the entire remainder of the name
>    space.  This is handled by treating the name space as circular and
>    putting the zone name in the RDATA of the last NXT in a zone.
> 
> However it appears that DNSSECbis makes no similar statement about a
> circular name space.

not only that, the circularity is only by mention, not in fact.  it does
not say that putting your own owner name in as the target name works;
rather, that the zone name (or apex, or @ in my example) is special cased.

--
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: Jim Reid <[email-masked]>
Date: Tue, 15 Jun 2004 14:25:15 +0100

>>>>> "Roy" == Roy Badami <[email-masked]> writes:

    Olaf> The mention of circularity is unambiguously mentioned in
    Olaf> records 4.1.1.

    Olaf> The value of the Next Domain Name field in the last NSEC
    Olaf> record in the zone is the name of the zone apex

    Roy> I disagree that it is unambiguous.  It is perfectly possible
    Roy> to read the above paragraph as indicating that the last NSEC
    Roy> record in the zone is a special case.

In that case, please contribute text that clarifies your perceived
ambiguity.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 16 Jun 2004 06:11:47 +0000

> ...
> If the WG concensus is that the DNSSEC design is based on the idea of
> a circular canonical ordering, ...

i don't think there's consensus on this yet.  not "informed" consensus at
any rate.  circularity is mentioned, and a target name of @ is given as an
example.  however, there's nothing in this thread, or the documents that
i can find, that describes

  $ORIGIN example.com.
  @ IN SOA ...
       NSEC Q
  Q    NSEC P

as denying the existence of names from Q to S wrapping through @.  in other
words if it really is a circular namespace then "Q NSEC P" denies O, R,
and so on.  and it's not clear that "Q NSEC Q" doesn't deny P, R, and etc,
since ownername==targetname.  and it's not clear whether "Q NSEC P" denies
@ or not.  targetname of @ seems very much special cased in the current docs.

lastly, the target name should have to be in-balliwick.  right now it would
be legal to say "Q NSEC Z.NET." but it's completely unclear what it would
mean.

these are probably editorial issues; consensus -- informed consensus, that
is -- will likely not be long in coming, once the right questions are asked.
note that i do not consider them to have been asked correctly yet, by me or
by anybody else in the thread that erupted from my weekend inquiry about this.

(if we really mean circularity, then we need "Q NSEC P" as one of our examples
and we need to explain what it means.  and the other stuff i mention above.)

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 16 Jun 2004 09:44:01 +0200

On Wed, 16 Jun 2004 06:28:45 +0000
Paul Vixie <[email-masked]> wrote:

> >   $ORIGIN example.com.
> >   @ IN SOA ...
> >        NSEC Q
> >   Q    NSEC P
> > 
> > as denying the existence of names from Q to S wrapping through @.  
> 
> "from Q to P wrapping through @", i meant.

Paul,

I think circular canonical ordering has never been a point of
discussion. It was described more explicit in 2535 and we have never
ever challenged canonical ordering. As far as I am concerned circular
canonical ordering is an editorial matter; it needs to be made more
explicit. (I appreciate that Roy, as a new reader, saw an ambiguity).

>From the cirular canonical ordering and the fact a zone always has an
apex you can deduce that Q NSEC P is simply invalid unless P equals
the apex, just as X NSEC X is invalid unless X equals the apex and the
zone is empty.

I think that DNSSEC-bis leaves behaviour for Q NSEC P where P is not
the apex unspecified. It may even be useful for a zone owner to
generate such records and a validator may do useful thinks with these
records, on the other hand you have to consider that synthesized NSEC
RRs can be used in replay attacks as I argued for the X NSEC X case.

If you do not want replay attacks to be harmfull (because you want
white lies) than go and change the 'security state machine' by
changing the specs and experience the pain.

-- Olaf 
   No Hats (but tempted to put one on 'during' the first paragraph.)

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC

---

From: Derek Atkins <[email-masked]>
Date: Wed, 16 Jun 2004 11:34:12 -0400

"Olaf M. Kolkman" <[email-masked]> writes:

>    It may even be useful for a zone owner to

This seems to argue that X NSEC X should be specified to cover exactly
one name (X), except for the special case of X = @.  I don't believe
that X NSEC X is a white lie -- indeed, if you are trying to implement
on-the-fly NXDOMAIN signing, what _ARE_ you supposed to use for the
'next domain' entry in an on-the-fly NSEC?

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

---

From: [email-masked] (Geoffrey Sisson)
Date: Wed, 16 Jun 2004 16:56:19 +0100 (BST)

> 'next domain' entry in an on-the-fly NSEC?

You could have "X NSEC X+1" where X+1 is the next possible owner name
in cannonical sort order, e.g.

	a.example. NSEC	a-.example.

or even

	a.example. NSEC a\000.example.

In this case, if the owner name were the last possible owner name in
sort order, it would point back to the apex.

Regards

Geoff

---

From: Edward Lewis <[email-masked]>
Date: Wed, 16 Jun 2004 12:19:45 -0400

>'next domain' entry in an on-the-fly NSEC?

If the next name field in the NSEC is defined to be the next name in 
the zone, then generating on-the-fly "X NSEC X" (where there is 
another name in the zone) *is* a "white" lie.  More accurately, an 
abuse of the protocol.

If you are to implement on-the-fly RCODE='name error' signing, then 
you don't need the NSEC approach of showing a next name.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

"I can't go to Miami.  I'm expecting calls from telemarketers." -
Grandpa Simpson.

---

From: Rob Austein <[email-masked]>
Date: Wed, 16 Jun 2004 12:45:28 -0400

I'm not comfortable with this X NSEC X thing, for two reasons:

a) As far as I can tell, the answer to the question "is it circular or
   is X NSEC @ a special case?" is "mu".  The only case where the
   circularity mattered in RFC 2535 for X NXT Y was Y = @, because in
   all other cases, Y > X, by definition.

b) Defining X NSEC X to be a statement just about X would require
   treating @ NSEC @ as a special case.

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Wed, 16 Jun 2004 23:03:21 -0400

>    treating @ NSEC @ as a special case.

<just a regular wg-member>
@ NSEC @  with SOA bit set
zone @ has only records at apex and here is the list.

X NSEC X  (w/o SOA bit set) is IMHO a REAL BAD IDEA.
It says name X exits and has following types, this is not what you
want to communicate as it may confuse resolvers.  It is perfectly
valid for a validating resolver to return to client RCODE=0
with empty answer, rather than the intended RCODE=3.

What should be done in this case is
         pred(X) NSEC succ(X)
where pred(X) is a name that is:
         close to X and does not exist
         sorts before X

and succ(X)
         close to X and does not exist
         sorts after X

In this case there are no special cases, resolver that only looks
at the owner name when there is a match does not get confused.
example:
         pred("amazon") == amazom\376\376\376\376
         succ("amazon") == amazon\001\001\001\001
or
         pred("amazon") == amazom\200
         succ("amazon") == amazon\037

         Olafur