On 6/29/15, 13:43, "DNSOP on behalf of Andrew Sullivan" <[email protected] on behalf of [email protected]> wrote:
>In my view, the namespace is the logical space of all possible domain >names. That certainly narrows the discussion for me. >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"). In the sense that the DNS name space is bounded - there's only a finite set of names it can contain - there exists a complete roster of all names. You can then divide the list into names that have a responsible party and those that don't - and call that (positively registered) and not (or negatively) registered. I separate registration from delegation. Registration means I have entered the domain name in database (or register as a noun) with some characteristics. The characteristics include contact information (e.g., technical, abuse) and/or whether the name is available for some operations (etc., delegation, re-registration). Delegation refers to the "DNS as per STD 13" action of entering NS records and giving total control of the names below the name in the DNS namespace tree to an (possibly different) authority. Not all names in the register get to be delegated because of rules like reserved names, IDN variants, rules rooted in the policy of the registration activity. >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.) I'm not aware of "the rule" that declares Onion names as part of the domain name space. Not an argument, just a data point. I've always heard, and have been running on this, that Onion names are not part of the DNS name space. If Onion's namespace permits names that cannot be part of the finite roster of DNS name space, then I derail seeing how Onion names are domain names. With that, any sort of logic to meld the two name spaces falls apart. This isn't a criticism of either name space. >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). Let me go backwards. I asked the WhoIs server of IANA and it does not know of "IETF." "IETF." is in the finite roster of domain names, it is not delegated (owns no NS records) and is not present in a register as far as I can tell. Perhaps it is in a register as a name assigned to some entity and is not eligible for delegation, but I can't find the register (easily). And to throw this in the mix, the name is non-existent within the DNS protocol (RFC 4592) because it owns no resource records sets and has no descendants - yet it is a member of the finite roster of possible names. I think/assume/believe that Onion is name that has been deployed through out the network in such a way as to set up a potential conflict with the use of "onion." as a domain name. I say "think" because I am going on the list discussion, I have no hard evidence of it - only because I am a curmudgeon when it comes to technology. Given the apparent deployment of the name, it is probably wise that it not be delegated in the public DNS, i.e., the system that is in use where Tor also operates. (I.e., not in the protocol, but in operations.) The special-use domain names registry is apparently the right place to register the name. But to me that is an incomplete process. Who or what is the entity that is assigned/owns the name? (Okay, the registry identifies an RFC that ought to have that information.) Once registered in that way, should the name be delegated? What I hear is no. Is being an entry in the special-use domain names a barrier to delegation? I assume so. Is being an entry a barrier to being used in the DNS? This is not clear - I can ssh to a .local machine. >Does this make the distinction I'm trying for any clearer? Perhaps. (Despite the mangling of the question...;)...I've got a pretty clear distinction in my head how this works, I don't know whether we are converging though. >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. My analogy is human spoken languages. I was once in Holland and approached by a waiter. I thought the waiter addressed me in German (which would be odd), so I responded in German. I then discovered it was German-influenced Dutch he was speaking. Just because something sounds like German doesn't mean it is, it might be Dutch. Just because something looks like a domain name doesn't mean it is, it might be an Tor identifier. Outside of trying one and failing, falling back to some other, I don't see a way to meld the two spaces. >The second case is where a name _is_ part of the DNS, but is >not registered in some special way. For that, and because you mentioned the special word "registered", there are registry database inspection protocols (WhoIs, IRIS, RDAP) that, at least by design, handle that distinction. Granted, IRIS went no where and RDAP is still wearing diapers, but I'm talking intent here. >Doesn't the existing registry (which gives a link to the defining >document) do that? Not programatically. Code can't read RFC. ;) I imagine I am a thread in java. I can use those cool RESTful interfaces and JSON notation to guide my way through code paths and libraries to decide how to transmit some information to an identifier. Obviously, an English parser isn't what I want to carry around. >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.) Alain Durrand and I talked about this a few weeks back. He made the point that you can distinguish the namespace of an identifier "on the right" or "on the left" imaging the use of names in URLs. I.e., there could be a "http-tor://tor-name.onion/path" and use http-onion to tag this as a Tor identifier or "http://tor-name.onion/path"; and assume it's Tor because of the onion where I'd expect(*) a domain name to be. * - It is important to say that I only expect a domain name to be there - I never was able to find out whether the http method/schema/etc/I-forget-the-word expects the first part of the path name to be a domain name or not. Logically, yes, there is a distinction between Tor's name space and the DNS name space. I'm not sure though that the distinction is detectable in how we render in words or bits the identifiers. The special-use domain name registry is an attempt to do that but, in my opinion, it isn't a complete solution as it doesn't help code (for one). (And I do have non-specific concerns over the admission criteria to the registry, i.e., the corp/onion divide you mention.)
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
