[dns-operations] Akamai now works with ENT (Empty Non-Terminals)?
ietf-dane at dukhovni.org
Mon Apr 15 16:49:29 UTC 2019
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.[220.127.116.11]
> > @ns4.epik.com.[18.104.22.168]
> > ;; ->>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 22.214.171.124
> > 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
More information about the dns-operations