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

[Viktor Dukhovni]

On Sun, Apr 14, 2019 at 03:56:35PM -0400, Shumon Huque wrote:

> > 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.

It is a bit more mundane, queries for "A" records do return the
wildcard A result, the failre is with sub-domain queries for any
other RR type, where the RCODE is correct (NODATA), but the NSEC
chain is wrong (includes just the zone apex, no 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?

I sent an email to support at epik.com, no response as yet.  Perhaps
the published support address is not the right channel for this
sort of issue. :-(  I just did the "online chat" on the website,
that seems to have reached someone who's forwarding it on to the
right folks...

-- 
	Viktor.