[dns-operations] Akamai now works with ENT (Empty Non-Terminals)?

[Alexander Dupuy]

Shumon Huque asks:

> Try dig @8.8.8.8 blah.h4ha.net. A for example.
>

With BIND/Unbound/Knot, this authenticates correctly.
>
...

> Wonder why Google fails though? Is it determining that a wildcard exists,
> and thus the NSEC record must be wrong ..


Peter van Dijk replies:

> The response contains the asked-for A record. The (cryptographically
> valid) RRSIG over that mentions off-hand that it was expanded from a
> wildcard. An NSEC is included that says that ‘blah’ does not exist. I
> believe that that is a conclusion that a validator is allowed to jump to.
>
> However, the NSEC does prove that the wildcard itself does not exist and
> thus the answer makes no sense. I believe that that is also a conclusion
> that a validator is allowed to end up with, and it looks like that is what
> Google is doing.


And Viktor Dukhovni notes:

> This could be an interaction with aggressive nsec.


>From the horse's mouth: Google Public DNS returns SERVFAIL for this
response because the authority has provided a self-contradictory answer
that represents a potential vulnerability in the zone.

Shumon's speculation further on in the thread that returning SERVFAIL here
might encourages authorities to fix the problem is certainly an argument I
agree with, and it is part of the reason I chose to do this. The larger
reason is that when I was updating the code that now does not accept such
self-contradictory answers, it was part of a security cleanup in response
to Ralph Dolmans' and Karst Koymans's CVE-2017-15105 vulnerability report,
which Ralph later wrote up in an excellent blog post (
https://medium.com/nlnetlabs/the-peculiar-case-of-nsec-processing-using-expanded-wildcard-records-ae8285f236be
).

Although their report focused on wildcard NSEC records, it also
demonstrated that NSEC or NSEC3 records could be mis-used for exploits:
proving nonexistence of CAA records that did exist, or redirecting e-mail
through a wildcard MX when an MX or A/AAAA record existed for a hostname.
In that light, it seemed better not to accept these self-contradictory
proofs, since they were at best the result of a broken DNSSEC signing
process, and potentially a malicious attempt to "prove" things about the
domain that were not true. Google Public DNS makes no attempt to search out
larger self-contradictions (DNS is only eventually consistent anyhow, so
they may exist in any zone that changes), but when a single answer is
self-contradictory in this way it is rejected.

Viktor's point about aggressive NSEC synthesis based on such records is
well taken, although Google Public DNS would not do so in this case even if
it accepted the inconsistent response, since it needs an SOA record and
none was provided here (Google Public DNS aggressive NSEC only synthesizes
NXDOMAIN or NOERROR-NODATA responses, not wildcards). Another query type
that doesn't match the wildcard (such as AAAA) could be accepted, if it
were not for the fact that the authority returns NOERROR-NODATA with a
proof of NXDOMAIN. That response also gets a SERVFAIL (as it must, to
prevent forged delegation referral responses for nonexistent domains) and
therefore is not used for aggressive NSEC cache synthesis.

On a more practical note, in a previous case where an authority was
returning "bald-faced lies" (proving the nonexistence of anything but the
zone apex in a non-empty zone, in contrast to the minimal white and black
lies) we had to disable aggressive NSEC cache synthesis as it was causing
spurious negative answers. The domain was later identified as using
PowerDNS, and the solution was for them to run pdnsutil rectify-zone to
rebuild the NSEC chain (
https://community.cloudflare.com/t/leg-br-domains-failing-to-query-1-1-1-1/18379/2).
It is possible that this is all that epik.com needs to do to fix this issue.

@alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20190417/4a960614/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4849 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20190417/4a960614/attachment.bin>