Re: [DNSOP] Some distinctions and a request - Have some class?
On Mon, Jul 06, 2015 at 06:48:18AM +, Evan Hunt wrote: > > The remark prefaced with "by convention" doesn't strike me as particularly > definitive. I suppose I'd feel better about that if LDH weren't enshrined at least in operational policies all over the Internet. But I suppose you're right: we could issue a document formally deprecating the convention and then explicitly noting that since aliases are defined in terms of zones, therefore alias processing is not permitted to cross class boundaries and can result in non-parallel name spaces. In principle classes would be useful again (though you're still right to note that the code is almost completely unexercised. I have been led to believe that Jefsey Morfin and his friends intend to run/are running an experiment using classes, so perhaps we're in for some excitement). > Point taken, but the problem we're facing is magic special-purpose labels > potentially being repurposed in the global DNS and thus becoming ambiguous. > Allocating class ONION, class MDNS, etc, for things like this may actually > turn out to be less trouble in the long run than ensuring that ICANN never > sells anybody a TLD called .onion. ICANN does have a policy that entries in 6761 are automatically out of bounds, and I can't imagine the parallel universe where they decided that was a bad rule. So I'm not super worried about a collision. You have an interesting point anyway, however, which is I guess what Bill was saying in the first place. If an application actually wanted to protect itself from DNS processing the answer would not be to use a magic string (which could well leak to the IN-class DNS) but instead to call for resolution using a different class. I wonder how many libraries allow you to specify this. I observe that at least the getdns API has it available. Maybe it really is time for another class. I seem to recall that John Klensin suggested a separate class to handle IDNs many years ago. I'll see whether I can find any of the relevant discussion as to why that road was not followed. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request - Have some class?
On Sun, Jul 05, 2015 at 10:01:55PM -0400, Andrew Sullivan wrote: > Since the RDATA for a CNAME or DNAME is another point in the tree, the > above convention would suggest in fact that you _can't_ point to a > different alias (or else, we'd get a very unusual meaning of the terms > "parallel" and "same"). The remark prefaced with "by convention" doesn't strike me as particularly definitive. There's no .bind TLD in class IN, yet version.bind/CHAOS exists in many DNS servers, therefore the namespaces aren't actually parallel or the same, whatever the authors may have expected to happen at the time 1034 was written. > If all we want is a convention for instructing the local resolver, > repurposing classes seems like a lot of work. After all, apparently > Bonjour and Tor -- and for that matter, DKIM -- are able to figure > this out by grovelling through magic labels in the owner name. It's > filthy, but the code all shiped ages ago. Point taken, but the problem we're facing is magic special-purpose labels potentially being repurposed in the global DNS and thus becoming ambiguous. Allocating class ONION, class MDNS, etc, for things like this may actually turn out to be less trouble in the long run than ensuring that ICANN never sells anybody a TLD called .onion. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request - Have some class?
While not Paul or Stephane, I would like to point out that repeated, empirical evidence shows that simply dropping or ignoring queries has the operational effect of link saturation. A quicker, more reliable DDoS vector may not exist. I could not agree that dropping queries is sensible or prudent, if the goal is to have a workable DNS. As to delay as a mitigating strategy, well, that didm;t work so well either. The original RFC 1918 blocks had no public DNS service. We then made the mistake of standing them up. The intent was to delay the response, with an NXDOMAIN first and then a redirect into the private network. It was never flaky enough and developers built around that. This became apparent when we actually started responding authoritatively from these servers. I think it was less than an hour before Herb and Jon were in my office and we had a call with the President of the University. Neither delay, nor redirection will be effective. Either no answer or an authoritative answer give the community certainty. I’ll step back and let the experts “solve” this. manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 5July2015Sunday, at 5:30, Steve Crocker wrote: > Stephane and Paul, > > I’m ok with anything that provides effective negative feedback. Dropping > queries or redirecting them is ok with me. > > Thanks, > > Steve > > On Jul 5, 2015, at 5:11 AM, P Vixie wrote: > >> Delay is expensive for responders since it requires state. Steve's goal of >> making some tld strings flaky so as to encourage developers to avoid DNS for >> those names could be met statelessly. For example delegate them to localhost. >> >> On July 5, 2015 12:51:08 PM GMT+01:00, Stephane Bortzmeyer >> wrote: >> On Sat, Jul 04, 2015 at 09:16:17AM -0700, >> Steve Crocker wrote >> a message of 21 lines which said: >> >> except for the additional load it places on the root servers, >> >> RFC 7535 could be a solution. >> >> I propose augmenting the DNS to include entries in the root that >> serve the purpose of giving slow NXDOMAIN responses instead of quick >> responses for those strings that the IETF has identified as not >> TLDs. >> >> If it is a serious proposal, I object. Delaying answers require >> keeping state in the authoritative name server and opens a nice DoS >> boulevard. >> >> >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request - Have some class?
Two message replies in one: On Sun, Jul 05, 2015 at 05:16:05PM +, Evan Hunt wrote: > What *does* happen is unclear; maybe nothing. To the best of my > knowledge, nobody currently uses non-IN namespaces except for strictly > local authoritative data such as version.bind/CHAOS/TXT. I'm not sure > whether it's even theoretically possible to do more than that today; in any > case it hasn't gotten much attention from implementors or operators, so if > the code exists, it's not being exercised. You're quite right that nobody is really exercising classes anyway, but if you read RFC 1034 the story doesn't get a lot better. One could argue that CNAME and DNAME do not alias namespaces across class boundaries because when you do the DNAME and CNAME substitutions, you do it "matching down, label by label, in the zone." That would seem to help, except that if you look up what a zone is RFC 1034 (section 4.2) says this: The class partition is simple. The database for any class is organized, delegated, and maintained separately from all other classes. Since, by convention, the name spaces are the same for all classes, the separate classes can be thought of as an array of parallel namespace trees. Note that the data attached to nodes will be different for these different parallel classes. Since the RDATA for a CNAME or DNAME is another point in the tree, the above convention would suggest in fact that you _can't_ point to a different alias (or else, we'd get a very unusual meaning of the terms "parallel" and "same"). > Non-IN delegation and recursion > probably aren't adequately specified, certainly aren't adequately tested, > and if my interpretation above is correct, they'd imply a need for a > ./FAKE root zone alongside the ./IN one, which opens up multiple cans of > distressingly wiggly worms. Especially if you're also supposed to honour some convention about parallel namespaces. > However, I can imagine a mechanism in which a query for some.tld/FAKE > instructs the local resolver to use an alternate resolution mechanism for > some.tld, with the DNS protocol being used only for that first hop. > This might be suitable for things like .onion. If all we want is a convention for instructing the local resolver, repurposing classes seems like a lot of work. After all, apparently Bonjour and Tor -- and for that matter, DKIM -- are able to figure this out by grovelling through magic labels in the owner name. It's filthy, but the code all shiped ages ago. On Sun, Jul 05, 2015 at 10:38:18PM +0100, Ray Bellis wrote: > I agree. I very strongly suspect that the omission of explicit QCLASS > matching in DNAME is a simple omission that none of us caught at the > time rather than a deliberate attempt to make DNAME class independent. I recall quite clearly raising the issue at the time (though maybe not on dnsext -- perhaps only in private conversation. That'll teach me), because I had the distinct, um, pleasure of simultaneously trying to explain DNAME to people who thought it would magically solve all their variant issues, and trying to understand a certain M. Morfin's plan to bootstrap his Intersem using new classes. I would have liked it if the answer to everyone I could think of was, "Please do what you like with your namespace," but it didn't seem to work that way. So this was not at least an oversight in my case. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request - Have some class?
On 05/07/2015 18:16, Evan Hunt wrote: > On Sun, Jul 05, 2015 at 10:44:40AM -0400, Andrew Sullivan wrote: >> Imagine the alternative-resolution class FAKE. In the IN class, >> example.com has a DNAME entry pointing to example.net. What should >> happen when someone performs a query for QNAME localentry.example.com, >> TYPE , and CLASS FAKE? > > What *should* happen, IMHO, is the DNAME shouldn't come into consideration > because it only exists in class IN. localentry.example.com/FAKE/ is in > a different namespace entirely, and a query for it should never reach the > example.com/IN zone. I agree. I very strongly suspect that the omission of explicit QCLASS matching in DNAME is a simple omission that none of us caught at the time rather than a deliberate attempt to make DNAME class independent. Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request - Have some class?
On Sun, Jul 05, 2015 at 10:44:40AM -0400, Andrew Sullivan wrote: > Imagine the alternative-resolution class FAKE. In the IN class, > example.com has a DNAME entry pointing to example.net. What should > happen when someone performs a query for QNAME localentry.example.com, > TYPE , and CLASS FAKE? What *should* happen, IMHO, is the DNAME shouldn't come into consideration because it only exists in class IN. localentry.example.com/FAKE/ is in a different namespace entirely, and a query for it should never reach the example.com/IN zone. What *does* happen is unclear; maybe nothing. To the best of my knowledge, nobody currently uses non-IN namespaces except for strictly local authoritative data such as version.bind/CHAOS/TXT. I'm not sure whether it's even theoretically possible to do more than that today; in any case it hasn't gotten much attention from implementors or operators, so if the code exists, it's not being exercised. Non-IN delegation and recursion probably aren't adequately specified, certainly aren't adequately tested, and if my interpretation above is correct, they'd imply a need for a ./FAKE root zone alongside the ./IN one, which opens up multiple cans of distressingly wiggly worms. However, I can imagine a mechanism in which a query for some.tld/FAKE instructs the local resolver to use an alternate resolution mechanism for some.tld, with the DNS protocol being used only for that first hop. This might be suitable for things like .onion. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request - Have some class?
On Sun, Jul 05, 2015 at 08:17:03AM +0100, Ray Bellis wrote: > > Sure, CNAME is *defined* for all classes, but AFAIK there's no way to "jump" > out of one class into another using a CNAME. No, that's correct. But if the point of using a class is to create a separate namespace, then the fact of class-independent RRTYPEs means you can't do that. As Paul Vixie notes, there appears to be some ambiguity with CNAMEs on this front, but as nearly as I can tell RFC 6672 makes this plain for DNAME. Imagine the alternative-resolution class FAKE. In the IN class, example.com has a DNAME entry pointing to example.net. What should happen when someone performs a query for QNAME localentry.example.com, TYPE , and CLASS FAKE? RFC 6672's description of the algorithm does not use CLASS as a distinguishing criterion. So, I think the answer is the DNAME processing should return the results for localentry.example.net, regardless of the class. As a consequence, CLASS does not work to provide different completely independent namespaces, and therefore co-ordination across the class registrations will be necessary. In effect, CLASS doesn't work. At least, that's my reading of the RFC. I'd be pleased to be wrong. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request - Have some class?
On Sun, Jul 05, 2015 at 04:56:21AM -0700, Steve Crocker wrote a message of 23 lines which said: > It would be acceptable to simply dump requests for those names if > the load is too high. In that case, resolvers try and try again, which is even worse for the authoritative name servers. Also, deciding whether to reply or not may be more work than just replying. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request - Have some class?
Stephane and Paul, I’m ok with anything that provides effective negative feedback. Dropping queries or redirecting them is ok with me. Thanks, Steve On Jul 5, 2015, at 5:11 AM, P Vixie wrote: > Delay is expensive for responders since it requires state. Steve's goal of > making some tld strings flaky so as to encourage developers to avoid DNS for > those names could be met statelessly. For example delegate them to localhost. > > On July 5, 2015 12:51:08 PM GMT+01:00, Stephane Bortzmeyer > wrote: > On Sat, Jul 04, 2015 at 09:16:17AM -0700, > Steve Crocker wrote > a message of 21 lines which said: > > except for the additional load it places on the root servers, > > RFC 7535 could be a solution. > > I propose augmenting the DNS to include entries in the root that > serve the purpose of giving slow NXDOMAIN responses instead of quick > responses for those strings that the IETF has identified as not > TLDs. > > If it is a serious proposal, I object. Delaying answers require > keeping state in the authoritative name server and opens a nice DoS > boulevard. > > > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request - Have some class?
Right. Cname does not cross classes. In original DNS, class was incoherently sometimes an attribute of zone data and sometimes a namespace selector. In modern DNS it is coherently always the latter. On July 5, 2015 8:17:03 AM GMT+01:00, Ray Bellis wrote: > > >On 05/07/2015 01:35, Andrew Sullivan wrote: > > > Classes don't work in the general case, because CNAME (and following > > it, DNAME) is class-independent. This is arguably a bug in the > > protocol, but it's a fact nevertheless. As a result, different > > classes aren't really different namespaces. > >Andrew, > >Can you please elaborate on what you mean there? > >Sure, CNAME is *defined* for all classes, but AFAIK there's no way to >"jump" out of one class into another using a CNAME. If you've queried >in class FOO and see a CNAME then the resolution of the target of the >CNAME should continue in class FOO. > >RFC 1034 §3.6.2: > >"CNAME RRs cause special action in DNS software. When a name server >fails to find a desired RR in the resource set associated with the >domain name, it checks to see if the resource set consists of a CNAME >record with a matching class. If so, the name server includes the CNAME > >record in the response and restarts the query at the domain name >specified in the data field of the CNAME record." > >kind regards, > >Ray > >___ >DNSOP mailing list >DNSOP@ietf.org >https://www.ietf.org/mailman/listinfo/dnsop -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request - Have some class?
Delay is expensive for responders since it requires state. Steve's goal of making some tld strings flaky so as to encourage developers to avoid DNS for those names could be met statelessly. For example delegate them to localhost. On July 5, 2015 12:51:08 PM GMT+01:00, Stephane Bortzmeyer wrote: >On Sat, Jul 04, 2015 at 09:16:17AM -0700, > Steve Crocker wrote > a message of 21 lines which said: > >> except for the additional load it places on the root servers, > >RFC 7535 could be a solution. > >> I propose augmenting the DNS to include entries in the root that >> serve the purpose of giving slow NXDOMAIN responses instead of quick >> responses for those strings that the IETF has identified as not >> TLDs. > >If it is a serious proposal, I object. Delaying answers require >keeping state in the authoritative name server and opens a nice DoS >boulevard. > >___ >DNSOP mailing list >DNSOP@ietf.org >https://www.ietf.org/mailman/listinfo/dnsop -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request - Have some class?
On Jul 5, 2015, at 4:51 AM, Stephane Bortzmeyer wrote: > On Sat, Jul 04, 2015 at 09:16:17AM -0700, > Steve Crocker wrote > a message of 21 lines which said: > >> except for the additional load it places on the root servers, > > RFC 7535 could be a solution. > >> I propose augmenting the DNS to include entries in the root that >> serve the purpose of giving slow NXDOMAIN responses instead of quick >> responses for those strings that the IETF has identified as not >> TLDs. > > If it is a serious proposal, I object. Delaying answers require > keeping state in the authoritative name server and opens a nice DoS > boulevard. Hmm… It would be acceptable to simply dump requests for those names if the load is too high. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request - Have some class?
On Sat, Jul 04, 2015 at 09:16:17AM -0700, Steve Crocker wrote a message of 21 lines which said: > except for the additional load it places on the root servers, RFC 7535 could be a solution. > I propose augmenting the DNS to include entries in the root that > serve the purpose of giving slow NXDOMAIN responses instead of quick > responses for those strings that the IETF has identified as not > TLDs. If it is a serious proposal, I object. Delaying answers require keeping state in the authoritative name server and opens a nice DoS boulevard. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request - Have some class?
On 05/07/2015 01:35, Andrew Sullivan wrote: > Classes don't work in the general case, because CNAME (and following > it, DNAME) is class-independent. This is arguably a bug in the > protocol, but it's a fact nevertheless. As a result, different > classes aren't really different namespaces. Andrew, Can you please elaborate on what you mean there? Sure, CNAME is *defined* for all classes, but AFAIK there's no way to "jump" out of one class into another using a CNAME. If you've queried in class FOO and see a CNAME then the resolution of the target of the CNAME should continue in class FOO. RFC 1034 §3.6.2: "CNAME RRs cause special action in DNS software. When a name server fails to find a desired RR in the resource set associated with the domain name, it checks to see if the resource set consists of a CNAME record with a matching class. If so, the name server includes the CNAME record in the response and restarts the query at the domain name specified in the data field of the CNAME record." kind regards, Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request - Have some class?
Avoiding collisions between DNS and non-DNS use of domain names is probably important to us (to some degree that’s what we’re trying to decide). But I have thought, and continue to think, that we make a serious mistake if we regard it as our purpose to “say what strings in the name space should NOT be TLDs.” The IETF delegated that responsibility long ago to someone else, and for good reason. I thought we were heading toward a process to identify domain names that should not be in the DNS for engineering reasons. In practice they're likely to be TLDs, but I can imagine hypothetical situations where someone invents a son-of-onion under .ARPA or somewhere else. Regards, John j...@m.183.57.64.in-addr.arpa (try it if you dare)___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request - Have some class?
On Fri, Jul 03, 2015 at 06:43:13AM -0700, manning wrote: > Actually, there IS an escape method already defined. We just don’t use it > much these days. > It’s called “class” Classes don't work in the general case, because CNAME (and following it, DNAME) is class-independent. This is arguably a bug in the protocol, but it's a fact nevertheless. As a result, different classes aren't really different namespaces. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request - Have some class?
On 4 Jul 2015, at 18:29, Suzanne Woolf wrote: > It seems to me, from long experience of both organizations, that ICANN says > what names should and shouldn’t be in the DNS root zone— Well, I have never seen ICANN saying "definite no" to any string. ICANN only say "no, this string is not to be ok in THIS round of gTLD applications" (as part of the result of the PDP), or "we defer delegation indefinitely". If you have other data, please let me know. As a chair of SSAC I am interested... ;-) Patrik signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request - Have some class?
(no hats) > On Jul 4, 2015, at 3:12 AM, Patrik Fältström wrote: > > Once again: > > ICANN do say what strings in the name space should be TLDs. > > IETF do say what strings in the name space should NOT be TLDs. In the interests of precision in our discussion: I’m not convinced that’s actually the case, and I’m not convinced it’s consistent with what we’ve said in the conversation so far. I *think* it loses exactly the distinction that we started the thread with. It seems to me, from long experience of both organizations, that ICANN says what names should and shouldn’t be in the DNS root zone— a specific instantiation of the namespace, tied to use in a specific database (the public DNS) and the DNS protocol. (Enormous chunks of the Applicant Guidebook, and of the deliberations in the new gTLD program, were devoted to discussion of what names should *not* be in the root zone.) It further seems to me that the IETF says what names it considers to be in the namespace for other reasons, such as enabling deployment of new protocols (as already pointed out upthread, it’s perhaps unfortunate but undoubtedly true that people are doing this and we may want to enable it). Avoiding collisions between DNS and non-DNS use of domain names is probably important to us (to some degree that’s what we’re trying to decide). But I have thought, and continue to think, that we make a serious mistake if we regard it as our purpose to “say what strings in the name space should NOT be TLDs.” The IETF delegated that responsibility long ago to someone else, and for good reason. > The rest are just strings waiting to end up in one of the two groups. I’m not sure I agree with this either, but will have to think further. best, Suzanne ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request - Have some class?
See the end for something provocative. > ICANN do say what strings in the name space should be TLDs. > > IETF do say what strings in the name space should NOT be TLDs. > > The rest are just strings waiting to end up in one of the two groups. > > Patrik Perfectly stated. There is really just one name space. Once a string is designated by the IETF for some purpose other than allocation as a top level domain, it is, IMO, permanently barred from being allocated as a TLD. As a practical matter, non-TLD strings regularly leak into the public domain name system and wind up at the root. In principle, this should not be a problem except for the additional load it places on the root servers, EXCEPT we have also seen end systems depend on the NXDOMAIN response from the root servers as part of their processing. This creates a nasty security hole. I propose augmenting the DNS to include entries in the root that serve the purpose of giving slow NXDOMAIN responses instead of quick responses for those strings that the IETF has identified as not TLDs. local, corp, home, mail, and others are what I have in mind. This is intended to incentivize developers not to release code that improperly depends on the NXDOMAIN response in their search path. Steve ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request - Have some class?
On 4 Jul 2015, at 8:31, John Levine wrote: > I guess my question here is, what would prevent House Finch Feathers OY from > applying >> for the DNS(IN) string ONION from ICANN because they want that as a TLD in >> the IN >> class? > > > At the moment, nothing. > > Remember, we also have a draft about .HOME and .CORP and .MAIL. ICANN > says they're not planning to delegate those names, but they have about > 20 active applications and $3.7M in application fees for those names > which suggests that their plan may not be entirely final. That's why > I think we need an ongoing way to identify names that should stay out > of the DNS for engineering reasons. +1 Once again: ICANN do say what strings in the name space should be TLDs. IETF do say what strings in the name space should NOT be TLDs. The rest are just strings waiting to end up in one of the two groups. Patrik signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request - Have some class?
On 4 Jul 2015, at 1:56, manning wrote: > So I -think- we are on the same page here, although I would replace your use > of the phrase, “name space” with domain. We have empirical evidence of > multiple domains using the same name space. > (Fred Baker persuaded me that there is a single name space, but we > partition/segregate by function/purpose). The same name space for UUCP, > CHAOS, Internet, Onion, etc… just different domains. This is why I do NOT want to use the word domain, but name space, and why I suggest discussion must start there. Because we, as Warren explained, are discussing collision avoidance when there is a risk the same name have multiple use. Patrik signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request - Have some class?
>I guess my question here is, what would prevent House Finch Feathers OY from >applying >for the DNS(IN) string ONION from ICANN because they want that as a TLD in the >IN >class? At the moment, nothing. Remember, we also have a draft about .HOME and .CORP and .MAIL. ICANN says they're not planning to delegate those names, but they have about 20 active applications and $3.7M in application fees for those names which suggests that their plan may not be entirely final. That's why I think we need an ongoing way to identify names that should stay out of the DNS for engineering reasons. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request - Have some class?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 7/3/2015 4:56 PM, manning wrote: > Borrowing a snippet from the operational community (h/t Chris > Morrow). If one replaces “subnet” with “domain”… Indeed -- subnet <--> domain do not map properly in the current landscap e. - - ferg - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlWXTD4ACgkQKJasdVTchbLQZAEAwYK2qPZyjVX/wmrQoTXNXSfB uUuW3e7VBy5yUxXi/zcA/RJ/Tfnq9Xy7PqNlzUZ7TBx6kBnmz1/suvYHlmQKJueC =rJpi -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request - Have some class?
Borrowing a snippet from the operational community (h/t Chris Morrow). If one replaces “subnet” with “domain”… —— this is really a form of: "A subnet should contain all things of a like purpose/use." that way you don't have to compromise and say: "Well... tcp/443 is OK for ABC units but deadly for XYZ ones! block to the 6 of 12 XYZ and permit to all ABC... wait, can you bounce off an ABC and still kill an XYZ? crap... pwned." segregation by function/purpose... best bet you can get. —— So I -think- we are on the same page here, although I would replace your use of the phrase, “name space” with domain. We have empirical evidence of multiple domains using the same name space. (Fred Baker persuaded me that there is a single name space, but we partition/segregate by function/purpose). The same name space for UUCP, CHAOS, Internet, Onion, etc… just different domains. manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 3July2015Friday, at 14:58, Patrik Fältström wrote: > On 3 Jul 2015, at 20:11, manning wrote: > >> I guess my question here is, what would prevent House Finch Feathers OY from >> applying for the DNS(IN) string ONION from ICANN because they want that as a >> TLD in the IN class? > > Nothing, if that is the goal, which I claim it is not. > > The goal is to ensure that portion of the name space, rooted at ONION, is > _not_ existing the portion of the name space reachable by the normal DNS. To > ensure the name space is properly partitioned. > > Patrik > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request - Have some class?
On 3 Jul 2015, at 20:11, manning wrote: > I guess my question here is, what would prevent House Finch Feathers OY from > applying for the DNS(IN) string ONION from ICANN because they want that as a > TLD in the IN class? Nothing, if that is the goal, which I claim it is not. The goal is to ensure that portion of the name space, rooted at ONION, is _not_ existing the portion of the name space reachable by the normal DNS. To ensure the name space is properly partitioned. Patrik signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request - Have some class?
On Fri, Jul 3, 2015 at 2:11 PM, manning wrote: > > On 3July2015Friday, at 9:26, Suzanne Woolf wrote: > >> >> It does seem to me that an important feature here is that "TLD" as we're >> using it is "name in the root zone (or root zone space), to be managed >> within a context that assumes DNS protocol and semantics as well as >> DNS-compatible name space." (That is, people using the term "TLD" to refer >> to single-label DNS-compatible name are incorrect-- "onion" is not a TLD, >> and that's largely the point.) > > CHAOS names are DNS-compatible. But they are not anchored in the root of the > Internet class. > > I guess my question here is, what would prevent House Finch Feathers OY from > applying for the DNS(IN) string ONION from ICANN because they want that as a > TLD in the IN class? Nuttin' -- they can apply, but the expectation is that it wouldn't be granted. The last new gTLD round "Draft Applicant Guidebook" contained: 2.2.1.2.1 Reserved Names All applied-for gTLD strings are compared with the list of top-level Reserved Names to ensure that the applied-for gTLD string does not appear on that list. So, putting something on the SUN registry seems to make it not eligible for being considered as string that can be applied for (at least in this last round) W > > I will not be able to attend the DNSOPS WG since I arrive in Prague later in > the week, but would appreciate being part of this ongoing discussion. > > > /bill > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- 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
Re: [DNSOP] Some distinctions and a request - Have some class?
On 3July2015Friday, at 9:26, Suzanne Woolf wrote: > > It does seem to me that an important feature here is that "TLD" as we're > using it is "name in the root zone (or root zone space), to be managed within > a context that assumes DNS protocol and semantics as well as DNS-compatible > name space." (That is, people using the term "TLD" to refer to single-label > DNS-compatible name are incorrect-- "onion" is not a TLD, and that's largely > the point.) CHAOS names are DNS-compatible. But they are not anchored in the root of the Internet class. I guess my question here is, what would prevent House Finch Feathers OY from applying for the DNS(IN) string ONION from ICANN because they want that as a TLD in the IN class? I will not be able to attend the DNSOPS WG since I arrive in Prague later in the week, but would appreciate being part of this ongoing discussion. /bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request - Have some class?
Hi, On Jul 3, 2015, at 11:18 AM, Patrik Fältström wrote: > Unfortunately I think we all in this discussion [again] mix up discussion > about DNS with the discussion about the name space that is in use for example > by what we know as "the domain name system rooted at the root zone managed by > IANA". > > I think we just must force ourselves to stay focused on namespace management. > A portion of that name space is to be accessed using DNS. Some other portions > of that very same name space is access using other mechanisms. If I've followed the discussion so far-- which has been very good, and exactly what I think we've been working towards for quite awhile now-- this is key to making any kind of progress beyond beauty contests for the IETF to judge about "things that look like TLDs" and confusion for developers of new technology who want to use DNS-compatible names. > This is not easy, but I think that is the way to attack the problem. > > And given such a view, IETF is to decide what strings are to be used "by > other mechanisms" so that [for example] they can and should never ever be > accessed by the domain name system. As long as administrators can configure their own namespaces, the IETF has limited power in this area, and IMHO shouldn't chase more. We can provide advice, however, such as encouraging the use of .alt names in the same kind of "protocol switch signal" names that people are starting to scatter arbitrarily through the namespace. > This while ICANN have processes for deciding what string should be TLDs, > based on the standards created by for example the IETF. It does seem to me that an important feature here is that "TLD" as we're using it is "name in the root zone (or root zone space), to be managed within a context that assumes DNS protocol and semantics as well as DNS-compatible name space." (That is, people using the term "TLD" to refer to single-label DNS-compatible name are incorrect-- "onion" is not a TLD, and that's largely the point.) > > Maybe a document is needed that describes that namespace? How it is > partitioned? Andrew requested on the list last week that we discuss the possibility of 6761bis in Prague, and the draft agenda (to be posted in the next couple of days) does include a slot for that. In the meantime, let's continue here. best, Suzanne > On 3 Jul 2015, at 16:21, manning wrote: > >> Thanks for that. The original claim was that these name spaces were global >> in scope, but not part of the Internet. >> So I took that as face value. Your example, while perhaps a valid >> interpretation, is not what was asked for. >> If it is, then namespace/class specific applications/extentions need to be >> developed/deployed, OR folks need to suck it up and just use the Internet >> portion of the DNS (and its associated rules, e.g. new TLDs are defined by >> ICANN) >> >> /bill >> >> >> On 3July2015Friday, at 7:01, Warren Kumari wrote: >> >>> On Fri, Jul 3, 2015 at 9:43 AM, manning wrote: Actually, there IS an escape method already defined. We just don’t use it much these days. It’s called “class” There is no reason these alternate namespaces should sit in the IN class. they could/should be in their own class, like the old CHAOS protocols. So a class “ONION” or “P2P” would work out very nicely. >>> >>> Yup, but the problem is that people want to be able to enter the >>> alternate namespace names into existing applications (like browsers, >>> ssh, etc), just like a "normal" DNS name. They want to be able to >>> email links around (like https://facebookcorewwwi.onion/ ) and have >>> others click on them, etc. >>> >>> There is no way that I know of to tell e.g Safari to look this up in a >>> different class... and, even if there were, they would *still* leak, >>> because people are lazy... >>> >>> W >>> After all it’s the Domain Name System. (can comprehend names in multiple domains, not just the Internet) manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 2July2015Thursday, at 20:56, manning wrote: > > On 2July2015Thursday, at 18:21, Robert Edmonds wrote: > >> manning wrote: >>> There in lies the problem. These systems have no way to disambiguate a >>> local v. global scope. >>> It seems like the obvious solution is to ensure that these nodes do >>> NOT have global scope, i.e. No connection to the Internets >>> and no way to attempt DNS resolution. Or they need to ensure that >>> DNS resolution occurs after every other “name lookup technology” >>> which is not global in scope. >> >> I don't understand this point. Since Onion hidden service names are >> based on hashes derived from public keys surely they're globally scoped >> (barring hash collisions)? >> >> -- >> Robert Edmonds
Re: [DNSOP] Some distinctions and a request - Have some class?
On 7/3/15 7:01 AM, Warren Kumari wrote: > On Fri, Jul 3, 2015 at 9:43 AM, manning wrote: >> Actually, there IS an escape method already defined. We just don’t use it >> much these days. >> It’s called “class” >> >> There is no reason these alternate namespaces should sit in the IN class. >> they could/should be in their >> own class, like the old CHAOS protocols. So a class “ONION” or “P2P” >> would work out very nicely. > > Yup, but the problem is that people want to be able to enter the > alternate namespace names into existing applications (like browsers, > ssh, etc), just like a "normal" DNS name. They want to be able to > email links around (like https://facebookcorewwwi.onion/ ) and have > others click on them, etc. > > There is no way that I know of to tell e.g Safari to look this up in a > different class... and, even if there were, they would *still* leak, > because people are lazy... well before we just started typing stuff in and let heuristics and search engines divine what we meant, we had urns. I will not suggest that we're going back there UI wise but the heuristics can get more expressive. this can be largely a UI issue today in chrome, if I want to send my query to a particular application e.g. wolfram alpha I do "= " and proceed. UI grooming in no way prevents leakage. nor does it preclude you from having to divine the intentions of the user. > W > >> >> After all it’s the Domain Name System. (can comprehend names in multiple >> domains, not just the Internet) >> >> manning >> bmann...@karoshi.com >> PO Box 12317 >> Marina del Rey, CA 90295 >> 310.322.8102 >> >> >> >> On 2July2015Thursday, at 20:56, manning wrote: >> >>> >>> On 2July2015Thursday, at 18:21, Robert Edmonds wrote: >>> manning wrote: > There in lies the problem. These systems have no way to disambiguate > a local v. global scope. >It seems like the obvious solution is to ensure that these nodes > do NOT have global scope, i.e. No connection to the Internets >and no way to attempt DNS resolution. Or they need to ensure > that DNS resolution occurs after every other “name lookup technology” >which is not global in scope. I don't understand this point. Since Onion hidden service names are based on hashes derived from public keys surely they're globally scoped (barring hash collisions)? -- Robert Edmonds >>> >>> If they _are_ globally scoped, what part of the local system decides which >>> namespace to use, the ONION, the LOCAL, the P2P, the BIT, the BBSS, the >>> DECnetV, the IXP, or the DNS… >>> where is search order determined? Does first match in any namespace win? >>> What is the tiebreaker when there are label collisions between namespaces? >>> >>> >>> /bill >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > > signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request - Have some class?
Perhaps. The Domain Name System is just that. A naming system for domains, one of which is the Internet. Being lazy, and in the absence of significant development in other domains (save the CHAOS domain), our community conflates the DNS(IN) as the entire DNS. Which is false. The DNS, class IN, is rooted at the root zone managed by the IANA. The DNS, class CHAOS, is not. The DNS, class ONION, may not. Legacy applications/browsers etc, are also lazy and have built in assumptions about DNS, class IN. This would only be true for globally scoped name spaces, (so not .LOCAL) And I would be happy to write up something about name spaces, partitions, etc. manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 3July2015Friday, at 8:18, Patrik Fältström wrote: > Unfortunately I think we all in this discussion [again] mix up discussion > about DNS with the discussion about the name space that is in use for example > by what we know as "the domain name system rooted at the root zone managed by > IANA". > > I think we just must force ourselves to stay focused on namespace management. > A portion of that name space is to be accessed using DNS. Some other portions > of that very same name space is access using other mechanisms. > > This is not easy, but I think that is the way to attack the problem. > > And given such a view, IETF is to decide what strings are to be used "by > other mechanisms" so that [for example] they can and should never ever be > accessed by the domain name system. > > This while ICANN have processes for deciding what string should be TLDs, > based on the standards created by for example the IETF. > > Maybe a document is needed that describes that namespace? How it is > partitioned? > > Patrik > > On 3 Jul 2015, at 16:21, manning wrote: > >> Thanks for that. The original claim was that these name spaces were global >> in scope, but not part of the Internet. >> So I took that as face value. Your example, while perhaps a valid >> interpretation, is not what was asked for. >> If it is, then namespace/class specific applications/extentions need to be >> developed/deployed, OR folks need to suck it up and just use the Internet >> portion of the DNS (and its associated rules, e.g. new TLDs are defined by >> ICANN) >> >> /bill >> >> >> On 3July2015Friday, at 7:01, Warren Kumari wrote: >> >>> On Fri, Jul 3, 2015 at 9:43 AM, manning wrote: Actually, there IS an escape method already defined. We just don’t use it much these days. It’s called “class” There is no reason these alternate namespaces should sit in the IN class. they could/should be in their own class, like the old CHAOS protocols. So a class “ONION” or “P2P” would work out very nicely. >>> >>> Yup, but the problem is that people want to be able to enter the >>> alternate namespace names into existing applications (like browsers, >>> ssh, etc), just like a "normal" DNS name. They want to be able to >>> email links around (like https://facebookcorewwwi.onion/ ) and have >>> others click on them, etc. >>> >>> There is no way that I know of to tell e.g Safari to look this up in a >>> different class... and, even if there were, they would *still* leak, >>> because people are lazy... >>> >>> W >>> After all it’s the Domain Name System. (can comprehend names in multiple domains, not just the Internet) manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 2July2015Thursday, at 20:56, manning wrote: > > On 2July2015Thursday, at 18:21, Robert Edmonds wrote: > >> manning wrote: >>> There in lies the problem. These systems have no way to disambiguate a >>> local v. global scope. >>> It seems like the obvious solution is to ensure that these nodes do >>> NOT have global scope, i.e. No connection to the Internets >>> and no way to attempt DNS resolution. Or they need to ensure that >>> DNS resolution occurs after every other “name lookup technology” >>> which is not global in scope. >> >> I don't understand this point. Since Onion hidden service names are >> based on hashes derived from public keys surely they're globally scoped >> (barring hash collisions)? >> >> -- >> Robert Edmonds > > If they _are_ globally scoped, what part of the local system decides > which namespace to use, the ONION, the LOCAL, the P2P, the BIT, the BBSS, > the DECnetV, the IXP, or the DNS… > where is search order determined? Does first match in any namespace win? > What is the tiebreaker when there are label collisions between > namespaces? > > > /bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop >>>
Re: [DNSOP] Some distinctions and a request - Have some class?
Hi, I can't comment on whether this suggestion makes sense for these overlay networks, but it may be one way of handling these non-DNS resolving but still use HTTPS/TCP "IN" type things. I expect that Hellekin, C Grothoff, and others (TOR, namecoin, ...) would be best placed to comment. There is still the time challenge for the certificate work. Thanks for your suggestion, manning. Hugo Connery -- Head of IT, DTU Environment, http://www.env.dtu.dk what the internet should be doing is defining escape mechanisms for non-internet systems, rather than saying "we are the only thing you can use". P Vixie From: DNSOP [dnsop-boun...@ietf.org] on behalf of manning [bmann...@karoshi.com] Sent: Friday, 3 July 2015 15:43 To: Robert Edmonds; Andrew Sullivan Cc: dnsop@ietf.org Subject: Re: [DNSOP] Some distinctions and a request - Have some class? Actually, there IS an escape method already defined. We just don’t use it much these days. It’s called “class” There is no reason these alternate namespaces should sit in the IN class. they could/should be in their own class, like the old CHAOS protocols. So a class “ONION” or “P2P” would work out very nicely. After all it’s the Domain Name System. (can comprehend names in multiple domains, not just the Internet) manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 2July2015Thursday, at 20:56, manning wrote: > > On 2July2015Thursday, at 18:21, Robert Edmonds wrote: > >> manning wrote: >>> There in lies the problem. These systems have no way to disambiguate a >>> local v. global scope. >>>It seems like the obvious solution is to ensure that these nodes do >>> NOT have global scope, i.e. No connection to the Internets >>>and no way to attempt DNS resolution. Or they need to ensure that >>> DNS resolution occurs after every other “name lookup technology” >>>which is not global in scope. >> >> I don't understand this point. Since Onion hidden service names are >> based on hashes derived from public keys surely they're globally scoped >> (barring hash collisions)? >> >> -- >> Robert Edmonds > > If they _are_ globally scoped, what part of the local system decides which > namespace to use, the ONION, the LOCAL, the P2P, the BIT, the BBSS, the > DECnetV, the IXP, or the DNS… > where is search order determined? Does first match in any namespace win? > What is the tiebreaker when there are label collisions between namespaces? > > > /bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request - Have some class?
Unfortunately I think we all in this discussion [again] mix up discussion about DNS with the discussion about the name space that is in use for example by what we know as "the domain name system rooted at the root zone managed by IANA". I think we just must force ourselves to stay focused on namespace management. A portion of that name space is to be accessed using DNS. Some other portions of that very same name space is access using other mechanisms. This is not easy, but I think that is the way to attack the problem. And given such a view, IETF is to decide what strings are to be used "by other mechanisms" so that [for example] they can and should never ever be accessed by the domain name system. This while ICANN have processes for deciding what string should be TLDs, based on the standards created by for example the IETF. Maybe a document is needed that describes that namespace? How it is partitioned? Patrik On 3 Jul 2015, at 16:21, manning wrote: > Thanks for that. The original claim was that these name spaces were global > in scope, but not part of the Internet. > So I took that as face value. Your example, while perhaps a valid > interpretation, is not what was asked for. > If it is, then namespace/class specific applications/extentions need to be > developed/deployed, OR folks need to suck it up and just use the Internet > portion of the DNS (and its associated rules, e.g. new TLDs are defined by > ICANN) > > /bill > > > On 3July2015Friday, at 7:01, Warren Kumari wrote: > >> On Fri, Jul 3, 2015 at 9:43 AM, manning wrote: >>> Actually, there IS an escape method already defined. We just don’t use it >>> much these days. >>> It’s called “class” >>> >>> There is no reason these alternate namespaces should sit in the IN class. >>> they could/should be in their >>> own class, like the old CHAOS protocols. So a class “ONION” or “P2P” >>> would work out very nicely. >> >> Yup, but the problem is that people want to be able to enter the >> alternate namespace names into existing applications (like browsers, >> ssh, etc), just like a "normal" DNS name. They want to be able to >> email links around (like https://facebookcorewwwi.onion/ ) and have >> others click on them, etc. >> >> There is no way that I know of to tell e.g Safari to look this up in a >> different class... and, even if there were, they would *still* leak, >> because people are lazy... >> >> W >> >>> >>> After all it’s the Domain Name System. (can comprehend names in multiple >>> domains, not just the Internet) >>> >>> manning >>> bmann...@karoshi.com >>> PO Box 12317 >>> Marina del Rey, CA 90295 >>> 310.322.8102 >>> >>> >>> >>> On 2July2015Thursday, at 20:56, manning wrote: >>> On 2July2015Thursday, at 18:21, Robert Edmonds wrote: > manning wrote: >> There in lies the problem. These systems have no way to disambiguate a >> local v. global scope. >>It seems like the obvious solution is to ensure that these nodes do >> NOT have global scope, i.e. No connection to the Internets >>and no way to attempt DNS resolution. Or they need to ensure that >> DNS resolution occurs after every other “name lookup technology” >>which is not global in scope. > > I don't understand this point. Since Onion hidden service names are > based on hashes derived from public keys surely they're globally scoped > (barring hash collisions)? > > -- > Robert Edmonds If they _are_ globally scoped, what part of the local system decides which namespace to use, the ONION, the LOCAL, the P2P, the BIT, the BBSS, the DECnetV, the IXP, or the DNS… where is search order determined? Does first match in any namespace win? What is the tiebreaker when there are label collisions between namespaces? /bill >>> >>> ___ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >> >> >> >> -- >> 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 > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request - Have some class?
Thanks for that. The original claim was that these name spaces were global in scope, but not part of the Internet. So I took that as face value. Your example, while perhaps a valid interpretation, is not what was asked for. If it is, then namespace/class specific applications/extentions need to be developed/deployed, OR folks need to suck it up and just use the Internet portion of the DNS (and its associated rules, e.g. new TLDs are defined by ICANN) /bill On 3July2015Friday, at 7:01, Warren Kumari wrote: > On Fri, Jul 3, 2015 at 9:43 AM, manning wrote: >> Actually, there IS an escape method already defined. We just don’t use it >> much these days. >> It’s called “class” >> >> There is no reason these alternate namespaces should sit in the IN class. >> they could/should be in their >> own class, like the old CHAOS protocols. So a class “ONION” or “P2P” >> would work out very nicely. > > Yup, but the problem is that people want to be able to enter the > alternate namespace names into existing applications (like browsers, > ssh, etc), just like a "normal" DNS name. They want to be able to > email links around (like https://facebookcorewwwi.onion/ ) and have > others click on them, etc. > > There is no way that I know of to tell e.g Safari to look this up in a > different class... and, even if there were, they would *still* leak, > because people are lazy... > > W > >> >> After all it’s the Domain Name System. (can comprehend names in multiple >> domains, not just the Internet) >> >> manning >> bmann...@karoshi.com >> PO Box 12317 >> Marina del Rey, CA 90295 >> 310.322.8102 >> >> >> >> On 2July2015Thursday, at 20:56, manning wrote: >> >>> >>> On 2July2015Thursday, at 18:21, Robert Edmonds wrote: >>> manning wrote: >There in lies the problem. These systems have no way to disambiguate > a local v. global scope. > It seems like the obvious solution is to ensure that these nodes do > NOT have global scope, i.e. No connection to the Internets > and no way to attempt DNS resolution. Or they need to ensure that > DNS resolution occurs after every other “name lookup technology” > which is not global in scope. I don't understand this point. Since Onion hidden service names are based on hashes derived from public keys surely they're globally scoped (barring hash collisions)? -- Robert Edmonds >>> >>> If they _are_ globally scoped, what part of the local system decides which >>> namespace to use, the ONION, the LOCAL, the P2P, the BIT, the BBSS, the >>> DECnetV, the IXP, or the DNS… >>> where is search order determined? Does first match in any namespace win? >>> What is the tiebreaker when there are label collisions between namespaces? >>> >>> >>> /bill >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > > > -- > 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request - Have some class?
On Fri, Jul 3, 2015 at 9:43 AM, manning wrote: > Actually, there IS an escape method already defined. We just don’t use it > much these days. > It’s called “class” > > There is no reason these alternate namespaces should sit in the IN class. > they could/should be in their > own class, like the old CHAOS protocols. So a class “ONION” or “P2P” > would work out very nicely. Yup, but the problem is that people want to be able to enter the alternate namespace names into existing applications (like browsers, ssh, etc), just like a "normal" DNS name. They want to be able to email links around (like https://facebookcorewwwi.onion/ ) and have others click on them, etc. There is no way that I know of to tell e.g Safari to look this up in a different class... and, even if there were, they would *still* leak, because people are lazy... W > > After all it’s the Domain Name System. (can comprehend names in multiple > domains, not just the Internet) > > manning > bmann...@karoshi.com > PO Box 12317 > Marina del Rey, CA 90295 > 310.322.8102 > > > > On 2July2015Thursday, at 20:56, manning wrote: > >> >> On 2July2015Thursday, at 18:21, Robert Edmonds wrote: >> >>> manning wrote: There in lies the problem. These systems have no way to disambiguate a local v. global scope. It seems like the obvious solution is to ensure that these nodes do NOT have global scope, i.e. No connection to the Internets and no way to attempt DNS resolution. Or they need to ensure that DNS resolution occurs after every other “name lookup technology” which is not global in scope. >>> >>> I don't understand this point. Since Onion hidden service names are >>> based on hashes derived from public keys surely they're globally scoped >>> (barring hash collisions)? >>> >>> -- >>> Robert Edmonds >> >> If they _are_ globally scoped, what part of the local system decides which >> namespace to use, the ONION, the LOCAL, the P2P, the BIT, the BBSS, the >> DECnetV, the IXP, or the DNS… >> where is search order determined? Does first match in any namespace win? >> What is the tiebreaker when there are label collisions between namespaces? >> >> >> /bill > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- 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
Re: [DNSOP] Some distinctions and a request - Have some class?
Actually, there IS an escape method already defined. We just don’t use it much these days. It’s called “class” There is no reason these alternate namespaces should sit in the IN class. they could/should be in their own class, like the old CHAOS protocols. So a class “ONION” or “P2P” would work out very nicely. After all it’s the Domain Name System. (can comprehend names in multiple domains, not just the Internet) manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 2July2015Thursday, at 20:56, manning wrote: > > On 2July2015Thursday, at 18:21, Robert Edmonds wrote: > >> manning wrote: >>> There in lies the problem. These systems have no way to disambiguate a >>> local v. global scope. >>>It seems like the obvious solution is to ensure that these nodes do >>> NOT have global scope, i.e. No connection to the Internets >>>and no way to attempt DNS resolution. Or they need to ensure that >>> DNS resolution occurs after every other “name lookup technology” >>>which is not global in scope. >> >> I don't understand this point. Since Onion hidden service names are >> based on hashes derived from public keys surely they're globally scoped >> (barring hash collisions)? >> >> -- >> Robert Edmonds > > If they _are_ globally scoped, what part of the local system decides which > namespace to use, the ONION, the LOCAL, the P2P, the BIT, the BBSS, the > DECnetV, the IXP, or the DNS… > where is search order determined? Does first match in any namespace win? > What is the tiebreaker when there are label collisions between namespaces? > > > /bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Andrew Sullivan wrote: > On Tue, Jun 30, 2015 at 11:43:42AM +, Edward Lewis wrote: >> 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. > > You're conflating "DNS name space" and "domain name space" again. > I didn't say they're part of the DNS name space; and given what > the top-level label onion. does, they can't possibly be. At the > beginning, I claimed that the domain name space was all the > logically possible domain names, not all the ones in fact possibly > in the DNS. Under this definition, local. is part of the domain > name space and not part of the DNS name space (because of local. > being registered in the special use names registry). > > When I asked about this before, one of the onion proponents told > me that onion names have to conform to DNS (and, he claimed, LDH) > rules right now, though that is a possibly temporary convention. .onion and .i2p (and to my knowledge, the other proposed P2P-Names TLDs too) have to conform to DNS rules in order to be usable in legacy applications that expect domain names. In some future where the percentage of apps requiring this is much lower (by most apps natively supporting Tor/I2P/etc), the restriction could be removed. But while domain names are the de-facto standard, I don't see it changing. >> 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. > > I think this is a terrible confusion of URI schemes vs. name-space > switches. It's true that if you treat the URI as an unformatted > string you can parse it this way; but there are already rules for > that. But I think anyway that's a distraction. We don't need > uri-schemes to creep into this. +1. Besides the confusion, this would require native app support, because URI schemes are generally handled separately to name resolution - you couldn't just use a SOCKS/HTTP/DNS proxy to handle legacy applications, like Tor/I2P/GNUnet do now. str4d > > Best regards, > > A > -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVk371AAoJEBO17ljAn7PgmpgP/RXlwq9LVkKCkY8Ldk/QMo2z zFc2P1E7mO2JmNrkt4d77l+mzWNz3Ne0LMRen5mnJMvl+LitsF62kM3DJ+J9P0EZ 9MFt+WkpkYa+Jz1pMvTaR18Z5uZg8MAJB/qui/0xpTx2FPg02aNWyeroS32nX5Lo TCx4YgVxBdQYKjXzg9t57+5t+CgcNVu9/YBVuJfEj+Isu/GZHr4ElstVtVrv50zq 1U3UycHA9HWdTjKU1zE6f3IrZXIzNpQGDXwjdhYySpGK1nKwTVRBEJFDsz2JDtyc fu8gVsMPvvmqDwDYOJCqxvB5Ko/bF2PehtdtGY82qJBdtE5w+/Rbtu5mdZeupcU3 Ps74fZk6zHEZzzbbJjvwDHHG4oE/AmhLRZp9fylhzabCCElGNZ8Uuc4Fz7ZuXFsn ngg+9ANVl10JFv+RkKjKEbyyoUKDvd69d7TxAv11wR+OIhnchCFFRyU3YVlEuuK5 g5WMCQyhb010Wa5QasoQH2OAlhKQPsDtN2WbLoljqyptmIJ4TU2dej/EJSYSvX1M kbkj005GFm0jv4rVRja7dgkmrErxH9tJq0HwcIsQPe+KaIHWmeR2BwTbxXiQtjBr gb6bGc5EO1GakxARefvHSLjag/iFuOjJ8M6kU8IKb2gemzXpOPA4ocfF3GwajcXi +uWyxB0slKYUiBUNxFzw =67PO -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request
On Tue, Jun 30, 2015 at 04:27:10PM +, Edward Lewis wrote: > > So this is about words - what you call a negative registration is a > registration nonetheless, with an responsible party. Well, it's about conceptual clarity. If we want to call that "negative registration" instead "skippy the wonder dog", I don't care. But there's a difference between "positively registered with someone that delegation is not allowed" and "a possible name enumerable in the namespace that is not registered." I hope we can agree on that. > How can I not (conflate them)? I don't follow you. I am trying to draw a distinction. I'm going to try one more time here on the list, begging everyone else's indulgence, and then if that doesn't work I'm going to figure that I can't explain it. Perhaps another way to say this is that the term "DNS" has taken on a separate meaning from "domain name", but I think that's not necessary: On the one hand, we have the domain name space. It encompasses within it all the logically-possible domain names. These are all the names of one or more labels, where one label is null length and is the last label, and all the other labels are between 1 and 63 octets. The whole name must be under 255 octets. Otherwise, there is a variable number of labels and each label may vary in length according to the above restrictions. It is, as you point out, a finite name space. On another hand, we have the _DNS_ space. This is a subset of the domain name space as such. The DNS space is all the names covered in the domain name space, that may in fact be registered (not just delegated, but registered) in the DNS. (Note that DNS means domain name system, so another way to say this is that these are the domain names that are in fact allowed in the system.) I say that protocol-switch names like local. are inside the domain name space, but not in the DNS space, because they function to switch any lookup out of the domain name system and into some other resolution mechanism. Other special names do not have the same effect -- invalid., for instance, does not. (Note that one consequence of this is that the null-length label is special in more than one way, because it has to exist in every system namespace. I think that's all right, because these different names are all within the domain name space, just not in the DNS space. It's conceptually hideous, but I can see why people do it in implementation.) (I'm leaving out the zone space here, because that's yet another subset, of DNS space, and we seem to agree about that.) > what I understand that would be a $key.onion. I don't grok how > $key.onion. "can't possibly be" a domain name given that "onion." is. both $key.onion. and onion. are domain names, but they're not in the DNS namespace. > DNS." Do you mean names of greater than 256 octets, etc., not possible > because they violate syntax rules? Or...I don't follow. There are names outside the domain name space, yes. A name that has a label longer than 63 octets is outside the domain name space. > special-use domain name registry. Perhaps it's confusing because RFC 6761 > defines "Special-Use Domain Names" and not Special-Use Names. From the Yes, they're domain names, but not DNS names. > Well, it's odder than that. There is ICANN's WhoIs and IANA's WhoIs. I > mentioned IANA's specifically for a reason. Ok, a fair point. But surely ICANN could register names that it will not (by policy) admit to the IANA root zone in the IANA whois without any delegation? Hmm, I suppose not, given the IANA rules for registrations. This is an interesting policy problem, but fortunately not one we have to discussion on DNSOP. I understand there was a large meeting recently that might have presented a forum for this. > database (anywhere, all the time). I really don't know if there is a > formal listing of "IETF." as having any status in any register. (Using > the dictionary definition of register as an official roll.) It's in a list in the Applicant Guide Book, as I mentioned in the previous message. Given that the AGB is the holy tome of new non-ccTLD allocations for registration by ICANN, I think that counts as an official roll. > What's "the AGB"? "Applicant Guide Book". "AGB" seems to be a common shorthand for this in ICANN circles. Sorry for the jargon. > No, people can implement an RFC. Yes, and then they have an implementation which implements the RFC. At least, that's the way people say such things to me. I agree it's too bad that we don't have the lexico-grammatical precision in English that Latin does, but here we are. Anyway, I hope this helps. If not, then perhaps I'm completely wrong or perhaps I'm just doing a poor job explaining myself to you. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request
On 6/30/15, 11:18, "DNSOP on behalf of Andrew Sullivan" wrote: >This is a different use of "positively|negatively registered" than I >outlined. The case that I was talking about I think _does_ have an RP >for the negaitve registration. But that registration is there to >prevent delegation. Another example of this is the controversial >reservation practices in xxx and sucks: you pay your money for a >registration to guarantee that the name will _not_ be delegated. So this is about words - what you call a negative registration is a registration nonetheless, with an responsible party. If I want to delegate a name that is registered "negatively", I can go to the responsible person, trade with them and then get the name delegated so long a all policies are followed. It's like buying the house lot next to yours to make sure no one builds on it. But I don't think this is a significant point of contention. >You're conflating "DNS name space" and "domain name space" again. How can I not (conflate them)? I don't follow you. >I didn't say they're part of the DNS name space; and given what the >top-level label onion. does, they can't possibly be. I have some trouble parsing, let alone understanding, that sentence. "They" in "they're part" refers to the names ending in "onion."? From what I understand that would be a $key.onion. I don't grok how $key.onion. "can't possibly be" a domain name given that "onion." is. (Or isn't, I'm just confused.) >At the >beginning, I claimed that the domain name space was all the logically >possible domain names, not all the ones in fact possibly in the DNS. >Under this definition, local. is part of the domain name space and not >part of the DNS name space (because of local. being registered in the >special use names registry). Here my confusion is centered on "not all the ones in fact possibly in the DNS." Do you mean names of greater than 256 octets, etc., not possible because they violate syntax rules? Or...I don't follow. I don't see that "local." is not part of the DNS name space. It's in the special-use domain name registry. Perhaps it's confusing because RFC 6761 defines "Special-Use Domain Names" and not Special-Use Names. From the title, I assume that the list if objects are domain names that are part of the DNS name space that are accorded special status for some reason. Which fits "local." >That's because you're assuming that the whois contains all >registrations in the top-level name space. I wish it were true that >ICANN, in its role as steward of the root zone, registered things in >the root whois that it was registering/reserving from allocation to >others. But it doesn't, for reasons known best to itself. The AGB >clearly reserves some names from use, which I think pretty plainly >puts them into the DNS name space and outside of eligibility for other >registration. That is, I claim, a negative registration of the name. Well, it's odder than that. There is ICANN's WhoIs and IANA's WhoIs. I mentioned IANA's specifically for a reason. And I'll defer to the comment that WhoIs isn't totally representative of what's in the registration database (anywhere, all the time). I really don't know if there is a formal listing of "IETF." as having any status in any register. (Using the dictionary definition of register as an official roll.) What's "the AGB"? >Are you arguing that is inadequate? If so, a reason why would be nice. >>Not programatically. Code can't read RFC. ;) > >But it can implement one. No, people can implement an RFC. Perhaps this isn't a point that will go far, but, DNS has defined "unknown types" which can future proof servers. General apps don't have something like that. I mean - if the app can ask the registry for the names, it can react somehow (I won't expand here). >I think this is a terrible confusion of URI schemes vs. name-space >switches. It's true that if you treat the URI as an unformatted >string you can parse it this way; but there are already rules for >that. But I think anyway that's a distraction. We don't need >uri-schemes to creep into this. That was partly mean as an example of how to separate namespaces. After this exchange, I'm still confused - are Tor Identifiers domain name or not? Is there an intersection or not? Or is it just a "they look the same?" smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request
On Tue, Jun 30, 2015 at 11:43:42AM +, Edward Lewis wrote: > 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. This is a different use of "positively|negatively registered" than I outlined. The case that I was talking about I think _does_ have an RP for the negaitve registration. But that registration is there to prevent delegation. Another example of this is the controversial reservation practices in xxx and sucks: you pay your money for a registration to guarantee that the name will _not_ be delegated. > 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. Yes, exactly. > 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. You're conflating "DNS name space" and "domain name space" again. I didn't say they're part of the DNS name space; and given what the top-level label onion. does, they can't possibly be. At the beginning, I claimed that the domain name space was all the logically possible domain names, not all the ones in fact possibly in the DNS. Under this definition, local. is part of the domain name space and not part of the DNS name space (because of local. being registered in the special use names registry). When I asked about this before, one of the onion proponents told me that onion names have to conform to DNS (and, he claimed, LDH) rules right now, though that is a possibly temporary convention. > 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. That's because you're assuming that the whois contains all registrations in the top-level name space. I wish it were true that ICANN, in its role as steward of the root zone, registered things in the root whois that it was registering/reserving from allocation to others. But it doesn't, for reasons known best to itself. The AGB clearly reserves some names from use, which I think pretty plainly puts them into the DNS name space and outside of eligibility for other registration. That is, I claim, a negative registration of the name. > 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. This line of argument is collapsing the very distinction I was trying to make. Onion and (say) corp both have that property, but only one of them is functioning to signal a protocol change. > 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.) Are you arguing that is inadequate? If so, a reason why would be nice. > Once registered > in that way, should the name be delegated? What I hear is no. I think pretty obviously this depends on the use case, which goes in the defininig RFC if I read 6761 correctly. > My analogy is human spoken languages. Where computers are concerned, that is almost always a mistake. > Not programatically. Code can't read RFC. ;) But it can implement one. > 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. I think this is a terrible confusion of URI schemes vs. name-space switches. It's true that if you treat the URI as an unformatted string you can parse it this way; but there are already rules for that. But I think anyway that's a distraction. We don't need uri-schemes to creep into this. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request
On 6/30/15, 7:48, "DNSOP on behalf of Ray Bellis" wrote: >So can I, but that's because my computer's name service stub used mDNS >to find it, not DNS. Would the same code handle .onion? (Perhaps a new version via RPM push.) Is relying on software updates scaleable? This is the flip side of whether the name ought to return NXDOMAIN if the DNS is queried... smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request
On 30/06/2015 12:43, Edward Lewis wrote: > Is being an entry a barrier to being used in the DNS? This is > not clear - I can ssh to a .local machine. So can I, but that's because my computer's name service stub used mDNS to find it, not DNS. Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request
On 6/29/15, 13:43, "DNSOP on behalf of Andrew Sullivan" 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 b
Re: [DNSOP] Some distinctions and a request
Hi Ed, On Thu, Jun 25, 2015 at 12:51:46PM +, 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
Re: [DNSOP] Some distinctions and a request
On 6/23/15, 13:07, "DNSOP on behalf of Andrew Sullivan" 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. 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". There's no "zone" in the DNS sense related to this, because this is not DNS. 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." Just a bit confused. >At least some special-use names are in-band signals of a protocol >shift. >Some other possible special-use names are really names that are >expected to appear in DNS contexts _but_ that are not expected to >resolve in the global DNS context. 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. 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. 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? smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Some distinctions and a request
Dear colleagues, Perhaps it's to do with blood flow to my brain due to my experiences this week, but I've been contemplating some distinctions that we have perhaps not made as clearly as we might in respect of RFC 6761. This message is an attempt to lay those out. RFC 6761 contains a number of questions for how to determine whether something is a special-use name, but I think there may be missing a distinction that is useful. 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. RFC 6761 appears to suggest that one should not have a special-use entry that definitely appears in the zone at the special-use name. I suggest in addition that we have a distinction to make. At least some special-use names are in-band signals of a protocol shift. For instance, logically speaking local in the root zone is not really a special name that is in the registry, but not in the zone. Instead, it's a signal that one should query on port 5353. (This does not mean you can't implement this with tricks in the DNS, or that you might not find some way to respond in DNS for local. queries; just that the _point_ of the string is a protocol switch.) Some other possible special-use names are really names that are expected to appear in DNS contexts _but_ that are not expected to resolve in the global DNS context. We can think of these as _negative_ entries in the target DNS registry: registrations that are supposed to prevent other registrations and are supposed to prevent DNS resolution in the global DNS. I think these distinctions need to be make clear. In addition, I think it would be really helpful if these distinctions were made in the special-use names registry document, which makes me think that RFC 6761bis is needed. I think this topic should be on the agenda for Prague. I also think that it would be really helpful to keep these distinctions present to mind in additional discussions of the topic. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
