Dear colleagues, I made some remarks in the earlier discussion of draft-grothoff-iesg-special-use-p2p-names-00. In this message, I attempt to review draft-grothoff-iesg-special-use-p2p-names-01 completely. I hope these remarks are useful.
Overall ======= I remain extremely concerned that this effort represents another step along a deep and extremely confusing path of mixing the domain name system and other name spaces. I think the IETF needs to figure out whether we're going to accept that, historically, we had multiple name spaces but that now we're going to have one big one; or whether we're going to continue pretending that every other name space doesn't end up wandering into the DNS anyway. (If there are additional alternatives, I am unable to think of them.) I think a pragmatic answer is to accept that, given the number of places we expose domain name slots, anything that uses a name is going to end up having to be somehow compatible with domain name slots. But I think that is a wide-ranging discussion that almost certainly needs to be tackled #separately from the consideration of this particular draft. For the purposes of this draft, I think it would be extremely good if the draft included a section actually documenting the deployment of these top-level labels on systems in reasonable use on the Internet. The mere existence of some software somewhere isn't enough. There needs to be some evidence of deployment, I think, because otherwise this is just a case of label-squatting. That is, if the justification for normalizing these names is just that some software implemented them somewhere, then that becomes a trivial mechanism by which people can do an end-run around the ICANN TLD procedures. Therefore, I think for this case we need some evidence of significant existing deployment of these names in order to meet the terms of the first paragraph of section 4 of RFC 6761. (So, this requires an expansion of a paragraph in section 1 into at least a paragraph for each label.) The RFC 6761 questions to be answered for each reservation are answered in this draft in section 5.1, with the questions answered for all of them. I think this is a mistake, because I think the properties of the different names are actually different. It'd be much better just to refer to the 6761 questions, and say "here are the answers" in each case. So, just for example. I think these are the answers for the .gnu label: 1. Yes. Users must install GNS to use names under .gnu. 2. Yes. The application needs to be GNS-aware, or else the application environment must support GNS. 3. Yes. GNS is a parallel name resolution system and a GNS-capable resolver will need to know how to resolve such names. A GNS-incapable DNS resolver will always receive RCODE=3 (Name Error) for any name beneath .gnu. 4. No. 5. No. 6. Yes. The .gnu top-level label "shifts" the name space to GNS as opposed to DNS. A DNS operator that attempts to configure the .gnu name space is therefore treading on the GNS name space. 7. Every such registry and registrar should reject such registration attempts. Something along those lines for each requested label. Also, see below about particular issues I have. _Many_ of the references seem to be works in progress or unstable web pages. That needs to be fixed for this document to be a useful specification. Particular items in the draft ============================= Abstract: "designed to help harden name resolution security, provide censorship resistance, and protect the users' privacy on the Internet." I think that's just polemical. The purpose of registering these names is, as I understand it, that they're already in use in deployed systems, so you need to register them for interoperability purposes. Right? I suggest saying that instead. If you really need a motivation for the uses, then something like, "designed to help users in non-DNS contexts where DNS-style names are useful for the applications described in this memo." You can get into the motivation for the applications in the text if you want, but not in the abstract, please. Terminology: The acronym "pTLD" is used as a shortcut to mean a pseudo Top-Level Domain, i.e., a name or label for a network not present in operational DNS, and not registered with IANA for use within the scope of operational DNS. I'm not sure I get this. If this document is published, what happens is that the candidate labels become real, genuine labels registered in the DNS. It just so happens that they appear in no zones, because they are in effect allocated and not delegated. I think of allocated names as still being 'part of' the DNS: .invalid is still part of the DNS. I also think it's confusing to claim that these names aren't "part of" the DNS when the whole procedure here is in fact for putting the names into a DNS registry. In this document, ".tld" (with quotes) means: any domain or hostname within the scope of a given pTLD, while .tld (without quotes), or dot-tld, both refer to an adjective form. For example, a collection of ".gnu" peers, but an .onion URL. The pTLD itself is mentioned with dot, and within double quotes, and usually followed by the word pTLD. I find that paragraph confusing, but it appears to be defining a term that is then used less than rigourously throughout the document. It'd be better to define the use once and then make the rest of the draft consistent with the definition. The ".gnu" Relative pTLD: […] Note that ".gnu" names SHOULD follow the naming conventions of DNS. What does this mean exactly? Is this the LDH rule? Case-insensitive but case-preserving? Is GNS subject to IDNA? Or are labels just bags of octets? Are they only 63 octets each, with a maximum 255 limit? "The naming conventions of DNS" have been an endless source of trouble, and I think this needs to be spelled out in detail, or else left out completely because it's well-specified somewhere else. ".gnu" names are personal, relative, and transitive: each user of the GNS controls their own zone that is authoritative for all ".gnu" domains; zones can be delegated between authorities, so that any user can share names, and chain labels to resolve names out of the requesting user's zone of control, including across several zones. [and the next paragraph]. I think this probably should be cut. It's really a description of how the GNS works, and it is neither detailed enough to give the reader a sense of how that works (it sounds like chaos on its own), nor plain enough to require no more explication. The ".zkey" Compressed Public Key pTLD: It is very far from obvious, in this draft, why this functionality requires a whole separate TLD. It _might_ be because of the reverse trick, in which case say that. The ".exit" Client Source Routing pTLD: This one is especially problematic, because it appears to be a TLD that results in special handling of the name to control DNS lookups. This _really_ needs to be unpacked because it will certainly have implications for the global DNS. Also, "hostname" in here is a little confusing. The example, for instance, is "gnu.org.f97f3b153fed6604230cd497a3d1e9815b007637.exit". Once the .exit TLD is registered, then that becomes a valid hostname (but one that in principle always returns particular answers). So, is it ok to have "gnu.org.f97f3b153fed6604230cd497a3d1e9815b007637.exit.f97f3b153fed6604230cd497a3d1e9815b007637.exit"? If not, why not? If so, what do you do when you run into the total limit on DNS names? The ".noconnect" Client Interruption pTLD: If this label isn't requested, just take this section out. The ".i2p" Addressbook pTLD: Apart from the ".b32.i2p" domain that is reserved for SHA-256 hashes, other hostnames within the ".i2p." pTLD are non-hierarchical and can be assigned locally: example.i2p and other.example.i2p do not necessarily belong to the same authority. This looks like a recipe for future disaster. What if you end up with a different encoding scheme in future? Don't you need to allow for that? Also, I really don't get why this one is a TLD. It seems like the sort of name that could be absolutely anywhere in the tree. The ".bit" Timeline System pTLD: Why does this need to be a TLD? This one is to me most fraught, because (1) namecoin sure looks like an effort that has significant potential money-generating activity associated and (2) I can't see any reason this had to be a TLD. Security Considerations: Operation of said TLDs into the global DNS scope could as well produce conflicts [SAC45] due to later real use and the possible acquisition of intellectual property rights in such names. The reservation of several Top-Level Domain names for these purposes will minimize such confusion and conflict, and safety risks for users. But if these names are added to the registry (assuming this document is published) then surely they will _not_ be added to the DNS, because they're already allocated in the DNS. No? Therefore, this isn't a security consideration of the document, but a consideration in case of non-document :) Domain Name Reservation Considerations: 1. Users MAY use these names as they would other domain names, entering them anywhere that they would otherwise enter a conventional DNS domain name, or a dotted decimal IPv4 address, or a literal IPv6 address. Really? So I can put ajs@[gnu.org.f97f3b153fed6604230cd497a3d1e9815b007637.exit]? I bet not. It's simply not true that names and numbers can everywhere be used interchangeably. 2. Application Software MAY pass requests to any of the six proposed pTLDs for normal DNS resolution if A/AAAA records are desired. If available, the local DNS resolver MUST intercept such requests within the respective operating system hooks and behave like DNS. That is a _very very_ bad idea. Either these are special names that aren't part of the DNS, or they're not. If they _are_ part of the DNS because you sometimes want to get DNS data associated with them, then they're DNS names and there's no excuse for this special registration. Go apply to ICANN. If they're not, then you can't have this. But I think what this actually means is, "If these are passed to a DNS resolver, the DNS resolver will follow the usual DNS semantics to resolve them. That should result in RCODE=3 (Name Error) because the TLD labels should never appear in the root of the DNS. I don't like the bits in this section that suggest "the resolver" can do different things, depending. What is really meant is that a resolver call on a system might be resolving in more than one name space. It so happens that a non-DNS resolver might use these name spaces as triggers to do something. In any case, if this owner name reaches the DNS resolver, then the expected outcome is RCODE=3. In addition, I wonder whether this means that these ought to be set up as "default local zones" the way certain other ones are. See below. 4. […] But given that ".bit" users have no special privacy requirements, and those names are globally unique, caching DNS servers MAY choose to treat them as regular DNS names, and cache the responses obtained from the Namecoin block chain as if they were resolved from the regular DNS tree. This is, bluntly, a reason to refuse the .bit registration. If .bit wants a TLD, then let them get it. Otherwise, this is a special name and shouldn't be in the DNS, period. 6. DNS Server Operators MAY choose to resolve ".bit" names using the Namecoin block chain, and if they do so SHOULD treat such domains like they would regular DNS names. Same here. Also, DNS Server Operators SHOULD treat requests to the other five considered pTLDs as typos, for correct installations MUST NOT allow such P2P requests to escape to DNS. This is ridiculous. The _whole point_ of these special TLDs is that you expect to hand these names around as though there's nothing special about them. In that case, you absolutely must expect that these names are going to get to the global DNS (if you think they won't, then I urge you to consider how much .local traffic makes it to the root). Because they don't exist in the root zone, they will be cached for the negative TTL in the root zone's SOA (currently 1 day, if memory serves). So, first, that certainly has effects on DNS operators. Second, there's no such thing as "considering a label a typo" except in the most egregious abuses of the DNS. What we have is "resolved or did not". But perhaps what you are saying is that these ought to be added to the list in RFC 6303, and that they should always answer NXDOMAIN? I could certainly live with that. Best regards, Andrew -- Andrew Sullivan a...@anvilwalrusden.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop