[Opendnssec-user] NSEC3 records with empty Type Bit Maps field?

[Sebastian Castro]

hsalgado at nic.cl wrote:

Hi Hugo,

Thanks for your reply.
> The empty non-terminals are part of a nsec3 chain but have an empty type bit map.
> They are spread through your zone with the canonical ordering of their hashes, but may be records of the apex zone, typically a srv record (nicname._tcp ?)
> 

Just for clarity and documentation purposes, what I initially thought as
a OpenDNSSEC turned to be a misconception of my part and a bug in a
different piece of code.

NSEC3 with empty type bit maps where generated for records like this:

example.com IN NS a.ns.example.com.
example.com IN NS b.ns.example.com.

The record was added to cover ns.example.com on the cases I saw.

And YAZVS was choking with that due to a bug in the version of
Net::DNS::SEC module I'm using. Hugo provided a patch for it.

cheers,

> Regards,
> 
> Hugo
> 
> Sent from my BlackBerry® wireless device
> 
> -----Original Message-----
> From: Sebastian Castro <sebastian at nzrs.net.nz>
> Sender: opendnssec-user-bounces at lists.opendnssec.org
> Date: Tue, 10 Aug 2010 10:01:26 
> To: Opendnssec-user at lists.opendnssec.org<Opendnssec-user at lists.opendnssec.org>
> Subject: [Opendnssec-user] NSEC3 records with empty Type Bit Maps field?
> 
> Hi:
> 
> While using Duane's tool YAZVS (http://yazvs.verisignlabs.com/) to
> verify a signed version of the co.nz zone, I stepped on a curious case.
> 
> Currently I'm signing the zone with NSEC3 without Opt-Out and there are
> 22 NSEC3 records with an empty Type Bit Maps field representation. I
> couldn't find a reference on RFC 5155 telling that value could be empty.
> 
> So a normal delegation in the signed zone will look like this:
> 
> trademe.co.nz.  86400   IN  NS  ns1.trademe.co.nz.
> trademe.co.nz.  86400   IN  NS  ns2.trademe.co.nz.
> trademe.co.nz.  86400   IN  NS  ns3.trademe.co.nz.
> trademe.co.nz.  86400   IN  NS  ns4.trademe.co.nz.
> vhquglfsgbhs4r0ri8hlphqk00kk950c.co.nz. 3600    IN  NSEC3   1 0 5
> 23b431f77625ad5d  vhqulb93jlf3mgckjs93bdtev0tgf22h NS
> vhquglfsgbhs4r0ri8hlphqk00kk950c.co.nz. 3600    IN  RRSIG   NSEC3 7 3
> 3600 20100810083824 20100808175000 53435 co.nz.
> WVr/+e6bFI2LnT3ie807q69+AI6azt+uG888w4sh0soy3w6rDq0DpaAK6edCsNhze1tGRbqsov2V98sK8QCb9uhWAdT+wQc5qB/rdfnSJJP36klaYqbsRZrkhRYPHgT+94GtGxspNVEMJFl5VaSTt2maGp8gIx6Jf9bub3LNwV4=
> 
> and then the next sequence of NS+NSEC3+RRSIG will follow,
> but on the very few strange cases, it looks like this
> 
> oma-rapiti.co.nz.   86400   IN  NS  ns1.openhost.net.nz.
> oma-rapiti.co.nz.   86400   IN  NS  ns2.openhost.net.nz.
> oma-rapiti.co.nz.   86400   IN  NS  ns3.openhost.net.nz.
> rbdkpg1fmijiaah7mf7n0h1ufbtbav5b.co.nz. 3600    IN  NSEC3   1 0 5
> 23b431f77625ad5d  rbdl6o7oqkad3u8n3bm6soo4jfhgi0h2 NS
> rbdkpg1fmijiaah7mf7n0h1ufbtbav5b.co.nz. 3600    IN  RRSIG   NSEC3 7 3
> 3600 20100810053112 20100808175000 53435 co.nz.
> ZX2zvmTnW/neN+X0Yqutxq7yqcjp+I+P0ZZZbVujfu7OX77daXe8pXhua8/uMVzsYuAcf8bO7T6ECibWLWdT+R+VEv6i4qfbEoCe19e7W8FyvK0gDhMlX9Np4CtYuY4+A6zqwn5nZfUmj9uZb5G0GDg09kbAKW3xFi9U6sOsJPQ=
> ;{id = 53435}
> 
> rbdl6o7oqkad3u8n3bm6soo4jfhgi0h2.co.nz. 3600    IN  NSEC3   1 0 5
> 23b431f77625ad5d  rbdof4uj5oj1cebdk0ud74vnnr0me7ch
> rbdl6o7oqkad3u8n3bm6soo4jfhgi0h2.co.nz. 3600    IN  RRSIG   NSEC3 7 3
> 3600 20100810054536 20100808175000 53435 co.nz.
> Db6ueQIyutV0g7STy5QwE+wL7Kf8MenFVEHAdsDEEEHmKQ4lmi4SA6pDUTjTxbSsy70iERIdRCaGH7il1W0Hr9SvXWPPIS/VuoLf1Ge9u9IfW4tla3dhesJpExgFJy9CCMPkFSIkSaPRWTJYcWAegRDqHSSDhD3r5V0vW7o8vxI=
> 
> So the sequence is NS+NSEC3+RRSIG+NSEC3_with_no_type+RRSIG.
> 
> YAZVS barks with that, named-checkzone doesn't complain,
> ldns-verify-zone hasn't finished after 12 hours running.
> 
> Looks likes an OpenDNSSEC bug? is that valid or I should go and check
> YAZVS dependencies for errors?
> 
> 
> cheers,


-- 
Sebastian Castro
DNS Specialist
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 495 2337
mobile: +64 21 400535