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?)

Unbound
1

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).
However the validation works fine for existing domains. I haven't seen something
similar in other TLDs.

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.

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

(attachments)

com_net_org_proofs-of-nonexistence.nsec3_records (17.8 KB)
com_net_org_proofs-of-nonexistence.nsec_records (3.4 KB)
com_net_org_proofs-of-nonexistence.rrsig_records (61.1 KB)
com_net_org_proofs-of-nonexistence.dig (1.98 KB)

2

Hi Ondrej,

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

3

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.

Hm. I tracked the reason for failing validation down to two possibilities or
combination thereof, but not sure which is true:

i) Something has changed in the com/net/org TLD with the NSEC3 around 3 months
back, probably by setting the opt-out bit on NSEC3 records or creating more gaps
with NSEC3 records that have the opt-out bit set. I should have some old scan of
.com TLD, but it'll take me some time to retrieve it and compare the records.

ii) Some old version of unbound does not handle this case and sets the AD flag
(see below).

I am fairly sure that the com/net/org non-existent validation was "working" 3-4
months ago, some other people I asked remember it this way, too (I used it quite
a lot for testing DNSSEC Validator and other SW).
I wrote "working" in quotes because I'm not 100% sure if it was due to a change
in the zones or a bug/missing feature in unbound or bind. Though I think bind
did validate the nonexistent com/net/org domains as well back then.

The machine at 193.29.206.206 that sets the AD flag for optout NSEC3
NXDOMAIN fails to implement RFC5155.

I've just asked admins today and the 193.29.206.206 machine runs unbound
1.4.6-1 from Ubuntu Lucid.

Does anyone know since when do the com/net/org NSEC3s have the opt-out bit set?

Ondrej

4

Not speaking for org, but com and net have had the opt-out bit set the entire time they have been signed.

5

Hi Ondrej,

i) Something has changed in the com/net/org TLD with the NSEC3
around 3 months back, probably by setting the opt-out bit on NSEC3
records or creating more gaps with NSEC3 records that have the
opt-out bit set. I should have some old scan of .com TLD, but it'll
take me some time to retrieve it and compare the records.

ii) Some old version of unbound does not handle this case and sets
the AD flag (see below).

I am fairly sure that the com/net/org non-existent validation was
"working" 3-4 months ago, some other people I asked remember it
this way, too (I used it quite a lot for testing DNSSEC Validator
and other SW). I wrote "working" in quotes because I'm not 100%
sure if it was due to a change in the zones or a bug/missing
feature in unbound or bind. Though I think bind did validate the
nonexistent com/net/org domains as well back then.

The machine at 193.29.206.206 that sets the AD flag for optout
NSEC3 NXDOMAIN fails to implement RFC5155.

I've just asked admins today and the 193.29.206.206 machine runs
unbound 1.4.6-1 from Ubuntu Lucid.

So, it is a bug in an older version of unbound, which has already been
fixed (ii)? Ah yes, in 1.4.7 there is this bugfix: Abide RFC5155
section 9.2: no AD flag for replies with NSEC3 optout.

Does anyone know since when do the com/net/org NSEC3s have the
opt-out bit set?

The authority servers are not the problem here, the older version of
unbound does not set the AD flag correctly for NXDOMAIN responses with
optout.

Best regards,
   Wouter

6

Thanks, this is likely the reason I remember the validation "working". I went
through some of older recorded scans of .com from May and the .com NSEC3s were
'insecure' back then, too. I'd guess it will be the same with .net TLD.

Ondrej