[Opendnssec-develop] NSEC next_domain in canonical form

[Alexd at nominet.org.uk]

Hi - 

I've been looking at the problems reported by Dave Knight to OpenDNSSEC, 
where a zone with :

B.in-addr-servers.arpa.          3600            IN              NSEC   
C.in-addr-servers.arpa. A AAAA RRSIG NSEC

will not verify correctly in the auditor (it does with bind and ldns).

The problem is with the capital "C" in the NSEC record. RFC 4034 states :

The Next Domain field contains the next owner name (in the canonical
   ordering of the zone) that has authoritative data or contains a
   delegation point NS RRset

The canonical ordering section then states :

For the purposes of DNS security, owner names are ordered by treating
   individual labels as unsigned left-justified octet strings.  The
   absence of a octet sorts before a zero value octet, and uppercase
   US-ASCII letters are treated as if they were lowercase US-ASCII
   letters.

In dnsruby, I had taken this to mean that the NSEC record should contain 
the canonical form of the next domain in the canonically sorted zone.

So, when dnsruby calculates the signature of an RRSet, it uses the 
canonical form of the NSEC record. In this case, that means changing 
"C.in-add-servers.arpa" to "c.in-addr-servers.arpa", just like it changes 
the "B.in-addr-servers.arpa" to "b.in-addr-servers.arpa". This gives it a 
different message digest to ldns (which downcases the "B", but keeps the 
"C" upcase).

So, I was wondering if it was just me who took a different interpretation 
away from the spec, or whether this should be clarified somewhere. I was 
also hoping that somebody could give me a definitive answer on what the 
right thing to do with an NSEC next_domain is. It does seem odd to me that 
this is not canonicalised - after all, it already obeys the "no 
compression" rule for canonical names...

[Side question - if I'm wrong, then what happens if the domain name in the 
next_domain field is spelled in several different mixed-case ways in the 
zone? Which one makes the NSEC record?]

Thanks,


Alex.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20100324/9cd8f4fc/attachment.htm>