<font size=2 face="sans-serif">Hi - </font>
<br>
<br><font size=2 face="sans-serif">I've been looking at the problems reported
by Dave Knight to OpenDNSSEC, where a zone with :</font>
<br>
<br><font size=2 face="sans-serif">B.in-addr-servers.arpa.    
     3600            IN  
           NSEC        
   C.in-addr-servers.arpa. A AAAA RRSIG NSEC</font>
<br>
<br><font size=2 face="sans-serif">will not verify correctly in the auditor
(it does with bind and ldns).</font>
<br>
<br><font size=2 face="sans-serif">The problem is with the capital "C"
in the NSEC record. RFC 4034 states :</font>
<br>
<br><tt><font size=3>The Next Domain field contains the next owner name
(in the canonical<br>
   ordering of the zone) that has authoritative data or contains a<br>
   delegation point NS RRset</font></tt>
<br>
<br><font size=2 face="sans-serif">The canonical ordering section then
states :</font>
<br>
<br><tt><font size=3>For the purposes of DNS security, owner names are
ordered by treating<br>
   individual labels as unsigned left-justified octet strings.  The<br>
   absence of a octet sorts before a zero value octet, and uppercase<br>
   US-ASCII letters are treated as if they were lowercase US-ASCII<br>
   letters.<br>
</font></tt>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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).</font>
<br>
<br><font size=2 face="sans-serif">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...</font>
<br>
<br><font size=2 face="sans-serif">[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?]</font>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br>
<br>
<br><font size=2 face="sans-serif">Alex.</font>