Subject: NSEC3 Issue 11, revisited.

From: David Blacka <[email-masked]>
Date: Thu, 24 Aug 2006 14:31:30 -0400

The NSEC3 draft editors are working toward publishing version -07 of
this draft, the main focus of which is addressing currently open issues.
 To that end, I'm going to bring up some open issues that haven't gotten
sufficient (or any) discussion on this mailing list, at least about
their current form.

The first of these is NSEC3 Issue 11: Queries for NSEC3 RRs.
(<http://www.nsec3.org/cgi-bin/trac.cgi/ticket/22> for reference).

The recap the background of this issue:  This is all about the paradox
or contradiction caused by NSEC3 RR owernames not being represented in
the NSEC3 chain itself.  That is if if a.example.com is in the zone,
then a.example.com is represented in the NSEC3 chain has
H(a.example.com).  However, that name is not also in the chain as
H(H(a.example.com)).  This particular issue comes up when trying to
construct a NOERROR/NODATA response when the qname is an NSEC3 hashed
ownername, but qtype is not NSEC3.

The current version of the NSEC3 draft, draft-ietf-dnsext-nsec3-06
(http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-nsec3/draft-ietf-dnsext-nsec3-06.txt),
in sections 6.2.8 and 7.10 describes a special case for this sort of
response where the response includes an NSEC3 RR that "directly covers"
the qname (instead of the hash of the qname, as is normal).

In the Frankfurt workshop in March, there was a preference expressed for
a different solution to this problem: essentially to treat NSEC3 RRs as
if they don't really exist for query purposes (obviously, still
returning them in AXFR/IXFR responses, and in the authority section of
normal responses).  The advantages to this approach are:

  * No special case in the validator logic.
  * and thus, presumably simpler to implement.

Some disadvantages might be:

  * It does create a special case for the authoritative server, however,
it could be argued that it is a natural special case to handle.
  * you could not directly query for NSEC3 RRs.

It was noticed during the Frankfurt workshop that no direct queries for
NSEC3 records were actually done.

Based on feedback received in the workshop and on the nsec3-testing
list, the editors are inclined to change this behavior in the -07
version of the draft.  However, we seek guidance from the WG.

-- 
David Blacka                      <[email-masked]>
Sr. Engineer    VeriSign Infrastructure Product Engineering

--
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: Mark Andrews <[email-masked]>
Date: Fri, 25 Aug 2006 10:08:21 +1000

> version of the draft.  However, we seek guidance from the WG.

	In favour.
 
--
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DHCP.  Email [email-masked].
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Wouter Wijngaards <[email-masked]>
Date: Fri, 25 Aug 2006 09:41:56 +0200

>> version of the draft.  However, we seek guidance from the WG.

Could this decision be in terms of protocol instead of server
implementation?
So, I would prefer if the draft terms this decision in terms of response
to queries, not in terms of implementation guidance. NSEC3 records
exist, obviously (in AXFRs), but are not answered for; only the nxdomain
response to a node with only NSEC3+RRSIG remains as a special case. This
special case is to help validators.

You may notice I am in favor of existing NSEC3s, because then you can
query for them directly (if that need ever arises). You can stop queries
for them, but then if you ever want an NSEC3 you have to query for the
domain name original (i.e. know the reverse of the hash) to get the
server to include it in a response, and you have to guess a type-code
that does not exist at that domain. Anyway, if its not needed and
complicated, we can drop NSEC3 responses.

I can imagine wanting to query for an NSEC3 to see what RR types exist
at a domain name. Though I have no examples of types :-)

Best regards,
   Wouter

---

From: David Blacka <[email-masked]>
Date: Fri, 25 Aug 2006 09:22:10 -0400

> Could this decision be in terms of protocol instead of server

I'm not sure what you are asking here.  Are you asking that the WG
ignore implementation concerns for this issue?

> special case is to help validators.

The draft always describes the solution to this issue strictly in term
of protocol.  Well, at least I think it does.  Here is my text for the
forthcoming -07 version on this issue (the other option is sections
6.2.8 and 7.10 in -06):

7.2.8.  Responding to NSEC3 Queries

   Since NSEC3 ownernames are not represented in the NSEC3 chain like
   other zone ownernames, direct queries for NSEC3 ownernames present a
   special case: NSEC3 ownernames cannot be proven to exist, in general.

   If the following conditions are all true:

   o  The QNAME equals an existing NSEC3 ownername, and
   o  There are no other record types other than RRSIG existing at
      QNAME,

   Then the response MUST be constructed as a Name Error response
   (Section 7.2.2).  Or, in other words, the authoritative nameserver
   will act, for direct query purposes, as if the NSEC3 ownername did
   not exist.

   Note that NSEC3 RRs are returned as a result of an AXFR or IXFR
   query.

