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

[Shumon Huque]

On Sun, Apr 14, 2019 at 3:02 PM Viktor Dukhovni <ietf-dane at dukhovni.org>
wrote:

> On Sun, Apr 14, 2019 at 11:19:09AM -0400, Shumon Huque wrote:
>
> > Not sure I have any specific suggestions, other than that the DNS
> community
> > could try to work collectively to ensure that all major DNS providers
> have
> > protocol compliant behavior.
>
> That'd be great.  One recent problem "hotspot" is epik.com, where
> I'm seeing many new problem domains showing.  These signed domains
> have only the zone apex in their NSEC chain, but TLSA queries for
> sub-domains return NODATA rather than NXDOMAIN.  This renders replies
> for TLSA queries bogus, and breaks email delivery from DANE-enabled
> senders.
>
> For example (condensed):
>
>     @ns3.epik.com.[52.55.168.70]
>     @ns4.epik.com.[45.79.4.83]
>     ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49327
>     ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
>     ;_25._tcp.h4ha.net.     IN TLSA
>     h4ha.net.               SOA     ns1.epik.com. [...]
>     h4ha.net.               NSEC    h4ha.net. A NS SOA RRSIG NSEC DNSKEY
> CAA
>
> There does appear to be a wildcard in play:
>
>     @ns3.epik.com.[52.55.168.70]
>     @ns4.epik.com.[45.79.4.83]
>     ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39918
>     ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>     ;*.h4ha.net.            IN A
>     *.h4ha.net.             RRSIG   A 13 2 [...]
>     *.h4ha.net.             A       192.155.81.104
>
> but, as seen above, it is not included in the NSEC chain.  The
> behavior is identical across all ~3700 epik.com hosted domains I've
> managed to find.
>

Interesting problem. So the wildcard can be queried directly and validates
properly. But _any_ queries that match the wildcard, including TLSA records
at subdomains, don't validate because of the missing NSEC for the wildcard.

Wonder what DNS implementation they are running, or if they rolled their
own. There have actually been bugs in some open source DNS implementations
involving incomplete NSEC/NSEC3 chain generation.

I assume you've attempted to reach out to the DNS admins involved?

Shumon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20190414/4a68fd3a/attachment.html>