[Unbound-users] Strange validation errors for proofs of non-existence in .com, .net, .org TLD (is it due to NSEC3 opt-out or I am missing some trust anchor?)

[W.C.A. Wijngaards]

-----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 Unbound-users at unbound.net 
> 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-----