> On Feb 1, 2017, at 3:47 PM, Bob Harold <rharo...@umich.edu> wrote: > > > On Wed, Feb 1, 2017 at 3:28 PM, Warren Kumari <war...@kumari.net > <mailto:war...@kumari.net>> wrote: > Hi there all, > > I have just posted a new version of alt-tld, which folds in a number > of suggestions and comments from various people -- thank you for > those. As the document was parked I held off making some of the larger > edits; if you sent comments and I missed them, I apologize - please > send them again (or point at them) and I'll try address them. > > > The largest outstanding issue is what to do about DNSSEC -- this is > (potentially) a problem for any / all 6761 type names. > The root is signed, so if a query leaks into the DNS (as they will), > an (unaware) validating resolver will try resolve it, and will expect > either a signed answer, or proof of an insecure delegation; without > this things will look bogus, and so resolvers will SERVFAIL. > > Clearly, a signed answer isn't feasible, so that leaves 2 options - 1: > simply note that validation will fail, and that SERVFAIL will be > returned in many case (to me this seems "correct"), or 2: request that > the IANA insert an insecure delegation in the root, pointing to a: > AS112 or b: an empty zone on the root or c" something similar. > > This is a fine thing to request in an IANA consideratons, but isn't > necessarily *useful* -- the IANA has the technical ability to add > stuff to the root zone, but not the mandate (this is like walking into > a bank and requesting the teller gives you a bunch of money - they may > be able to do so, but aren't actually allowed to.. :-)). > > Some people have suggested "Well, we (or the IAB) can just ask ICANN > politely to do add this, they are in charge of the DNS root, they'll > help out, no worries...." > Unfortunately, this is only partly accurate -- adding an (insecure) > delegation to the root would make .alt be a "real" TLD. ICANN is just > an organization, they are driven by a multistakeholder[0] process, and > there is a huge amount of process and similar around creating a new > TLD -- go read the 300+ page gTLD Applicant Guidebook (Version > 2012-06-04 ) for a fun taste of this. > This would likely require convincing "the naming community" that, for > some reason the IETF is special and should get a "free"[1] TLD, and > that it is exempt from, well, basically all of the existing > requirements..... > > I'd started putting some strawman text into the draft[2], so that we > could have something concrete to discuss and poke holes in, but ripped > it out because it was clearly not going to fly / pure fiction... > > So, what do we want to do here? This is a WG document, the authors > will (of course) do whatever the WG wants, but my personal view is > that asking for an insecure delegation, while technically superior, is > simply not realistic. > > This discussion is somewhat about .alt, but other special use names > will likely have the same issues and concerns, and so we should > consider this in the larger context. > > For example, homenet already has had some of this discussion -- see: > https://mailarchive.ietf.org/arch/search/?email_list=homenet&q=+On+the+TLD+question+and+validatably-insecure+delegation > > <https://mailarchive.ietf.org/arch/search/?email_list=homenet&q=+On+the+TLD+question+and+validatably-insecure+delegation> > > > W > [0]: By law, all mentions of ICANN require the use of the word > "mutistakeholder"....Hey, this is no more crazy than some of the other > new rules.... > > [1]: Yeah, 'tis not a useable TLD in that you cannot sell names and > have them work in the DNS, but this is fairly subtle... > > [2]: > ------------------ > [ Editor note: This section is a strawman (and so is more > conversational than expected for the final version) -- it is likely to > change significantly, or more likely, be removed entirely. ] > > The point of adding this entry to the "Special-Use Domain Name" > registry is to create a namespace which can be used for alternate > resolution contexts, and which will not collide with entries in the > IANA DNS root. > > Unfortunately, queries will still leak into the DNS, and, as the DNS > root zone is signed, validating resolvers which are unaware of .alt > will attempt to DNSSEC validate responses. If there is not an insecure > delgation for .alt, DNSSEC validation will fail, and validating > resolvers will return SERVFAIL, causing additional lookups or other > unexpected behavior. > > In order to avoid this, the IANA is requested to add an insecure > delegation to the root-zone, delegating .alt to AS112 nameservers (or > to an empty zone on hosted by the root). > ------------------ > > > It appears to me that requesting an insecure delegation is the right thing to > do, as a "technical use". We have, so far, been very careful in what we ask > for. If ICANN does not agree, then we can discuss other options.
I agree. - Ralph > > -- > Bob Harold > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop