Well, yes, but it means that we need to ask ICANN to do an insecure delegation, and there isn't a process for that.
On Wed, Nov 16, 2016 at 4:28 PM, Mark Andrews <[email protected]> wrote: > > In message > <capt1n1m_btpk8tgugoyd7iwxu6sekpm288bibm3xss7hrp2...@mail.gmail.com> > , Ted Lemon writes: >> Yeah, this sunk in for all of us when we were standing around outside >> the meeting room kvetching. It's a bit of a conundrum. > > No. > > All it means is that there isn't policy for this which is exactly > the correct state of affairs for special names in the root namespace. > Each name needs to be individually handled as each is special with > its own requirements. > > Mark > >> On Wed, Nov 16, 2016 at 3:30 PM, Mark Andrews <[email protected]> wrote: >> > >> > In message <[email protected]>, Andrew Sullivan writes >> : >> >> Hi, >> >> >> >> Mark Andrews's point about a DNSSEC insecure delegation today was not >> >> I think fully appreciated. >> >> >> >> In order to create a top-most label in the domain name that can be >> >> used this way and that has the necessary properties, we cannot simply >> >> instruct IANA to do it. That is in fact creating a delegation in the >> >> root zone of the DNS. I believe that RFC 2860 (the MoU between the >> >> IETF and ICANN) does allow us to create special-use domain names at >> >> the top-most level. But I do not believe it allows us to create >> >> special-use domain names at the top-most level _in the DNS_, because >> >> that is control of the root zone and it is unambiguously the province >> >> of ICANN. >> >> >> >> Therefore, if the WG decides to use a top-level label for these >> >> purposes, we have to apply to ICANN to get it delegated from the root >> >> in a provably insecure fashion. Interestingly, ICANN actually has a >> >> policy that it won't delegate things from the root any more that are >> >> _not_ DNSSEC signed, and the whole point here is in fact to add an >> >> entry that is contrary to that policy, so getting such a delegation >> >> would require ICANN to change its policies before it could happen. >> > >> > I suspect this is a mischaracterization of the policy. GTLD >> > delegations are so constrained. This is not a GTLD delegation. >> > >> > New country code delegations are not so constrained. >> > >> > We are not asking them to delegate away from the roots. >> > >> > root zone: >> > HOMENET. NS A.ROOT-SERVERS.NET. >> > ... >> > HOMENET. NS M.ROOT-SERVERS.NET. >> > >> > homenet zone: >> > HOMENET. SOA a.root-servers.net. nstld.verisign-grs.com. 1 1800 900 604800 >> 86400 >> > HOMENET. NS A.ROOT-SERVERS.NET. >> > ... >> > HOMENET. NS M.ROOT-SERVERS.NET. >> > >> > B.T.W. this should also be done for .ONION and .LOCAL if we want >> > local DNS resolvers to intercept these queries. DNSSEC keeps >> > getting forgotten. The only reason people aren't screaming >> > is that there are very few validating clients and the both >> > .ONION and .LOCAL don't use the DNS. SERVFAIL is nearly as >> > good as NXDOMAIN for these use cases. >> > >> > HOMENET uses the DNS. If one can get a trust anchor for HOMENET >> > installed in every validator there shouldn't be any queries for >> > HOMENET/DS. >> > >> >> That is an important practical fact that ought to be taken into >> >> consideration when deciding what kind of label to use. >> >> >> >> Best regards, >> >> >> >> A >> >> >> >> -- >> >> Andrew Sullivan >> >> [email protected] >> >> >> >> _______________________________________________ >> >> homenet mailing list >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/homenet >> > -- >> > Mark Andrews, ISC >> > 1 Seymour St., Dundas Valley, NSW 2117, Australia >> > PHONE: +61 2 9871 4742 INTERNET: [email protected] >> > >> > _______________________________________________ >> > homenet mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/homenet > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
