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

[Viktor Dukhovni]

On Wed, Mar 03, 2021 at 12:40:55AM +0000, Paul Vixie wrote:

> > If, as Brian Dickson upthread, you're trying to find a way for
> > applications to work around non-cooperative iterative resolvers, and
> > somehow assemble all the DNSSEC metadata piecemeal over multiple
> > requests, that's very unlikely to work.
> 
> I didn't see what Mr. Dickson may have said.  However, Mark Andrews
> convinced me years ago that app-aware dnssec and stub-aware dnssec
> could be done.

I don't know what scenario mark had in mind, but per my earlier
response, I maintain that this is not possible in general, and I'm
not fond of solutions that are much too fragile.

When the response RRset dynamically generated or recently changed, with
different variants in different caches, any RRSIG you might get is
liable to be for some other version of the RRset than the one you're
trying to validate.

Also one can't elicit denial of existence of proofs by querying
DNSSEC-oblivious servers for insecure answers.  So opportunistic
DANE TLSA would not be possible.

I don't think we can or should build application security on such
fragile foundations.  The RRset and RRSIG need to travel together as a
unit.

> If it can't be done i'd like this community to work toward fixing
> things. but right now it's your estimate ("unlikely") against mine
> ("work around") and neither is a good basis for decision.

FWIW, I have concrete objections.

> I think you had me right the first time. I'm imagining a world with
> dnssec aware apps and stubs (and therefore, DANE validators in TLS
> clients), where some paths are closed for stupid reasons..., but the
> rest are either dnssec-aware or dnssec-nondamaging. We should not make
> the minimum viable product unbuildable unless we lack better choices.

A laudable goal, but exposing RRSIG as a bare RRset one can query does
not look like a viable path forward.  So I don't see this happening.
More likely equipment that gets in the way will over time get replaced,
or users will tunnel traffic to a less broken resolver.

-- 
    Viktor.