<div dir="ltr"><div dir="ltr">On Wed, Aug 7, 2019 at 4:51 PM Viktor Dukhovni <<a href="mailto:ietf-dane@dukhovni.org">ietf-dane@dukhovni.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Aug 07, 2019 at 03:44:01PM -0400, Alexander Dupuy wrote:<br>
<br>
> > Not completely, the DNSKEY RRset appears to validate fine, but the SOA<br>
> > signature is broken (perhaps serial bumped after signing?), and so<br>
> > all denial of existence fails<br>
> <br>
> I'm curious whether a resolver that fails validation of a negative response<br>
> only because of a bad RRSIG SOA record would be allowed by the RFCs to<br>
> return an uncached negative response without an SOA (or just return an<br>
> NXDOMAIN/NODATA response without caching, if it is a stub resolver).<br>
<br>
Indeed the SOA is used primarily for the negative TTL, and so given<br>
properly signed NSEC/NSEC3 records, perhaps it could be OK to accept,<br>
but not cache the denial of existence, but at least unbound does<br>
not do that, rather queries for non-existent names SERVFAIL.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>However, the following from RFC 4035, Section 3.2.3 may be relevant:</div><div><br></div><div>from <a href="https://tools.ietf.org/html/rfc4035#section-3.2.3">https://tools.ietf.org/html/rfc4035#section-3.2.3</a><br><br>3.2.3. The AD Bit<br><br> The name server side of a security-aware recursive name server MUST<br> NOT set the AD bit in a response unless the name server considers all<br> RRsets in the Answer and Authority sections of the response to be<br> authentic. The name server side SHOULD set the AD bit if and only if<br> the resolver side considers all RRsets in the Answer section and any<br> relevant negative response RRs in the Authority section to be<br> authentic. The resolver side MUST follow the procedure described in<br> Section 5 to determine whether the RRs in question are authentic.<br> [...]<br></div><div><br></div><div>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.</div><div><br></div><div>And RFC 2380 (Negative Caching), Section 3 says the following:</div><div><br></div><div> Name servers authoritative for a zone MUST include the SOA record of<br> the zone in the authority section of the response when reporting an<br> NXDOMAIN or indicating that no data of the requested type exists.<br> This is required so that the response may be cached. The TTL of this<br> record is set from the minimum of the MINIMUM field of the SOA record<br> and the TTL of the SOA itself, and indicates how long a resolver may<br> cache the negative answer. The TTL SIG record associated with the<br> SOA record should also be trimmed in line with the SOA's TTL.<br><br> If the containing zone is signed [RFC2065] the SOA and appropriate<br> NXT and SIG records MUST be added.<br></div><div><br></div><div>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.</div><div><br></div><div><br></div><div dir="ltr" class="gmail_attr">On Wed, Aug 7, 2019 at 3:51 PM Alexander Dupuy via dns-operations <<a href="mailto:dns-operations@dns-oarc.net">dns-operations@dns-oarc.net</a>> wrote</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>[...]</div><div>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?</div></div></blockquote><div><br></div><div>Alex - I agree with your last sentence (the not a good idea part)!</div><div><br></div><div>Shumon.</div><div> </div></div></div>