> complicated, we can drop NSEC3 responses.

I think it is a bit weird to have a record that clearly exists in the
zone, but cannot be directly queried.  However, this is, essentially, a
direct consequence of putting what is, for all practical purposes,
meta-data in the zone as records.

I'm pretty neutral, personally, on which of the two leading solutions to
this issue that is chosen.  I see them mostly as shifting the special
case around.  Although, in terms of draft column-inches, the -07 version
is 1/4 the size.

> at a domain name. Though I have no examples of types :-)

I'm having a hard time imagining when you would know the NSEC3 ownername
but not have the NSEC3 record in your possession.  I also think it will
be practically easy to guess a nonexistent type for a name (I like NULL,
personally).

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 25 Aug 2006 16:14:29 +0200

Hiya Ed,

As for context, you wrote:
>
>  h(registrant.example.).example. NSEC3 next-hash.example. NS NSEC3  
> RRSIG
>                                        RRSIG NSEC3 expires Sat  
> starts Mon
>

...
>
> The question is, what would I update via dynamic update to trigger  
> a regeneration of the RRSIG?  I can trigger NSEC's RRSIG to be hit  
> by updating
> the NS set.  I can't update the NSEC itself, nor the RRSIG.
>
> With the difference between the owner names for the NS set and  
> NSEC3 set, can we still rely on an update to the NS set hitting the  
> NSEC3 set?  Or will there be a need to address it directly now?

How do you manage that today? Are you keeping state of all your  
updated records in order to regenerate signatures? How about the  
NSEC3 RRs that come prior to the introduced H 
(registrant.example).example NSEC3 RR? These all have to be  
maintained and I think it is the master server that is 'responsible'  
for doing that not the dynamic client.

So, I do not think this is an protocol issue, or at least not a  
distinguished difference between NSEC and NSEC3.

--Olaf  (namedropper)

PS. I use secure dynamic updates with my laptop. The laptop updates  
the DNS whenever it thinks its suitable. My DNS server (bind9)  
generates/modifies/delete the appropriate NSEC and the appropriate  
RRSIGs and does the appropriate magic at deletion and introduction of  
the RR.  In order to make sure that signatures do not expire if RRs  
are not updated regularly a cronjob does a regular freeze; SOA bump;  
sign; unfreeze operation.

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: Wouter Wijngaards <[email-masked]>
Date: Fri, 25 Aug 2006 16:22:55 +0200

> forthcoming -07 version on this issue (the other option is sections

OK I agree with the text you have shown. Wanted to make sure it was only
protocol :-)

> meta-data in the zone as records.

Exactly my issue with it.

> case around.  Although, in terms of draft column-inches, the -07 version

I think both solutions are fine too, for this special case.

