Hi Ed, On Thu, Jun 25, 2015 at 12:51:46PM +0000, Edward Lewis wrote: > >It seems to me that, for any domain name, there are three things that > >are relevant: > > > >1. The namespace. > >2. The registry for that name (in the old-fashioned, not ICANN, sense) > >3. The zone at that name. > > I have to admit that this list isn't clear enough for me. When you same > "name space" are you referring to a domain name space or a more general > name space. I ask because the last entry "the zone" is specific to domain > names.
In my view, the namespace is the logical space of all possible domain names. So, it includes any name that has at least one label. Any label may be no more than 63 octets long. The whole thing can only be 255 octets long. In presentation format, each label is separated by a dot. Frequently, the last dot (and the final, null label) is implicit. In this namespace, I claim, there are several registries. One such registry is a special-names registry. This registry has a bunch of rules for ho things get into it. The things that get in are domain names, but they are not necessarily DNS names. In my view, local. and the proposed onion. are both non-DNS domain names. Indeed, their very function is to act as a switch to a resolver, to tell it, "The name anchored here is not in the DNS, but is resolved in some other way." The rest of the registries in the domain name space -- the ones that cover all the parts of the namespace not excluded by the special-names registry -- are DNS domain name registries. One of these is the root registry. In those registries are two kinds of registrations: ones that are there to enable further delegation (a "positive registration", to give this a name), and ones that are there to _prevent_ further delegation (a "negative registration"). For instance, com. is registered in the root zone, as a delegation point. Conversely, IETF is on the reserved strings list in the Applicant Guidebook (section 2.2.1.2.1) and is therefore, I claim, in the registry to prevent further delegation. Similarly, the rule about all 2-letter strings that are not in the ISO 3166 short codes list is such a preventative registration. Finally, there is the zone file, which contains the positive registrations in the DNS. (Naturally, by way of implementation, one could turn all negative registrations into entries in a zone file, by registering TXT records that said, "This name is not registered for resolution on the Internet," or something like that. Let's stipulate that this is a special case, but I don't think it obscures the point I'm trying to make.) > > With "onion" as the root of a namespace for Tor (sorry, maybe the term is > off), it has names in it that are in the "Tor name space". Yes, but as I understand it the rule is that such names are also part of the domain name space. (There could be a future time where some names beneath onion. are actually longer than the DNS would permit, and I don't know whether to call such things "domain names" or not; but it's fortunately not a problem for us today so I'm going to ignore it.) > There's no "zone" in the DNS sense related to this, because this is > not DNS. Yes. > However, there is talk that the TLD "onion." ought to remain, forever, a > non-existant name (as defined in RFC 4592 [The wildcard one]) and that > then means there should be no zone for "onion." I claim that, because of the function of onion., a registration of it in the special names registry effectively takes it out of the DNS name space (while maintaining it in the domain name space). For that reason, onion. MUST NOT be registered in the DNS root; but that's because its name is excluded from the DNS namespace and not because of something special it does with respect to DNS. This is different from (say) ietf., which _is_ in the DNS name space (it's registered there, though negatively). Does this make the distinction I'm trying for any clearer? > These are two very different things. The first is that the name's look > implies how it is resolved (mapped to an address, say). The latter is how > the DNS is impacted by a domain name that looks similar to the name in > question is treated. No, I don't think I was saying that. The first is a case where, if you match that label, you get a signal that you are walking out of the DNS name space and into some other protocol. For instance, if you encounter a domain name with the top-most label "local.", you immediately know that you shouldn't look that up in DNS, but instead in mDNS. The second case is where a name _is_ part of the DNS, but is not registered in some special way. "Example.com" is an example of this: it shouldn't normally give back results in the DNS, because of its special function. > I don't know if this comment is related, and I think I've said this before > (so guilty of repeating myself perhaps), the special-use domain-name > registry isn't very useful unless it indicates what someone/something > looking up the registry ought to do with the name besides not asking the > DNS for it. In this case, "in-band signals" should be made explicit in > the registry. Doesn't the existing registry (which gives a link to the defining document) do that? > But are the two things Andrew has really separate? I mean, isn't the > registry saying "this" has a non-DNS purpose and DNS ought not make it > exist? Yes, the the two are different (separated by the and in the > previous sentence) but are related outcomes from the use of the name in > some special way? I am claiming that there is a logical distinction here that can help us make evaluations. For instance, one could argue that we ought to distinguish between (say) corp. and onion.: the latter functions as a protocol switch, and needs to be out of the DNS namespace. The former is in fact in active use in DNS names all over the place, and that's what makes it dangerous. It is not obvious that the evaluation criteria in each case ought to be the same. Significantly, for protocol-switch questions there is little in the way of positive empirical evidence that ought to count. (Though if someone came along and asked for a special-use registration of something already registered in the DNS namespace, either positively or negatively, we might want to ask different questions.) I hope this helps, A -- Andrew Sullivan a...@anvilwalrusden.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
