John Levine wrote on 2022-08-01 15:22:
It appears that Paul Vixie <p...@redbarn.org> said:
i'm particularly interested in whether the root zone should have an NS
for the private-label tld(s) (.alt or ._alt or whatever) with an NS of
"localhost" and a dnssec "opt out" indicator so that these private tlds
can fit into the authenticity infrastructure.
Why? If you're going to hack in your local names, why wouldn't you hack
in your local DNSSEC anchors at the same time?
that's the Yeti-DNS approach and it works but it doesn't support
mobility with forwarders and is thus mostly a proof of concept. for
scale, it's necessary to augment the namespace without a locally
modified and signed root zone, and do it all in the resolver.
let's go back to the earlier part of the above-excerpted message:
+1. the namespace will be locally augmented. we should describe a way.
dnssec is somewhat viral, in that the one true root zone will contain
negative proofs for label ranges where nothing is known to exist. for
local augmentation to scale, the one true root zone should admit that a
few carve-out delegation points exist, and should specify that the
content inside those delegations isn't signed.
if a mobile forwarding resolver is going to see content from the one
true root and also content from its own local content, we should take
pains to ensure that the assertions from the one true root do not
conflict. while a recursive validator could possibly be educated in how
to live with a foot in each world, an application validator (such as
DANE) probably cannot be so educated.
"the namespace will be locally augmented. we should describe a way."
--
P Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
