[dns-operations] Google DNS ignores DNSSEC validation failure

[Matthäus Wander]

* Casey Deccio [2016-09-29 15:17]:
> I can't speak for Google, but in general how this is handled depends on
> resolver implementation.  The SERVFAIL here isn't really because of a
> validation failure; it is because the resolver is getting inconsistent
> results when communicating with the authoritative server, while querying
> to establish a chain of trust.  When it asks for
> insecuretest.switch.ch/DS <http://insecuretest.switch.ch/DS>, the query
> is answered from the parent zone (switch.ch <http://switch.ch>), and the
> result is NXDOMAIN because there is no delegation in the parent zone.
> 
> http://dnsviz.net/d/insecuretest.switch.ch/V-0R1g/dnssec/
> 
> 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.

Regards,
Matt

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5523 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160929/f63cdfe3/attachment.bin>