[dns-operations] Google DNS ignores DNSSEC validation failure

[Edward Lewis]

On 9/29/16, 18:19, "dns-operations on behalf of Daniel Stirnimann" <dns-operations-bounces at dns-oarc.net on behalf of daniel.stirnimann at switch.ch> wrote:

>I've added an unsigned zone insecuretest.switch.ch but did not add the
>delegation in the parent zone. Thus, on validating resolvers a lookup
>returns SERVFAIL.

The complicating factor is that the servers for switch.sh and the servers for insecuretest.switch.ch are the same.

When the DNS server(s) are asked a question, they choose the data from the "longest match" zone the server has.

So, when asked for the SOA or NS set, the answer comes from the zone insecuretest.switch.ch.  When asked for the DS, the answer comes from the zone switch.ch.

The SOA and NS set queries return answers, because the insecuretest.switch.ch zone is not aware the parent hasn't delegated it.  (Orphan?  Illegitimate child?).  The DS query at the parent returns that there is not DS record but that the name does not exist - which is the really confusing angle here.  The NXDOMAIN say that there shouldn't be a name to hold the SOA and NS answers the servers are returning.

There's no right answer here.  Perhaps coincidently, there is a document in the IETF covering this, saying that the recursive server can or ought to prioritize the NXDOMAIN over seeing answers below.

The confusion in DNSSEC validation is that, not only is the DS not there, concluding the delegation goes unsigned, the delegation isn't there either.  Scratching my head, this would mean the resolver ought to discard the NS and SOA records already on hand.

However, if it were the case that, minutes ago, insecuretest.switch.ch was legitimately delegated as insecure and the NS and SOA learned, then the delegation (in the parent was deleted) before the DS query came, the resolver arguably could still rely on the NS and SOA records.

Keeping in mind that this is a "broken set up" and the resolver never has complete knowledge of what is in the authoritative server's configuration (the zone set) as part of the protocol's design, there is no single right answer for a validating resolver to return.  Garbage in, garbage out, in a sense.

Aside - that document, I had just commented on this issue potential happening.  My conclusion there (also) was "it's up to the implementer because there's no single right answer."  In this case, out-of-band (the email thread) what is indicated is that the NXDOMAIN ought to trump the lower records, but the DNS protocol can't necessarily know this via the in-band channel.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2013 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20161002/7bf250e4/attachment.bin>