[dns-operations] DNSSEC validation - salliemae.com
shuque at gmail.com
Wed Aug 7 22:41:14 UTC 2019
On Wed, Aug 7, 2019 at 4:51 PM Viktor Dukhovni <ietf-dane at dukhovni.org>
> 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
> > 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
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:
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)
Alex - I agree with your last sentence (the not a good idea part)!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dns-operations