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]