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

[Paul Vixie]

On Tue, Mar 02, 2021 at 09:44:16PM -0200, Viktor Dukhovni wrote:
> 
> > On Mar 2, 2021, at 9:31 PM, Paul Vixie <paul at redbarn.org> wrote:
> > ...
> 
> I don't quite understand how "giving up" or not "giving up" on "dnssec-aware"
> apps fits into the picture.  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. 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.

> If on the other hand, you're arguing that given a validated response, an
> application should also be able to assemble the full validation chain by
> separately asking for the requisite signed DS and DNSKEY RRsets, then that's
> quite reasonable, and my comment on DNSKEY supports that use-case...

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 (like when i randomly added name
compression all over BIND8 without reading the RFC first as to which types
could and which could not use compression in their rdata), but the rest are
either dnssec-aware or dnssec-nondamaging. we should not make the minimum
viable product unbuildable unless we lack better choices.

-- 
Paul Vixie