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

[Viktor Dukhovni]

On Sun, Feb 28, 2021 at 02:35:45PM -0800, Brian Dickson wrote:

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

I'm not aware of, and would be very surprised to find any organic
(non-diagnostic) use of RRSIG queries.

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

No, because when you obtain an RRSet and a plausibly relevant RRSIG
separately, there's no expectation that the RRSIG is a signature of that
instance of the RRSet, and something older / newer / signed on the fly
by a load-balancer, ...  Signatures are no meaningfully detachable from
the content they're signing.

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

Yes, this is why (and, coincidentally, just a week or so back) I had
decided that the stub resolver I was implementing would refuse to do
RRSIG queries (it also refuses to issue AXFR and IXFR as ordinary
queries).

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

I think that's a non-starter.

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

Sure, but separate RRSIG queries are unlikely to get such host out of
the pickle they're in.  This is where DoT or similar bypass of the
middle-box is pretty much the only option if DNSSEC answers are wanted.

> 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

A bit of both, but not by supporting direct RRSIG queries.

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

I don't think this works.  Hence my suggestion to just return the
simplest possible synthetic answer to RRSIG that would be least
likely to be objectionable to downstream resolvers, causing them
to retry the query at another server.

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

This.  With stub and iterative resolvers not even bothering to ask, and
generating a fake answer (or error in the case of a stub) locally.

-- 
    Viktor.