-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Ondrej,
On 01/01/2013 11:19 PM, Ondrej Mikle wrote: > Hi, > > I've noticed that since some time ago the queries for non-existent > .com, .net and .org domains no longer validate (no AD flag, > libunbound marks them as insecure). It has always done that (to my knowledge): treat NSEC3 optout appropriately. > However the validation works fine for existing domains. I haven't > seen something similar in other TLDs. nsec3-optout makes stuff insecure (not secure and not bogus). Thus, NXDOMAINs, and unsigned delegations, in the optout space get no AD flag. > I've tested it with latest unbound 1.4.19 and older 1.4.16, as well > as RHEL's bind 32:9.8.2-0.10.rc1.el6_3.6, always with identical > result. The machine at 193.29.206.206 that sets the AD flag for optout NSEC3 NXDOMAIN fails to implement RFC5155. Best regards, Wouter > > Example (default resolver is unbound on localhost) : > > Following queries validate fine : > > dig +dnssec dnsviz.net #existing domain dig +dnssec > lkjfdshsldkjhgsldkfhglkcxvbxclks-sdf.cz #non-existent domain dig > +dnssec lkjfdshsldkjhgsldkfhglkcxvbxclks-sdf.se #non-existent > domain > > Following NXDOMAIN queries do not validate (no AD flag) : > > dig +dnssec lkjfdshsldkjhgsldkfhglkcxvbxclks-sdf.net dig +dnssec > lkjfdshsldkjhgsldkfhglkcxvbxclks-sdf.net @217.31.204.130 > > Strangely enough, I've found one ODVR that validates the .com, > .net, .org proofs of non-existence (fpdns says it's Raiden DNSD): > > dig +dnssec lkjfdshsldkjhgsldkfhglkcxvbxclks-sdf.net > @193.29.206.206 > > > I've looked at the NSEC3 records and RRSIG timestamps, keytags, > algorithms, but can't figure out what makes the difference between > proofs for existent and non-existent .net domains. > > For instance RRSIG for DS record of dnsviz.net has the same keytag > as RRSIG for NSEC3 of the sample non-existent > lkjfdshsldkjhgsldkfhglkcxvbxclks-sdf.net, algorithm in RRSIG > records is the same, signer is also identical. See the attached > list of parsed RRSIG, NSEC3 and NSEC records corresponding to the > domains in question. > > Currently I'm out of ideas what could cause this, I've also tried > refreshing root trust anchor using the 'unbound-anchor' utility, > but the result did not change. > > If I'm reading the dig's output correctly, the NSEC3 opt-out bit is > set in the responses for lkjfdshsldkjhgsldkfhglkcxvbxclks-sdf.net - > though that'd make the one response with AD bit set even stranger. > > > Thanks, Ondrej > > > > _______________________________________________ Unbound-users > mailing list [email protected] > http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJQ5DSNAAoJEJ9vHC1+BF+NRoMP/jseuCsT398MNB9V2Kkn35ar NqtDX9IGvXYFChipVXoY0lkIFM0rXLn4+guwmYFZCzykkVnX1pxQpQUrfoBNyyZK 2J46FcjXoP+kkT8jpVtN93bvhYoqwmDLnv9S8Ob5fxWwxcyX3FoQuQNSmR6XlSYq +vSK2GexY4KFDtK3a0ab32tS4MmVTplzH7wgtHW8in5DuhI6agI0ON8SqvT7o1vJ X2aU6PpVTKN4dmwZlt5XKGjb/L8jJ1nk2DJGIoy2v1ZZ1rZX6BIa6+Z0HkUT1gur 9Kz5xKZ920rCDHgKN6PPVlYtsxb20adZCsmIu5g8uREFaQnqWi7XhIDf93Ut5Co4 s5FH6Ro+mskgINGy4PZN+jJOdIMuh2eXbZ8qRfod7fitmp43dGGs7103xYq63ZfK l0i3ytfcQW6XezT0hBlBS5VhuhztRX7iWL2HRAPbZJVeODoaHZYWoz1I60Iil5pw 6daTjdRtsB7R7BbJ/7OBD9n1JvawkH5x7VlmcCnraOUBjDQfYzMmWed5IbFDuJNH qOWA5V5iN+Wnwkn9H2D4QKXH+/IHBXHwCTvDTYZ7SvdopYQtFC3DlhB3C86+Ua7M /mygNMim6sOLDtqaVD+ldFh0/F9XCywp719IeP4bdRrq8HA2p4xzugR7q/I962Yb e0xNeBVHGenQZ3mkInxJ =WmOc -----END PGP SIGNATURE----- _______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
