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

[Shumon Huque]

On Mon, Apr 15, 2019 at 6:24 PM Peter van Dijk <peter.van.dijk at powerdns.com>
wrote:

> On 15 Apr 2019, at 22:05, Shumon Huque wrote:
> >
> > 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.
>
> PowerDNS also accepts it. My suspicions match yours :)
>

Good to know. [Reminder to myself: I really need to add a PowerDNS
recursor to my suite of test resolvers :-)]

[...]

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

Yeah, the response is clearly non-sensical. I wasn't suggesting that Google
was in the wrong here, but I was wondering about the specific details of
their
validation algorithm, since if our speculation is correct, they seem to be
going beyond the requirements in the spec.

An implementer strictly following the recipe for authenticating DNS
responses outlined in RFC 4035 would probably end up validating
this response. To quote from 4035, Section 5.3.4:

> 5.3.4.  Authenticating a Wildcard Expanded RRset Positive Response
>
>    If the number of labels in an RRset's owner name is greater than the
>    Labels field of the covering RRSIG RR, then the RRset and its
>    covering RRSIG RR were created as a result of wildcard expansion.
>    Once the validator has verified the signature, as described in
>    Section 5.3, it must take additional steps to verify the non-
>    existence of an exact match or closer wildcard match for the query.

It doesn't say: also make sure there are no contradictory facts being
asserted in the response, such as an NSEC record that denies the
existence of the wildcard that was deduced to exist by means of the
RRSIG in the answer section. It seems that resolvers could make any
number of quite complex deductions of this nature, but why would an
implementer go out of their way to do all that extra work? On the other
hand, this zone is clearly broken, so there is probably benefit in a
popular resolver flagging its responses as broken, if it acts as an
incentive to get this fixed.

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