[dns-operations] Google DNS ignores DNSSEC validation failure
Viktor Dukhovni
ietf-dane at dukhovni.org
Thu Sep 29 21:47:37 UTC 2016
> On Sep 29, 2016, at 10:27 AM, Matthäus Wander <matthaeus.wander at uni-due.de> wrote:
>
>> Note that the NSEC proof accompanying the NXDOMAIN response is valid.
>> When it asks for insecuretest.switch.ch/A
>> <http://insecuretest.switch.ch/A> the query is answered from the child
>> zone, and the name exists--even if the record doesn't. The inconsistent
>> NXDOMAIN/NOERROR response can cause a server to respond with SERVFAIL,
>> but it depends on the order the queries, among other things.
>
> Well, there is proof that a secure delegation does not exist, but also
> proof that an insecure delegation does not exist either.
>
>> dig ds insecuretest.switch.ch +dnssec +norec @ns2.switch.ch
>> [...]
>> observium.inoc.switch.ch. 180 IN NSEC snmp-trap.int.switch.ch. CNAME RRSIG NSEC
>> observium.inoc.switch.ch. 180 IN RRSIG NSEC 13 4 180 20161017041346 20160919120546 46460 switch.ch. WBYWM+chArpfc1VpA7qvVrxY9xmr8Fb2N74hLqgi6Z2hsgbVU99tpLZs fpWfgolcHi/SbENdFL572jvTKROKiQ==
>
> Is degradation to insecure resolution really an option here? This would
> imply, an attacker can spoof an unsigned response despite a secure
> denial of existence in the parent zone.
I say that the @8.8.8.8 response is incorrect. Authenticated NXDOMAIN
for the DS RRset is *not* an insecure delegation, and consequently insecure
answers for the child domain are bogus. Otherwise indeed an MiTM is free
to create insecure (otherwise non-existent) sub-domains out of thin air.
This may, for example, downgrade DANE security for SMTP in edge cases.
If one considers a case in which a legacy MX host has been retired but
still appears in the MX record pending deletion:
example.com. IN MX 10 newimproved.example.com. ; NOERROR AD=1
example.com. IN MX 20 mothballed.example.com. ; -"-
newimproved.example.com. IN A 192.0.2.1 ; -"-
_25._tcp.newimproved.example.com. IN TLSA 3 0 1 ... ; -"-
mothballed.example.com. IN A ? ; NXDOMAIN AD=1
Then it would be bad if an attacker could resurrect said MX host from
the dead, with insecure A/AAAA records. The attacker could the block
connections to the primary MX host, and downgrade email delivery to
cleartext via the deleted MX host.
I very much doubt that DNSSEC is supposed to work this way.
--
Viktor.
More information about the dns-operations
mailing list