In message <cahw9_i+8pa3fqx8fqw-xq_96it7k-g5urmb7fxarui1gwq+...@mail.gmail.com>, Warren K umari writes: > 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.. :-)).
Actually it isn't the same. Implicit in the agreement that the IETF can get names in the root namespace is the ability to use them. Some uses require that there be a entry in the root zone. It doesn't say that the IETF can "RESERVE" a name. The IETF gets the name. > 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..... ICANN has already agreed that the IETF is special. Thats why there is a agreement that the IETF can request names in the root namespace outside of the regular process. There is nothing in the agreement that make the names the IETF requests gTLD. They are a different class. > 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 > > > 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). > ------------------ > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
