[email protected] 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 <[email protected]> > Sender: [email protected] > Date: Tue, 10 Aug 2010 10:01:26 > To: [email protected]<[email protected]> > 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 _______________________________________________ Opendnssec-user mailing list [email protected] https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
