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

[Shumon Huque]

On Mon, Apr 15, 2019 at 12:57 PM Viktor Dukhovni <ietf-dane at dukhovni.org>
wrote:

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

Ah, I see. I did some quick tests using 8.8.8.8 yesterday and it was
producing SERVFAIL for wildcard expanded positive responses too,
assumed that it was related to the incorrect NSEC, and didn't bother to
 investigate further.

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

With BIND/Unbound/Knot, this authenticates correctly. But I'd say that
the reason is a bit more interesting than mundane. The apparent sole
NSEC record in the zone, that is returned in the authority section of
the response, although incorrect (because there is at least one other name
in the zone, the wildcard), accidentally causes the right thing to happen:
namely it also proves no explicit match and no closer wildcard match of the
name is possible.

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

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