Subject: proposed definition for the NXT

From: Edward Lewis <[email-masked]>
Date: Tue, 6 May 2003 08:52:40 -0400

I'm proposing this for the NXT in the DNSSECbis document...

   After properly validating the NXT's authenticity:

   If the NXT-position bit is 1, then the NXT is processed as per RFC 2535
   or the DS RR (I don't recall any difference).

   If the bit is 0, then the verifier treats the zone as unsigned, ergo, all
   the subzones are unsigned.  (Yeah, yeah, secure entry points, yadda, yadda.)
   (See note 1 below.)

With that definition, non-opt-in (I'll call them 2535) zones will 
work, as they will either have only 1's in the NXT (bit position of 
the NXT) or no NXT's. Zones that do the funny stuff will be treated 
as the old experimental zones, which defaults to unsigned.  This 
let's server operators play with funny stuff (e.g., the current 
opt-in proposal) while not breaking themselves off the net.  For 
resolvers, which is what DNSSEC is all about protecting, the older 
resolvers are fine with 2535 and pre-2535 zones, and buffered against 
the funny stuff.  Once the funny stuff is acceptable, hits the 
standards track, then it becomes cool to define what the funny stuff 
is.  On the other hand, if the funny stuff never gets accepted, then 
the operators doing the funny stuff will have a reason to just sign 
the whole zone.

This lets us proceed without the presumption that the opt-in 
detractors are wrong because opt-in isn't being put into the resolver 
right out.  It respects the fact that consensus hasn't been reached, 
at least in the chairs' eyes.   Also, those who want to press forward 
stamping out the apparent uncertainty and doubt (omitting fear) have 
a sandbox area to make medium scale deployments for the sake of 
testing.

...For the time being, a compliant DNSSECbis signer MUST set the bit to 1.

Note 1 - Yes, any '0' bit in the NXT will make the resolver see the 
whole zone as unsigned - for the duration of the query at least, at 
most the ttl of the NXT it is looking at.  The burden is not on the 
resolver to seek out all the NXT's and look for '0' bits, but only if 
the query stumbles on it.  Treating the zone as unsigned means 
ignoring any DS records, KEY records, SIG records, NXT records, etc. 
By tainting the whole zone you "punish" the operator for doing this 
on the large scale, if that is your desire.  I think just treating 
spans of the zone as unsigned would be an over complication and too 
much like the current opt-in.  Perhaps we should always require a 
server to load only zones that have one kind of NXT - with the 1 or 
with the 0, and no combinations.  This will make it easier to decide 
of a zone is doing funny stuff.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Note to pilots: a three-point landing SHOULD NOT include a wing.

--
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: Paul Vixie <[email-masked]>
Date: Tue, 06 May 2003 14:24:41 +0000

>    If the bit is 0, then the verifier treats the zone as unsigned,
>    ergo, all the subzones are unsigned.  (Yeah, yeah, secure entry
>    points, yadda, yadda.)

at first glance, i like this approach.

>    (See note 1 below.)
...
> Note 1 - Yes, any '0' bit in the NXT will make the resolver see the whole
> zone as unsigned - for the duration of the query at least, at most the ttl
> of the NXT it is looking at.  The burden is not on the resolver to seek out
> all the NXT's and look for '0' bits, but only if the query stumbles on it.
> Treating the zone as unsigned means ignoring any DS records, KEY records,
> SIG records, NXT records, etc. By tainting the whole zone you "punish" the
> operator for doing this on the large scale, if that is your desire.  I
> think just treating spans of the zone as unsigned would be an over
> complication and too much like the current opt-in.  Perhaps we should
> always require a server to load only zones that have one kind of NXT - with
> the 1 or with the 0, and no combinations.  This will make it easier to
> decide of a zone is doing funny stuff.

since it's unenforceable, let's not specify that.  that is, your rule about
interpreting a "0" bit is the same thing, and would have to be done no matter
what requirements were stated for zone operators.  so let's just note that
so that zone operators can understand that the significance of a single "0"
bit is the same, to what you're calling 2535-style (but is really DS-style)
validators, as if all NXT.maskbit(NXT)'s in the zone were zero.  if a zone
operator wants to mix their 0's and 1's in spite of this notation, then it's
possible they'll have a reason they consider good and sufficient.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 7 May 2003 10:17:34 -0400

Since I have proposed this I've had a number of comments come to me. 
I will post an update sooner or later to address what I consider to 
be rather constructive comments:

   1) Might just want to consider the zone unsigned for the purposes of the
      current query.

   2) Might want to have the same behavior with the SIG bit as it is in the
      same class as the NXT.

   3) My own intention - address what happens if the group decides to roll
      the type codes.  (Not pushing it, but anticipating.)

If anyone has any other comments to share, I'll take them into 
consideration when I send an update to this.  (Note: I'm not 
measuring a consensus here, just making and editing a proposal.  The 
text would go into the DNSSECbis documents.)