[dns-operations] DNSSEC validation - salliemae.com

[Shumon Huque]

On Wed, Aug 7, 2019 at 4:51 PM Viktor Dukhovni <ietf-dane at dukhovni.org>
wrote:

> On Wed, Aug 07, 2019 at 03:44:01PM -0400, Alexander Dupuy wrote:
>
> > > Not completely, the DNSKEY RRset appears to validate fine, but the SOA
> > > signature is broken (perhaps serial bumped after signing?), and so
> > > all denial of existence fails
> >
> > I'm curious whether a resolver that fails validation of a negative
> response
> > only because of a bad RRSIG SOA record would be allowed by the RFCs to
> > return an uncached negative response without an SOA (or just return an
> > NXDOMAIN/NODATA response without caching, if it is a stub resolver).
>
> Indeed the SOA is used primarily for the negative TTL, and so given
> properly signed NSEC/NSEC3 records, perhaps it could be OK to accept,
> but not cache the denial of existence, but at least unbound does
> not do that, rather queries for non-existent names SERVFAIL.
>

I'm thinking this might be a little bit of a gray area, where the spec may
be underspecified, and different implementations therefore might have done
different things.

Curiously, RFC 4035, Section 5.4 (Authenticating Denial of Existence) says
nothing about authenticating SOA records in the authority section, and RFC
6840 offers no clarifications on this point either.

However, the following from RFC 4035, Section 3.2.3 may be relevant:

from https://tools.ietf.org/html/rfc4035#section-3.2.3

3.2.3.  The AD Bit

   The name server side of a security-aware recursive name server MUST
   NOT set the AD bit in a response unless the name server considers all
   RRsets in the Answer and Authority sections of the response to be
   authentic.  The name server side SHOULD set the AD bit if and only if
   the resolver side considers all RRsets in the Answer section and any
   relevant negative response RRs in the Authority section to be
   authentic.  The resolver side MUST follow the procedure described in
   Section 5 to determine whether the RRs in question are authentic.
   [...]

This means that a validating resolver should not consider a DNS response
validated unless all the (relevant) RRsets in the Answer and Authority
sections can be authenticated.

And RFC 2380 (Negative Caching), Section 3 says the following:

   Name servers authoritative for a zone MUST include the SOA record of
   the zone in the authority section of the response when reporting an
   NXDOMAIN or indicating that no data of the requested type exists.
   This is required so that the response may be cached.  The TTL of this
   record is set from the minimum of the MINIMUM field of the SOA record
   and the TTL of the SOA itself, and indicates how long a resolver may
   cache the negative answer.  The TTL SIG record associated with the
   SOA record should also be trimmed in line with the SOA's TTL.

   If the containing zone is signed [RFC2065] the SOA and appropriate
   NXT and SIG records MUST be added.

A strict reading of all of this suggests to me that Unbound is probably
doing the right thing - expecting and requiring the correctly signed SOA in
a negative response.


On Wed, Aug 7, 2019 at 3:51 PM Alexander Dupuy via dns-operations <
dns-operations at dns-oarc.net> wrote

> [...]
> I'm not at all convinced that this would be a good idea (it is generally
> better to get people to fix their broken authorities than to paper over
> their mistakes at the resolvers) but perhaps doing so is not (yet)
> forbidden?
>

Alex - I agree with your last sentence (the not a good idea part)!

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