Hi Ted, Thanks for this, a couple of clarifications inline….
On Dec 12, 2013, at 4:07 PM, Ted Lemon <[email protected]> wrote: > Thanks—this is a very helpful response. So if I were to condense your > response down, I would pull out the following (I'm doing this not to put > words in your mouth, but because I'm trying to make sure I don't misrepresent > what you've said): > > 1. Although the current proposal doesn't create a clearly bad amount of > stress on root servers, a policy of allocating tons of sTLDs might eventually > have a substantial impact on the root, simply because of the large number of > unanswerable queries that would be emitted from brokenware and not caught by > intermediate caches. So we should be figuring out what, if anything, we can > do about that eventuality, should it arise. Sadly I think this is true….we have to engineer not only to the DNS when it works and people are operating everything properly, but to the DNS when it doesn't and they aren't, at least as far as foreseeing the problems we're buying. As a minor point-- this sounds like a fairly far-fetched hypothetical in your formulation, and I don't regard it as particularly far-fetched. > 2. You seem to be agreeing with the statement that's been made by a number of > folks that if the particular proposed allocations are to happen, the > discussion ought to include ICANN, because they have thought about this issue > a lot (you didn't actually say this, but it's what I take from your response > to my point 2). And this has the same scaling problems you mentioned in > point 1, this time with respect to the thought process about trademarks. I do think that some discussion with ICANN is called for, although both 6761 and the IAB's MoU with ICANN are silent on the course such a discussion should take. There's an IAB liaison to ICANN's Board which should get involved-- I think I saw a reference in another discussion (the dns-dir message archive) to doing that already, which seems right to me. The concern over potential controversy takes two forms: * intellectual property and related politics; not just trademark-- see for example the controversy among government and commercial players over .amazon or .wine. * we don't know if or when ICANN has additional plans to expand the namespace significantly again. If there are none, many of these risks go away. But otherwise it would be nice to have some idea how the IETF process for picking future special names could limit the risk of a problem over a particular name, and to be sure ICANN was equally intent on avoiding a problem with the special use registry. Experience in both realms convinces me that everyone is interested in avoiding a problem. But we may need some additional consideration of how exactly to do that. > 3. Adding a lot of sTLDs really will have a significant impact on stub > resolvers (you gave some good examples). It adds complication. As an operator, this is my primary concern-- not what the names are, but how they're supposed to work. > 4. Not having clear specifications will exacerbate the problem mentioned in > 3, and you don't know whether the current specifications are clear enough (my > own experience of them from having gone and looked is that there is probably > a lot of the right information, but it's not straightforward to find it, and > it's not clear that it's stable in any useful sense). I've looked briefly at a couple of the underlying documents since I wrote last, agreed on this. > To respond to your final points: > >> * I'm not convinced the current draft is clear enough on the >> operational specifics of how an implementor should treat the requested >> names, or how the overall DNS system will manifest leakage or other >> mishandling of these names. This is operational and probably fixable. > > Yup. I think we need to have a better answer than we currently have, and to > a point drc made a while back, probably better data than we have now on the > current garbage query load on the root. FWIW there is some good data, not only the L-root public data but the datasets various people used in their analyses of existing namespace collisions between private use names leaked to the root and the current round of new gTLD names applied for with ICANN. Other root servers make various data publicly available; for example, the RIPE NCC regularly publishes per-node data for K-root at http://k.root-servers.org on most popular TLDs queried, including non-valid ones, and on distribution of return codes sent including NXDOMAIN. More, and on a more common basis across servers, would be really helpful. There are folks working on this…. > >> * I'm not convinced we've thought through how to manage >> "technical"/infrastructure DNS-like names in a world where those have policy >> implications we may not like but can't reasonably ignore. This is a matter >> of architecture and policy and can really only be resolved by discussion and >> judgment. > > That's pretty much what moved me to start this conversation. I think it's > been a useful conversation, but I don't think we've really got an answer yet. You and me both :) best, Suzanne _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
