Re: [DNSOP] Any suggestion on what I'm doing that is stupid here on NSEC3?

[Mukund Sivaraman <[e-mail]>]

Hi Nicholas

On Wed, Feb 12, 2014 at 07:35:47AM -0800, Nicholas Weaver wrote:
> Looking at com, the NSEC3 for "com" is:
> CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - ...
> 
> (Algorithm 1 -> SHA-1, flag = 1, iterations = 0, salt = None, fetched by "dig +dnssec MX com @a.gtld-servers.net")
> 
> Reading RFC5155, the calculation of the hash is:
> 
> [snip]
> 
> So it should be the base32 encoding of the SHA1 hash of the wire
> format for "com" (since there is no salt), which in python is:
> 
> "\x03com\x00", (3 characters, the string "com", and 0 as a terminator
> in wire format.  This matches the wire format I get from my name
> packer in my DNS server)
> 
> Yet when I try to calculate the SHA1 hash in python's library, I get:
> >>> m = hashlib.sha1() 
> >>> m.update("\x03com\x00") # There is no salt and 0 additional iterations
> >>> base64.b32encode(m.digest()) 
> 'MUAZYTWQIHEVT3OPHOPXIEDA27S5IL4W'

This is where the problem is. NSEC3 uses base32hex encoding, not
base32. See the difference in RFC 4648 section 7. It should be trivial
to convert the output of the above b32encode() to the base32hex encoding
using a simple lookup map.

If you want to look at some C++ code, clone the BIND 10 repo and look at
the following files:

src/lib/dns/nsec3hash.{h,cc}
src/lib/util/encode/base32hex.h
src/lib/util/encode/base_n.cc

I suggest avoiding the last file and just doing your own base64hex
implementation.. it can make you upset. ;)

		Mukund