> be practically easy to guess a nonexistent type for a name (I like NULL,

Bit of a kludge to fix the fix on queries with NSEC3 qtype. But it'll work.

Best regards,
   Wouter

---

From: Edward Lewis <[email-masked]>
Date: Fri, 25 Aug 2006 10:32:20 -0400

At 16:14 +0200 8/25/06, Olaf M. Kolkman wrote:

>How do you manage that today? Are you keeping state of all your updated
>records in order to regenerate signatures? How about the NSEC3 RRs that
>come prior to the introduced H(registrant.example).example NSEC3 RR? These
>all have to be maintained and I think it is the master server that is
>'responsible' for doing that not the dynamic client.

Today - I don't do anything.

I've just been bemused by BIND's maintenance of the RRSIG and NSEC 
records and how that can be used to managed a stable signed zone, 
i.e., a zone where the only changes are the expiration of signatures.

>So, I do not think this is an protocol issue, or at least not a distinguished
>difference between NSEC and NSEC3.

I haven't found anything that says dynamic updates shouldn't allow 
changes to NSEC records, but the one implementation I know of (BIND) 
bars this.  I'm just asking now, maybe there needs to be some 
protocol definition of this.

Note - this is not NSEC3 specific.

But, the reason I ask now as part of NSEC3 is that the owner names 
are different (whereas in NSEC-land they are the same).

>--Olaf  (namedropper)
>
>PS. I use secure dynamic updates with my laptop. The laptop updates the DNS
>whenever it thinks its suitable. My DNS server (bind9) generates/modifies/
>delete the appropriate NSEC and the appropriate RRSIGs and does the
>appropriate magic at deletion and introduction of the RR.  In order to make
>sure that signatures do not expire if RRs are not updated regularly a cronjob
>does a regular freeze; SOA bump; sign; unfreeze operation.

The latter part is what I am thinking about, but the option of freeze 
is not there.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Secrets of Success #107: Why arrive at 7am for the good parking space?
Come in at 11am while the early birds drive out to lunch.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 25 Aug 2006 09:53:10 -0400

>be practically easy to guess a nonexistent type for a name (I like NULL,

Perhaps this will be a separate issue - or maybe just a question, but 
I am thinking of dynamic update and the capability of a name server 
to maintain time-valid signatures.

For a delegation from the zone I manage, I may see this today:

        registrant.example. NS ns1.parkeddomain.example.
                            NS ns2.parkeddomain.example.

Once I sign my zone (example., that is) I will see this for the delegation:

        registrant.example. NS ns1.parkeddomain.example.
                            NS ns2.parkeddomain.example.

        h(registrant.example.).example. NSEC3 next-hash.example. NS NSEC3 RRSIG
                                        RRSIG NSEC3 expires Sat starts Mon

(For reference only, here is what I'd see with NSEC:

        registrant.example. NS    ns1.parkeddomain.example.
                            NS    ns2.parkeddomain.example.
                            NSEC  next-registrant.example. NS NSEC RRSIG
                            RRSIG NSEC expires Sat starts Mon
)

The question is, what would I update via dynamic update to trigger a 
regeneration of the RRSIG?  I can trigger NSEC's RRSIG to be hit by 
updating
the NS set.  I can't update the NSEC itself, nor the RRSIG.

With the difference between the owner names for the NS set and NSEC3 
set, can we still rely on an update to the NS set hitting the NSEC3 
set?  Or will there be a need to address it directly now?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 25 Aug 2006 11:07:31 -0700

>>>>> "DB" == David Blacka <[email-masked]> writes:

DB> If the following conditions are all true:

DB> o  The QNAME equals an existing NSEC3 ownername, and
DB> o  There are no other record types other than RRSIG existing at
DB> QNAME,

[if you don't want the long winded proof that I had to think through
myself anyway, skip to the suggestion at the bottom]

So, if I read this right then if I have

  a.example.    A 10.0.0.1

which produces via signing:

  a.example.    RRSIG ...
  H(a).example. NSEC3 ...
  H(a).example. RRSIG ...

and then someone comes along (being the someone they are) and registers:

  H(a).example. A 10.0.0.2

Then the resulting data will be:

  a.example.       A 10.0.0.1
  a.example.       RRSIG ...
  H(a).example.    NSEC3 ...
  H(a).example.    RRSIG(NSEC3) ...
  H(a).example.    A 10.0.0.2
  H(a).example.    RRSIG(A) ...
  H(H(a)).example. NSEC3 ...
  H(H(a)).example. RRSIG(NSEC3) ...

By the above rules if I wildcard query for H(a) then I'd get back the
NSEC3 of a stored at H(a) right?  Does the NSEC3 bitmap at H(H(a))
state the NSEC3 record at H(a) does or doesn't exist?  Does I believe,
right?  In which case it'd have to be returned or the validation of a
NSEC3 record must ignore the NSEC3 bit itself.

Because I have a never ending desire for making situations worse, lets
consider the transition phase when both NSEC and NSEC3 records exist.
Now we have:

  a.example.       A 10.0.0.1
  a.example.       RRSIG ...
  a.example.       NSEC(H(a) = A,RRSIG, NSEC) ...
  H(a).example.    NSEC3(a = (A, RRSIG, NSEC)) ...
  H(a).example.    RRSIG(NSEC3) ...
  H(a).example.    A 10.0.0.2
  H(a).example.    RRSIG(A) ...
  H(a).example.    NSEC(H(a) = A, RRSIG, NSEC, NSEC3) ...
  H(a).example.    RRSIG(NSEC) ...
  H(H(a)).example. NSEC3(H(a) = RRSIG, A, NSEC, NSEC3) ...
  H(H(a)).example. RRSIG(NSEC3) ...
  H(H(a)).example. NSEC(H(H(a)) = NSEC, NSEC3?, RRSIG) ...
  H(H(a)).example. RRSIG(NSEC) ...

So...  Now the fun really begins.

Lets say I query for a.  I get the NSEC3 at H(a) along with the NSEC
at a back.  Easy enough.  If I query for ANY at H(a) then I get back
all the records there plus the NSEC3 at H(H(a)) for proof that I got
everything.  Easy enough.  If I query for ANY at H(H(a)) then I get
back all the data at H(H(a)) with an NSEC there proving I got
everything but no NSEC3 showing I got everything (or else H(H(H(a)))
would have to exist, as would H^4(a), etc.  you know the drill.)

So I don't think the text works to protect you against duplicate
deployments of NSEC with NSEC3.  Additionally, what happens when you
deploy NSEC3s with different properties?  If both are to be returned
when possible I think you'll run into a similar case though I haven't
walked through it.

That was a lot of text to justify suggesting:

o  The QNAME equals existing NSEC, NSEC3 or other
   proof-of-non-existence records, and
o  There are no other record types other than RRSIG existing at
   QNAME,

-- 
Wes Hardaker
Sparta, Inc.

---

From: David Blacka <[email-masked]>
Date: Fri, 25 Aug 2006 15:05:35 -0400

> NSEC3 record must ignore the NSEC3 bit itself.

In (I think) the -06 rules, you would technically have the NSEC3 bit set
in the H(H(a.example)).example NSEC3 record.  However, with the
suggested rule for -07, it would not.  Which is easier anyway, since
actually setting the NSEC3 bit requires the signer to do a 2nd pass
through the generated hashes.

> at a back.  Easy enough.  

Wait a minute here. Are you imagining a server that is both returning
NSEC and NSEC3 based proofs?  I'm not sure why anything would ever do that.

> If I query for ANY at H(a) then I get back all the records there plus
> the NSEC3 at H(H(a)) for proof that I got everything. Easy enough.

Why would the NSEC3 for H(H(a)) be returned?  I don't think that would
happen.

> If I query for ANY at H(H(a)) then I get back all the data at H(H(a))
> with an NSEC there proving I got everything but no NSEC3 showing I
> got everything (or else H(H(H(a))) would have to exist, as would
> H^4(a), etc. you know the drill.)

Where does this "NSEC3 showing I got everything" come from?  I've never
heard of this behavior.

> when possible I think you'll run into a similar case though I haven't

I don't think that this is a realistic scenario.  Returning two set of
negative proof records is not something envisioned by the NSEC3
proposal.  And it seems (to me, at least) something not worth
engineering around.

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 25 Aug 2006 13:00:32 -0700

>> NSEC3 record must ignore the NSEC3 bit itself.

DB> In (I think) the -06 rules, you would technically have the NSEC3 bit set
DB> in the H(H(a.example)).example NSEC3 record.  However, with the
DB> suggested rule for -07, it would not.  Which is easier anyway, since
DB> actually setting the NSEC3 bit requires the signer to do a 2nd pass
DB> through the generated hashes.

If NSEC3 records didn't set bits for NSEC3 types it'd certainly be
better, IMHO.  I hadn't seen that explicitly stated though.

>> Lets say I query for a.  I get the NSEC3 at H(a) along with the NSEC

DB> Wait a minute here. Are you imagining a server that is both returning
DB> NSEC and NSEC3 based proofs?  I'm not sure why anything would ever
DB> do that.

I heard people discussing that at the last NSEC3 workshop at the last
IETF.  I agree I think it's silly and thus I'd suggest putting a "MUST
NOT return both NSEC and NSEC3" records in the NSEC3 draft.

>> the NSEC3 at H(H(a)) for proof that I got everything. Easy enough.

DB> Why would the NSEC3 for H(H(a)) be returned?  I don't think that would
DB> happen.

You're right it wouldn't.  But I didn't say "for" I said "at"...  IE,
the NSEC3 record with a name of H(H(a)) would be returned proving
non-existence of H(a).

>> H^4(a), etc. you know the drill.)

DB> Where does this "NSEC3 showing I got everything" come from?  I've
DB> never heard of this behavior.

Sorry.  How about "proving nothing else exists".  IE, when you query
for ANY you get back the data plus a NSEC record showing you that you got
it all (and the signature on it of course):

dig +short www.dnssec-tools.org ANY
;; Truncated, retrying in TCP mode.
66.35.250.210
A 5 3 14400 20060917162053 20060818162053 42869 dnssec-tools.org. Hjl3agQilrL6aEi3jcccdtoiqKP8+mQIX++BNF1L46PktX6qhX8k10Xg 2MWN0Mt1TkTJQgt2TegypqmPogKuOIKOl3BeOF9vo2uLZcb9s9oylDP9 kkq+fsKsxVIbtoP29ilgRvKiq4tM0L4faK8S9rSI9+IHizONCxmHjzMq hp2/eu+KHUQ0A7nTkXj5hyY+KYIB9R9rTlqOczTpAoZeAOXbirCivWFW VvQaN4o5sOmPhrY63QUM6PsrdAmX/fuQs3qIgUSTAfR8uQmXRD97E8eT ZvOXFyRKPh414n9cCX//JzUBqx619Xqt7eQCTIk+3kxisF7HiTcyH0qE 9wxx0A==
dnssec-tools.org. A RRSIG NSEC
NSEC 5 3 10800 20060917162053 20060818162053 42869 dnssec-tools.org. SikARJVu5j2GaHIKlGra3QBU2TIYCMOelcOJslA6gtzV7BucZh3jF4Dd P64GIllYWwobYfKB6z4d08ysXKnEYUgL4D3ekdk7FFsJRpw6Fz7wiU9A zZmfrewOjABFppI38Gb5XXxoq7yK88dYmlA2lt+JvhKSn5adhPZgn2zx X98knxllC0e2g5kJscxK1jhQaGGUEQVdvoRAvhXeGY88GqarHGi3jxvd oScfvwklKJuogcXbSE8Ap6D0KlgiMDGGHBj/9zxFO4o0l4x+un5X30IJ Sgag4Jn6Vyee7Gg1G+C1S3IlqkqijCKCvvwP2I+twNitbTAUB5+UYVb9 09XEtQ==

>> when possible I think you'll run into a similar case though I haven't

DB> I don't think that this is a realistic scenario.  Returning two set of
DB> negative proof records is not something envisioned by the NSEC3
DB> proposal.  And it seems (to me, at least) something not worth
DB> engineering around.

I've heard on multiple occasions people discussing multiple NSEC3
chains with different algorithms or different iteration settings.
These cases will prove interesting as well...

As far as engineering around, I wasn't.  I was merely changing the
text to be more inclusive of all negative types not just NSEC3.  The

>> o  There are no other record types other than RRSIG existing at

And also forward looking...
-- 
Wes Hardaker
Sparta, Inc.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 26 Aug 2006 08:15:59 +1000

I think the signer should generate NSEC3 records that ignore
	any NSEC records at the node.  I also think the signer
	should ignore NSEC3 records and nodes with only NSEC3 records
	when generating NSEC records.

	This allows for the instantaneous transition from generating
	NSEC proofs to generating NSEC3 proofs by just adding the
	the NSEC3 for the apex (or whatever we choose the signalling
	to be).  The reverse is also true.  See my transition text.

---

From: David Blacka <[email-masked]>
Date: Fri, 25 Aug 2006 17:05:03 -0400

> better, IMHO.  I hadn't seen that explicitly stated though.

It wasn't stated, but it is a good point, so it will be.

> the NSEC3 record with a name of H(H(a)) would be returned proving

Returned when?

> it all (and the signature on it of course):

You get back the NSEC record because it is one of the records at the
QNAME.  Not because DNSSEC added some requirement to return the NSEC as
part of the ANY response.  That is, you don't get back the "data plus a
NSEC".  You just get back the data.

> These cases will prove interesting as well...

There will be language in -07 that says that the server should just pick
one in that case.

> text to be more inclusive of all negative types not just NSEC3.  The

The text change was trivial, but I don't think it would work.

> And also forward looking...

So, if you actually have NSEC and NSEC3 in the same zone (so your change
would actually apply), then there will be zero times when QNAME equals
an existing NSEC but there are no other record types other than RRSIG.

So, in essence, your text change wouldn't actually change anything.

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 25 Aug 2006 13:07:22 -0700

>>>>> "WH" == Wes Hardaker writes:

WH> I've heard on multiple occasions people discussing multiple NSEC3
WH> chains with different algorithms or different iteration settings.

Which, btw, doesn't actually affect the current text.  I realized the
sentence above makes it sound like I was worried about it but I'm
not...  Either way, multiple algorithms are still NSEC3 records and
thus the current text treats them just fine.

-- 
Wes Hardaker
Sparta, Inc.