Re: NSEC version field (Re: NSEC2- and an Authenticated Denial M echanism Flag)

[Paul Vixie <paul@vix.com>]

> ..., but I'm not optimistic that we can find a "future amendment"
> means.  I'm often wrong.  I mean, from the thinking I've done, I
> really don't see a way to introduce versioning to the DNS protocol.

it's a second dnssec-wanted flag in edns0.  (dnssec-bis already depends
on edns so this is not a big change.)  the bit means "when i said i wanted
dnssec responses, i really meant i could handle dnssec-ter if you've got it.)

> I haven't proven (even to myself) that it can't be done.  From all the
> angles I've looked and with all of my assumptions applied it looks bleak
> though.
> 
> The only versioning precedent we have is EDNS(0) - and that only works
> because an "advanced" protocol speaker falls back to the old ways to a
> "legacy" protocol speaker.  I don't see this strategy working between
> NSEC and obfuscated authenticated denial.

if NSEC2 has a new type code (and maybe RRSIG but probably not DNSKEY) and
if we promote "want dnssec-ter" as from hop-by-hop to end-to-end (by only
returning cached data if it was acquired using the same flags as the current
query) then this is all pretty simple.

the harder problem is how to keep a bazillion other features out so that -ter
can deploy in a short year or two rather than a whole decade.

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>