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 st...@shinkuro.com 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 p...@redbarn.org 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 bortzme...@nic.fr wrote: On Sat, Jul 04, 2015 at 09:16:17AM -0700, Steve Crocker st...@shinkuro.com 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?
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?
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?
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 Sat, Jul 04, 2015 at 09:16:17AM -0700, Steve Crocker st...@shinkuro.com 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?
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 p...@redbarn.org 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 bortzme...@nic.fr wrote: On Sat, Jul 04, 2015 at 09:16:17AM -0700, Steve Crocker st...@shinkuro.com 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 r...@bellis.me.uk 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?
On Jul 5, 2015, at 4:51 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Sat, Jul 04, 2015 at 09:16:17AM -0700, Steve Crocker st...@shinkuro.com 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 Sun, Jul 05, 2015 at 04:56:21AM -0700, Steve Crocker st...@shinkuro.com 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?
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 bortzme...@nic.fr wrote: On Sat, Jul 04, 2015 at 09:16:17AM -0700, Steve Crocker st...@shinkuro.com 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 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 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?
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 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?
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?
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?
(no hats) On Jul 4, 2015, at 3:12 AM, Patrik Fältström p...@frobbit.se 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?
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?
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?
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?
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 war...@kumari.net wrote: On Fri, Jul 3, 2015 at 9:43 AM, manning bmann...@karoshi.com 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 bmann...@karoshi.com wrote: On 2July2015Thursday, at 18:21, Robert Edmonds edmo...@mycre.ws 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?
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 bmann...@karoshi.com wrote: On 2July2015Thursday, at 18:21, Robert Edmonds edmo...@mycre.ws 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?
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 war...@kumari.net wrote: On Fri, Jul 3, 2015 at 9:43 AM, manning bmann...@karoshi.com 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 bmann...@karoshi.com wrote: On 2July2015Thursday, at 18:21, Robert Edmonds edmo...@mycre.ws 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?
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 bmann...@karoshi.com wrote: On 2July2015Thursday, at 18:21, Robert Edmonds edmo...@mycre.ws 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?
On Fri, Jul 3, 2015 at 9:43 AM, manning bmann...@karoshi.com 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 bmann...@karoshi.com wrote: On 2July2015Thursday, at 18:21, Robert Edmonds edmo...@mycre.ws 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?
On 7/3/15 7:01 AM, Warren Kumari wrote: On Fri, Jul 3, 2015 at 9:43 AM, manning bmann...@karoshi.com 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 bmann...@karoshi.com wrote: On 2July2015Thursday, at 18:21, Robert Edmonds edmo...@mycre.ws 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?
Hi, On Jul 3, 2015, at 11:18 AM, Patrik Fältström p...@frobbit.se 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 war...@kumari.net wrote: On Fri, Jul 3, 2015 at 9:43 AM, manning bmann...@karoshi.com 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 bmann...@karoshi.com wrote: On 2July2015Thursday, at 18:21, Robert Edmonds edmo...@mycre.ws 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
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 p...@frobbit.se 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 war...@kumari.net wrote: On Fri, Jul 3, 2015 at 9:43 AM, manning bmann...@karoshi.com 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 bmann...@karoshi.com wrote: On 2July2015Thursday, at 18:21, Robert Edmonds edmo...@mycre.ws 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
Re: [DNSOP] Some distinctions and a request - Have some class?
On 3July2015Friday, at 9:26, Suzanne Woolf suzworldw...@gmail.com 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?
-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 p...@frobbit.se 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 bmann...@karoshi.com wrote: On 3July2015Friday, at 9:26, Suzanne Woolf suzworldw...@gmail.com 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. and then a table, containing, amongst other things (including 'ICANN', 'IETF', 'IESG', 'RSSAC' and 'SSAC' (don't even get me started..)) all of the single labels in the Special Use Names registry and *Note that in addition to the above strings, ICANN will reserve translations of the terms “test” and “example” in multiple languages. The remainder of the strings are reserved only in the form included above. 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
