[dns-operations] [Ext] Possibly-incorrect NSEC responses from many RSOs

[Brian Dickson]

On Sun, Feb 28, 2021 at 12:37 PM Viktor Dukhovni <ietf-dane at dukhovni.org>
wrote:

> On Sun, Feb 28, 2021 at 08:52:38PM +0100, Vladimír Čunát wrote:
>
> > On 2/28/21 8:47 PM, Paul Hoffman wrote:
> > >> [1]https://tools.ietf.org/html/rfc8482#section-7  [tools.ietf.org]
> > > That RFC (a) doesn't update RFC 4025 and (b) is only about QTYPE of
> "ANY".
> >
> > I meant just the informal future-work note focused on QTYPE=RRSIG (in
> > the linked section), to support my claim that there are advantages in
> > avoiding full replies to such queries.
>
> Not only are "full" replies not needed, detached from the RRSet for
> which an RRSIG is the signature, the content of the RRSIG is both
> useless and meaningless.  Since it can never be validated it should not
> be cached.
>
> An interoperable synthetic reply when the qname exists would be:
>
>     <qname> 0 IN RRSIG RRSIG 255 <numlabels> 0 <0x0> <0x0> 0
> <closest-encloser> AA==
>
> A signature payload of a single 0 byte avoids potential issues with
> unexpected zero-length signatures.
>
>   * It is less clear what to do when the qname is wildcard-synthesized.
>     Should there be NSEC records to validate a wildcard-based response???
>
> My take is "no", just always set the closest encloser to equal the
> qname, and let the zero TTL take care of not having such replies
> stick around in caches to imply anything about the node.
>
> Iterative resolvers should not cache RRSIG replies, regardless of TTL.
>
> I'm writing a new stub resolver for Haskell, and even prior to this
> thread my plan was to not permit RRSIG queries, because they made no
> sense.  I could instead just return the above synthetic response without
> asking any upstream server, but an error telling the user they're doing
> the wrong thing seems more appropriate.
>

I think this is vaguely interesting, if for no other reason that it exposes
some weaknesses in the original 403[345] RFCs.

Two relevant questions are:

   - Are the observed RRSIG queries the result of an actual client's
   behavior? (The alternative being diagnostic tool usage, and I'd be
   surprised if it was the former.)
   - If a validating client is either using a security-oblivious resolver
   (the client might be a stub or a forwarder), or has an intermediate network
   device interfering with DNSSEC, is it even possible to do validation, ever?

It's clear that the relevant portion(s) of 403[345] don't correctly handle
the RRSIG case, and pretty much cannot (since RRSIG needs to know the
original QTYPE to select/filter the RRSIG).

If (big IF) there is interest in solving for the second case (validating
client behind a middle box or resolver that is not returning RRSIG records,
possibly not doing EDNS, and may or may not be security-aware with respect
to CD and AD bits), what then?
It might be interesting to know how much of the Internet is in those
situations (validating stub or validating resolver, but unable to actually
validate).

The follow-up question, if there is a substantial portion of the client
base that is impacted, which path is more likely to occur on a timely basis:

   - Removal/upgrade of resolvers or middle boxes causing these issues
   - Deployment of new code on resolvers and clients with ways of
   addressing the RRSIG issue

(I don't think there is any real reason or value for auth-only servers to
do anything different, or at most only add the auth piece of any new logic.)

If the latter (deployment of new code) is the path of least resistance
(which would be unpleasant, obviously), the question would then be: how
would a client signal to a server, that it wants RRSIG records for a
specific signed RRSET/RRTYPE?

The assumption would probably be a worst-case scenario: no EDNS, but
possibly transparent path for AD/CD bits, and possibly support for new
OPCODEs. (Testing real paths might be needed for the OPCODE support.)

The methods I can think of are basically:

   - Underscore added to QNAME, to indicate the second QTYPE (either
   _RRSIG.QNAME for QTYPE==thing that is signed by the RRSIG, or _QTYPE.QNAME
   with real QTYPE being RRSIG).
   - New OPCODE for RRSIG, so instead of OPCODE==0 and QTYPE==FOO, have
   OPCODE==RRSIG and QTYPE==FOO
   - The returned reply would either be just the RRSIG of the right QTYPE,
   or the answer of QTYPE RRSET in the Answer section, and the RRSIG(s) in the
   Additional section

Absent the above, it is probably fair to exclude RRSIG from things that can
get sensible answers, and 403[345] should be updated to clarify.

(IMHO, the extra logic might not be too bad, and would potentially be
useful for advancing the deployment of validating stubs.)

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20210228/81e565f4/attachment.html>