Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
(No hat) On Mar 14, 2014, at 10:33 PM, Tim Wicinsku tjw.i...@gmail.com wrote: On Mar 14, 2014, at 7:22 PM, Warren Kumari war...@kumari.net wrote: On Thu, Mar 6, 2014 at 9:36 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Tue, Mar 04, 2014 at 02:38:14PM +, Warren Kumari war...@kumari.net wrote a message of 39 lines which said: Which is why I think that some of this involves us[0] talking to ICANN and explaining the reason / purpose for ALT, and playing nice. OK, so we just have to find people who accept to devote the next N years of their life to a boring and unrewarding task, full of meetings and thick reports, with lawyers and politicians. You've found someone? :-) Well, I go to all the ICANN meetings already, so... And successfully defended a challenge from my employer's legal department to send me to ICANN. While I consider it a win though I think as WG chair I may need to go if it would help resolve this issue No need for anything rash. Several DNSOP regulars are already sentenced to ICANN meetings, including myself. And given that ICANN does not currently have any mechanism for even entertaining a new TLD application of any kind, there's little point in going to an ICANN meeting to lobby for one. Let's do our own homework on this, first. I think TIm and I owe the group an attempt at a summary of the discussion we had in London and on the mailing list, and possible ways forward. Suzanne ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Thu, Mar 6, 2014 at 9:36 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Tue, Mar 04, 2014 at 02:38:14PM +, Warren Kumari war...@kumari.net wrote a message of 39 lines which said: Which is why I think that some of this involves us[0] talking to ICANN and explaining the reason / purpose for ALT, and playing nice. OK, so we just have to find people who accept to devote the next N years of their life to a boring and unrewarding task, full of meetings and thick reports, with lawyers and politicians. You've found someone? :-) Well, I go to all the ICANN meetings already, so... W ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
Sent from my iPhone On Mar 14, 2014, at 7:22 PM, Warren Kumari war...@kumari.net wrote: On Thu, Mar 6, 2014 at 9:36 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Tue, Mar 04, 2014 at 02:38:14PM +, Warren Kumari war...@kumari.net wrote a message of 39 lines which said: Which is why I think that some of this involves us[0] talking to ICANN and explaining the reason / purpose for ALT, and playing nice. OK, so we just have to find people who accept to devote the next N years of their life to a boring and unrewarding task, full of meetings and thick reports, with lawyers and politicians. You've found someone? :-) Well, I go to all the ICANN meetings already, so... And successfully defended a challenge from my employer's legal department to send me to ICANN. While I consider it a win though I think as WG chair I may need to go if it would help resolve this issue W ___ 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] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Tue, Mar 04, 2014 at 02:38:14PM +, Warren Kumari war...@kumari.net wrote a message of 39 lines which said: Which is why I think that some of this involves us[0] talking to ICANN and explaining the reason / purpose for ALT, and playing nice. OK, so we just have to find people who accept to devote the next N years of their life to a boring and unrewarding task, full of meetings and thick reports, with lawyers and politicians. You've found someone? :-) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On 3 Mar 2014, at 14:19, Warren Kumari war...@kumari.net wrote: 3. The root zone nameservers should either return NXDOMAIN responses, or the ALT TLD should be delegated to new style AS112 nameservers. (TODO(WK): WK, JA, BD to revive AS112 / AS112-bis). New-style AS112 proposes redirection to an empty zone rather than delegation. There's no machinery currently available to deploy a DNAME in the root zone, as far as I know. Since the IANA uses EPP to submit change requests to Verisign for implementation, and since the implementation (RZM) has not suffered from rapid development in the past, I suspect (pragmatically speaking) this is a non-starter. Delegation of ALT from the root zone seems likely to be interpreted as a provocative end-run around the new gTLD process and seems likely to raise eyebrows, if not hairs on the backs of necks. I don't see an obvious path forward here. We are in a maze of twisty passages, all alike. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Tue, Mar 4, 2014 at 12:59 PM, Joe Abley jab...@hopcount.ca wrote: On 3 Mar 2014, at 14:19, Warren Kumari war...@kumari.net wrote: 3. The root zone nameservers should either return NXDOMAIN responses, or the ALT TLD should be delegated to new style AS112 nameservers. (TODO(WK): WK, JA, BD to revive AS112 / AS112-bis). New-style AS112 proposes redirection to an empty zone rather than delegation. There's no machinery currently available to deploy a DNAME in the root zone, as far as I know. Since the IANA uses EPP to submit change requests to Verisign for implementation, and since the implementation (RZM) has not suffered from rapid development in the past, I suspect (pragmatically speaking) this is a non-starter. Delegation of ALT from the root zone seems likely to be interpreted as a provocative end-run around the new gTLD process and seems likely to raise eyebrows, if not hairs on the backs of necks. Yes. Which is why I think that some of this involves us[0] talking to ICANN and explaining the reason / purpose for ALT, and playing nice. Explaining that this is not usable as a further delegation (you cannot register a usable *DNS* name under this), and it should (hopefully) stop people squatting on labels that might otherwise be available as future TLDs should help ease over some of the uneasiness. Basically saying There's an upcoming problem over here. Here's a mitigation option, we'd like to do $foo. and not Mine! Mine! We can do $foo and you can't stop us, mwahaahha. W [0]: Read: The IETF ICANN Liaison / someone involved in both communities. I don't see an obvious path forward here. We are in a maze of twisty passages, all alike. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Tue, Mar 4, 2014 at 2:38 PM, Warren Kumari war...@kumari.net wrote: On Tue, Mar 4, 2014 at 12:59 PM, Joe Abley jab...@hopcount.ca wrote: On 3 Mar 2014, at 14:19, Warren Kumari war...@kumari.net wrote: 3. The root zone nameservers should either return NXDOMAIN responses, or the ALT TLD should be delegated to new style AS112 nameservers. (TODO(WK): WK, JA, BD to revive AS112 / AS112-bis). New-style AS112 proposes redirection to an empty zone rather than delegation. There's no machinery currently available to deploy a DNAME in the root zone, as far as I know. Since the IANA uses EPP to submit change requests to Verisign for implementation, and since the implementation (RZM) has not suffered from rapid development in the past, I suspect (pragmatically speaking) this is a non-starter. Delegation of ALT from the root zone seems likely to be interpreted as a provocative end-run around the new gTLD process and seems likely to raise eyebrows, if not hairs on the backs of necks. Yes. Which is why I think that some of this involves us[0] talking to ICANN and explaining the reason / purpose for ALT, and playing nice. Explaining that this is not usable as a further delegation (you cannot register a usable *DNS* name under this), and it should (hopefully) stop people squatting on labels that might otherwise be available as future TLDs should help ease over some of the uneasiness. Basically saying There's an upcoming problem over here. Here's a mitigation option, we'd like to do $foo. and not Mine! Mine! We can do $foo and you can't stop us, mwahaahha. Sorry all, I'm sitting in the DNSE BoF, got over excited and clicked send before I was really finished. I think that the to delegate or not delegate bit is simply a detail / optimization. We also don't need to, and shouldn't go into all the discussions about who has the right to do this, who gave them the right, which side they crack the egg on, what size cookies they serve, etc. Let's figure out what the right answers are, and then figure out how (and if) we get there from here. W W [0]: Read: The IETF ICANN Liaison / someone involved in both communities. I don't see an obvious path forward here. We are in a maze of twisty passages, all alike. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On 4 Mar 2014, at 15:17, Warren Kumari war...@kumari.net wrote: Let's figure out what the right answers are, and then figure out how (and if) we get there from here. I realise I have my broken record hat on, but the only problem that reserving ALT solves is avoiding collision with an ALT TLD in the DNS. This seems good if you have the underlying assumption that all alternative namespaces necessarily need to be anchored under a TLD label. As should be tediously and abundantly clear, I'm (a) not convinced that's a sensible assumption and (b) I think the reservation of a TLD is not sufficient anyway to deal with leaked queries. I think we need a problem statement (and we need to test it) before we start assessing solutions. I don't agree that we can plausibly arrive at the right answers until we know the question (unless we're happy not understanding the answer, which leads us into Douglas Adams territory). That's more than enough from me. I am throwing this hat away. :-) Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
Warren makes a strong argument in favor of .alt I think. Another related aspect is that if something like onion.notreallydns.org is used, with notreallydns.org registered for the specific purpose of providing a home for one or more non-resolving dns-like names, it is very non-trivial to guarantee that whoever has registered the notreallydns.org name will continue paying the yearly fees forever. If the registration lapses, an attacker could become the new holder of the notreallydns.org domain and use it to snoop and/or serve malware... Greetings, Norbert Am Sun, 2 Mar 2014 22:20:48 + schrieb Warren Kumari war...@kumari.net: On Wed, Feb 26, 2014 at 2:34 PM, Joe Abley jab...@hopcount.ca wrote: On 26 Feb 2014, at 5:03, Mark Andrews ma...@isc.org wrote: In message d0ac0015-63c3-4c03-a8d0-888c435d2...@virtualized.org, David Conrad writes: On Feb 25, 2014, at 9:51 AM, Stuart Cheshire chesh...@apple.com wrote: If we have *some* pseudo-TLDs reserved for local-use names, I would think = http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#User-assigned_code_element= s would be appropriate for this purpose. Regards, -drc Whatever is used needs to be insecurely delegated so that in app validation will work. I still don't see why we need a TLD, or a delegation/reservation under ARPA. There are many, many TLDs under which an application/protocol implementer can reserve some namespace for their exclusive use at low cost ($10/year, say). Why is this approach not preferred for a new application/protocol? It seems far simpler. Yes, and it is -- but it means that leakages hit more folk. Perhaps all that is missing is some guidance that says you shouldn't hijack namespaces that you don't control, even for non-DNS applications; register a domain instead. Because for some things, people specifically do *not* want it to hit / go through the DNS -- this is why they have done this, and *not* just registered e.g onion.com... For example, I'm a *huge* Justin Beiber fan. I, and a bunch of my fellow closet Bieberites hang out on the-bieb-is-cool.onion. (you don't really think we want everyone to know that we obsess over every little antic, do you?) Last week I emailed my friend a link to http://www.the-bieb-is-cool.onion/Justins_New_Shoes.html. Unfortunately, he was just *so* excited to see that the Bieb has new sneakers that he clicked on the link from his phone (which doesn't have the ToR interceptor software installed). This, of course, means that the DNS like name, which should not really be used in a DNS context suddenly hit the DNS. Only his recursive and the root saw this, and that's embarrassing enough, thank you. This is bad enough, but if people built stuff like this under .onion.eff.org (or foo.onion.arpa), there would now be many more people in the list who knew our shameful little secret. Obviously this is a somewhat contrived example (after all, who wouldn't want to make it widely known that they *love* Justin Bieber!), but lets instead pretend I'm using an overlay network as a political dissident, or to discuss my sexual orientation, or... This is some of the justification behind the .ALT TLD proposal (http://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-00) -- create a special label to be used to denote that this is not actually a name in the DNS context. By reserving it as a special use name: A: It creates a safe namespace, secure from collision for people to root namespaces that have no meaning in a DNS context. B: when one of these names *does* leak (as they will), iterative resolvers will be authoritative, with an empty zone, so the-bieb-is-cool.onion.alt only gets seen by the iterative and goes no further. C: When one does go further (as they will), the root can delegate to AS112, while can squash it. D: 4 years from now, when someone comes along and says I created a shiny new directory system. I used something that looks like DNS names, and I placed it under .pony. Please reserve that for me the IESG can at least say But we told you not to do that... They can also a: reserve it, b: not, or c: we can have another thread about this all again, but now at least we can nod knowingly and feel all superior... W P.S: Note: I did *not* say what should happen with the current pseudo-TLDs / colliding names. They can move under .ALT or they can not. The IESG can reserve them, or not, or bury them in peat, or paint them purple and dress them in wellies. I have views on what I think makes sense, but that's a separate mail. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dn ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On 3/3/14, 9:25 AM, Norbert Bollow wrote: Warren makes a strong argument in favor of .alt I think. yeah... anything that has the potential to result in additional leakage seems like a recipe for additional pain. Another related aspect is that if something like onion.notreallydns.org is used, with notreallydns.org registered for the specific purpose of providing a home for one or more non-resolving dns-like names, it is very non-trivial to guarantee that whoever has registered the notreallydns.org name will continue paying the yearly fees forever. If the registration lapses, an attacker could become the new holder of the notreallydns.org domain and use it to snoop and/or serve malware... Greetings, Norbert Am Sun, 2 Mar 2014 22:20:48 + schrieb Warren Kumari war...@kumari.net: On Wed, Feb 26, 2014 at 2:34 PM, Joe Abley jab...@hopcount.ca wrote: On 26 Feb 2014, at 5:03, Mark Andrews ma...@isc.org wrote: In message d0ac0015-63c3-4c03-a8d0-888c435d2...@virtualized.org, David Conrad writes: On Feb 25, 2014, at 9:51 AM, Stuart Cheshire chesh...@apple.com wrote: If we have *some* pseudo-TLDs reserved for local-use names, I would think = http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#User-assigned_code_element= s would be appropriate for this purpose. Regards, -drc Whatever is used needs to be insecurely delegated so that in app validation will work. I still don't see why we need a TLD, or a delegation/reservation under ARPA. There are many, many TLDs under which an application/protocol implementer can reserve some namespace for their exclusive use at low cost ($10/year, say). Why is this approach not preferred for a new application/protocol? It seems far simpler. Yes, and it is -- but it means that leakages hit more folk. Perhaps all that is missing is some guidance that says you shouldn't hijack namespaces that you don't control, even for non-DNS applications; register a domain instead. Because for some things, people specifically do *not* want it to hit / go through the DNS -- this is why they have done this, and *not* just registered e.g onion.com... For example, I'm a *huge* Justin Beiber fan. I, and a bunch of my fellow closet Bieberites hang out on the-bieb-is-cool.onion. (you don't really think we want everyone to know that we obsess over every little antic, do you?) Last week I emailed my friend a link to http://www.the-bieb-is-cool.onion/Justins_New_Shoes.html. Unfortunately, he was just *so* excited to see that the Bieb has new sneakers that he clicked on the link from his phone (which doesn't have the ToR interceptor software installed). This, of course, means that the DNS like name, which should not really be used in a DNS context suddenly hit the DNS. Only his recursive and the root saw this, and that's embarrassing enough, thank you. This is bad enough, but if people built stuff like this under .onion.eff.org (or foo.onion.arpa), there would now be many more people in the list who knew our shameful little secret. Obviously this is a somewhat contrived example (after all, who wouldn't want to make it widely known that they *love* Justin Bieber!), but lets instead pretend I'm using an overlay network as a political dissident, or to discuss my sexual orientation, or... This is some of the justification behind the .ALT TLD proposal (http://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-00) -- create a special label to be used to denote that this is not actually a name in the DNS context. By reserving it as a special use name: A: It creates a safe namespace, secure from collision for people to root namespaces that have no meaning in a DNS context. B: when one of these names *does* leak (as they will), iterative resolvers will be authoritative, with an empty zone, so the-bieb-is-cool.onion.alt only gets seen by the iterative and goes no further. C: When one does go further (as they will), the root can delegate to AS112, while can squash it. D: 4 years from now, when someone comes along and says I created a shiny new directory system. I used something that looks like DNS names, and I placed it under .pony. Please reserve that for me the IESG can at least say But we told you not to do that... They can also a: reserve it, b: not, or c: we can have another thread about this all again, but now at least we can nod knowingly and feel all superior... W P.S: Note: I did *not* say what should happen with the current pseudo-TLDs / colliding names. They can move under .ALT or they can not. The IESG can reserve them, or not, or bury them in peat, or paint them purple and dress them in wellies. I have views on what I think makes sense, but that's a separate mail. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dn ___ DNSOP mailing list DNSOP@ietf.org
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On 03/03/2014 09:25 AM, Norbert Bollow wrote: Warren makes a strong argument in favor of .alt I think. Another related aspect is that if something like onion.notreallydns.org is used, with notreallydns.org registered for the specific purpose of providing a home for one or more non-resolving dns-like names, it is very non-trivial to guarantee that whoever has registered the notreallydns.org name will continue paying the yearly fees forever. If the registration lapses, an attacker could become the new holder of the notreallydns.org domain and use it to snoop and/or serve malware... more generally, even if one person/institution holds that name forever, they/it can change their mind about catching the data there (and/or responding to it). So your protocol/security tradeoffs change when this approach is chosen compared to reserving it for explicit non-use. While the reservation can be pulled anyway, IMO it would be a much greater barrier should one try to do so. (not leaning either way myself at this point) Jelte ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On 3 Mar 2014, at 9:51, joel jaeggli joe...@bogus.com wrote: On 3/3/14, 9:25 AM, Norbert Bollow wrote: Warren makes a strong argument in favor of .alt I think. yeah... anything that has the potential to result in additional leakage seems like a recipe for additional pain. Well, except that the current proposal is to reserve (not delegate) ALT. If we assume that leaks will happen, then they will hit the root servers and there's no opportunity to sink the queries anywhere else. If we delegate ALT, then we have to decide where to. I can see this being contentious. Joe signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Mar 3, 2014, at 1:07 PM, Joe Abley jab...@hopcount.ca wrote: If we assume that leaks will happen, then they will hit the root servers and there's no opportunity to sink the queries anywhere else. This will happen whether the special-domain is under ALT or is itself a TLD. If we delegate ALT, then we have to decide where to. I can see this being contentious. It seems to me that it would be highly preferable not to delegate it. Is there an argument for doing so? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On 3 Mar 2014, at 13:17, Ted Lemon ted.le...@nominum.com wrote: On Mar 3, 2014, at 1:07 PM, Joe Abley jab...@hopcount.ca wrote: If we assume that leaks will happen, then they will hit the root servers and there's no opportunity to sink the queries anywhere else. This will happen whether the special-domain is under ALT or is itself a TLD. Ah, but in the case of a delegated ALT TLD, the referral will be cached and hence subsequent/repeated queries will be sunk elsewhere. If we delegate ALT, then we have to decide where to. I can see this being contentious. It seems to me that it would be highly preferable not to delegate it. Me too. Is there an argument for doing so? See above. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Mar 3, 2014, at 1:22 PM, Joe Abley jab...@hopcount.ca wrote: See above. Right. Ugh. How about delegating it to 127.0.0.27? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
Ted Lemon ted.le...@nominum.com wrote: It seems to me that it would be highly preferable not to delegate it. Is there an argument for doing so? As well as Joe's AS112 argument there is also the question of DNSSEC validation - but perhaps we don't want non-DNS names to make any kind of sense in this respect... cf. .local Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Trafalgar: Northwest 6 or 7, decreasing 5. Moderate or rough in far southeast, otherwise rough or very rough, becoming high. Showers. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Mar 3, 2014, at 1:32 PM, Tony Finch d...@dotat.at wrote: As well as Joe's AS112 argument there is also the question of DNSSEC validation - but perhaps we don't want non-DNS names to make any kind of sense in this respect... cf. .local Indeed, it doesn't make much sense to me that special-use names that are not intended to be resolved using the DNS should be validateable via DNSSEC. If they can be validated, it would have to be using whatever protocol is being used for name resolution (if any). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On 03/03/2014 01:43 PM, Ted Lemon wrote: On Mar 3, 2014, at 1:32 PM, Tony Finch d...@dotat.at wrote: As well as Joe's AS112 argument there is also the question of DNSSEC validation - but perhaps we don't want non-DNS names to make any kind of sense in this respect... cf. .local Indeed, it doesn't make much sense to me that special-use names that are not intended to be resolved using the DNS should be validateable via DNSSEC. If they can be validated, it would have to be using whatever protocol is being used for name resolution (if any). +1 This is something I asked about at the app session, and have been wondering; (why) are we worried about non-dns names at all? More importantly, where do we draw the line? A domain by any other name? Is anything sequence of characters that happens to maybe contain a dot a domain name? Is it that it *might* end up in some code path that tries to resolve it, even though the normal use doesn't use (the global) DNS at all? To make a crazy example; the left-hand side of an e-mail address also contains dots, but we're not worried about those somehow ending up in a resolution call. Neither were we worried about 'command.com' being resolved (and it does). I'd think that a domain name is only a domain name when whatever protocol it is defined in defines it as a domain name (or whatever undefined protocol uses it in actual dns resolution). What a non-domain name looks like shouldn't matter. Jelte ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On 03/03/2014 02:03 PM, Andrew Sullivan wrote: On Mon, Mar 03, 2014 at 01:56:20PM +, Jelte Jansen wrote: I'd think that a domain name is only a domain name when whatever protocol it is defined in defines it as a domain name (or whatever undefined protocol uses it in actual dns resolution). What a non-domain name looks like shouldn't matter. Are NetBIOS names domain names? How about mDNS names? I think yes, but neither is part of the DNS as such. I was wondering whether I should have stated that a bit more carefully, but 'part of the DNS' might be a different thing than 'could use DNS'. I wasn't suggesting there shouldn't be any reservations, but 'looks like a domain name' is way, way too wide a definition. In that case we need to reserve any possible TLD. Including all existing gTLD and ccTLD's. As for mDNS, I do not know; you tell me :) Is there a problem in anything that is *not* either a definite bug in a program or a user copy-pasting the name in a browser window? Jelte ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Mon, Mar 3, 2014 at 1:07 PM, Joe Abley jab...@hopcount.ca wrote: On 3 Mar 2014, at 9:51, joel jaeggli joe...@bogus.com wrote: On 3/3/14, 9:25 AM, Norbert Bollow wrote: Warren makes a strong argument in favor of .alt I think. yeah... anything that has the potential to result in additional leakage seems like a recipe for additional pain. Well, except that the current proposal is to reserve (not delegate) ALT. Weelll Actually it says (Section 3): 1. Stub resolvers MAY elect not to send queries to any upstream resolver for names in the ALT TLD. 2. Iterative resolvers SHOULD follow the advice in [RFC6303], Section 3. 3. The root zone nameservers should either return NXDOMAIN responses, or the ALT TLD should be delegated to new style AS112 nameservers. (TODO(WK): WK, JA, BD to revive AS112 / AS112-bis). Item 3 is specifically about this question -- it can either be that the root continues to not know about the ALT TLD[0] or it could be delegated to a new style AS112, which will, in theory, happily sink $whatever. That's an open question, but (IMO) a detail. W [0]: Much of this draft and discussion is made complicated by terminology problems. If someone uses www.foo.tld in their own protocol, it the rightmost label a TLD? Probably not... But, if the name (which is *not* a DNS name), but is DNS like leaks into the DNS, then it is... If we assume that leaks will happen, then they will hit the root servers and there's no opportunity to sink the queries anywhere else. If we delegate ALT, then we have to decide where to. I can see this being contentious. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On 26 Feb, 2014, at 06:34, Joe Abley jab...@hopcount.ca wrote: I still don’t see why we need a TLD, or a delegation/reservation under ARPA. There are many, many TLDs under which an application/protocol implementer can reserve some namespace for their exclusive use at low cost ($10/year, say). Why is this approach not preferred for a new application/protocol? It seems far simpler. The issue is home gateway vendors who want to sell a $49 home gateway that “just works”, out of the box, without the customer having to go though some confusing registration process (that also costs them $10/year, say) to use that home gateway product in their own home. Such products ship today with “.home” hard-coded into them, and all our pontificating about registration processes is not going to change that. Stuart Cheshire ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Wed, Jan 08, 2014 at 01:18:09PM -0500, Suzanne Woolf suzworldw...@gmail.com wrote a message of 215 lines which said: This new internet-draft is another request for additions to the RFC 6761 special names registry, There is even better now, there is a .DNS :-) http://blog.okturtles.com/2014/02/introducing-the-dotdns-metatld/ Because it is very recent, it has no installed user base. This may be a good opportunity to get in touch with the author(s) and ask them if they would be willing to accept a dns.alt or something like that. Any volunteer for outreach? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Feb 26, 2014, at 6:34 AM, Joe Abley jab...@hopcount.ca wrote: Perhaps all that is missing is some guidance that says “you shouldn’t hijack namespaces that you don’t control, even for non-DNS applications; register a domain instead”. +1, with a short list of things that can go wrong if you hijack. I'd be willing to write that up (maybe with Joe; his sardonic humor is more fun than mine) if people here think it would move forward as an update to RFC 6761. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
Joe, On Feb 26, 2014, at 10:34 PM, Joe Abley jab...@hopcount.ca wrote: On Feb 25, 2014, at 9:51 AM, Stuart Cheshire chesh...@apple.com wrote: If we have *some* pseudo-TLDs reserved for local-use names, I still don’t see why we need a TLD, or a delegation/reservation under ARPA. Because if something isn't documented, people tend to squat. There are many, many TLDs under which an application/protocol implementer can reserve some namespace for their exclusive use at low cost ($10/year, say). Why is this approach not preferred for a new application/protocol? It seems far simpler. Why does RFC 1918 address space exist? Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
Perhaps all that is missing is some guidance that says �you shouldn�t hijack namespaces that you don�t control, even for non-DNS applications; register a domain instead�. That's a relatively high bar for all the residential broadband users who buy a router at Best Buy (Future Shop to you), plug it in, and set up the router via the configuration page at http://router.home. What do they get for their $10/yr and extra config hassle that they would care about? R's, John PS: Don't miss ICANN's latest on this point: http://www.icann.org/en/news/announcements/announcement-26feb14-en.htm They commissioned a report that says to reserve .HOME .CORP and .MAIL, and to do a 120 day wildcard on new domains that returns 127.0.53.53 to alert people to upcoming problems and see what the traffic is. It notably does not suggest how to interpret the results after the 120 days. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
In message 6f605b46-51ad-4a21-ba3e-5723aa843...@virtualized.org, David Conrad writes: Joe, On Feb 26, 2014, at 10:34 PM, Joe Abley jab...@hopcount.ca wrote: On Feb 25, 2014, at 9:51 AM, Stuart Cheshire chesh...@apple.com wrote: If we have *some* pseudo-TLDs reserved for local-use names, I still don't see why we need a TLD, or a delegation/reservation under ARPA. Because if something isn't documented, people tend to squat. There are many, many TLDs under which an application/protocol implementer can reserve some namespace for their exclusive use at low cost ($10/year, say). Why is this approach not preferred for a new application/protocol? It seems far simpler. Why does RFC 1918 address space exist? Because IPv4 address were and always have been a scarse resource and RFC 1918 is a reaction to that. Homes use it because CPE vendors built it into their devices because * Lots of ISP's would only give you one address * Those that didn't often charged you a lot * Ridiculous ISP terms and conditions that prohibited multiple machines. Regards, -drc --Apple-Mail=_196EAF71-9F8C-416D-8D37-7BD2EBF86381 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJTDnaKAAoJENV6ebf0/4rXSUgH/jz+HlRsm7xmjLRg0RP/vHAn j9WnJB5RASC7wjTmj/KplNQzyMZvmgSwcF8NlZNwE9/L/pUA8bjguj2nMni/irnw 73BA/39fc1vlFNi6n1UuTEjFx9w2fYoxFk2x0Zjf2xd0U/THJhWisggFohXy0T5H 0iGIpAAr07Kj3y1QR0R59TMjZ0usxLDd0V9CZdoZcJzwRyqCFrJJS7twLtDvYWyl xmUPViNyeRbw8tbnHKFiGukGgeZeccjDF6qiSFlsKP1zPJAScUE4+9PC+JGCDrN+ ScyLGer3DOh5mVvFwENwwXeRHvoBQsml9byI8FkDqGB+r1ChuTqGHs3VP1UcY2Q= =1Gi3 -END PGP SIGNATURE- --Apple-Mail=_196EAF71-9F8C-416D-8D37-7BD2EBF86381-- --===0999451085410326449== Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop --===0999451085410326449==-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
In message 20140226233907.6214.qm...@joyce.lan, John Levine writes: Perhaps all that is missing is some guidance that says you shouldn't hijack namespaces that you don't control, even for non-DNS applications; register a domain instead. That's a relatively high bar for all the residential broadband users who buy a router at Best Buy (Future Shop to you), plug it in, and set up the router via the configuration page at http://router.home. And why wasn't that http://router.netgear.com; or http://router.linksys.com;. The router could easily serve the zone locally and the vendor could have a insecure delegation to it so it works if there are validating browsers being used. http://router.home does not work with validating browsers. If the CPE vendors want to use .home let them pony up the 100K for it rather than hijack the namespace. What do they get for their $10/yr and extra config hassle that they would care about? R's, John PS: Don't miss ICANN's latest on this point: http://www.icann.org/en/news/announcements/announcement-26feb14-en.htm They commissioned a report that says to reserve .HOME .CORP and .MAIL, and to do a 120 day wildcard on new domains that returns 127.0.53.53 to alert people to upcoming problems and see what the traffic is. It notably does not suggest how to interpret the results after the 120 days. --===4405462344142669891== Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop --===4405462344142669891==-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
That's a relatively high bar for all the residential broadband users who buy a router at Best Buy (Future Shop to you), plug it in, and set up the router via the configuration page at http://router.home. And why wasn't that http://router.netgear.com; or http://router.linksys.com;. I dunno, but that doesn't help much once the network is online and there are other devices with .home names. If the CPE vendors want to use .home let them pony up the 100K for it rather than hijack the namespace. Um, it's a wee bit late for that. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Feb 26, 2014, at 3:39 PM, John Levine jo...@taugh.com wrote: Perhaps all that is missing is some guidance that says �you shouldn�t hijack namespaces that you don�t control, even for non-DNS applications; register a domain instead�. That's a relatively high bar for all the residential broadband users who buy a router at Best Buy (Future Shop to you), plug it in, and set up the router via the configuration page at http://router.home. Ummm, why do those people need to have a unique domain name at all? PS: Don't miss ICANN's latest on this point: http://www.icann.org/en/news/announcements/announcement-26feb14-en.htm That's unrelated to this point, it seems. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
In message 20140227031921.7962.qm...@joyce.lan, John Levine writes: That's a relatively high bar for all the residential broadband users who buy a router at Best Buy (Future Shop to you), plug it in, and set up the router via the configuration page at http://router.home. And why wasn't that http://router.netgear.com; or http://router.linksys.com;. I dunno, but that doesn't help much once the network is online and there are other devices with .home names. Whether is it router.home or router.vendor.com, both names assume that the CPE device is in the DNS lookup path to get the correct address returned for the name. If the CPE puts out a search list of home.arpa rather than home in the DHCP lease and added the machines to home.arpa rather than home zone I doubt many people would notice. Most home users would be using unqualified names and the resolver's search will qualify them. This is all about getting sensible defaults in new CPE devices and have a reserved place for them. This should already be configurable if they doing this sort of thing. If the CPE vendors want to use .home let them pony up the 100K for it rather than hijack the namespace. Um, it's a wee bit late for that. R's, John -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Feb 4, 2014, at 8:06 PM, joel jaeggli joe...@bogus.com wrote: resolver libraries are being asked to make a decision on the basis of .tld how to handle a query we gone down an extensibility rathole that's hard to get out of. Lookup tables are hard... :) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On 4 Feb 2014, at 01:21, Andrew Sullivan a...@anvilwalrusden.com wrote: If you want to use a name in DNS protocol slots, then you need a DNS name. You didn't get a DNS name, and instead you used a label that wasn't under your control. That's been against the rules in the DNS since forever. Now you want to short-circuit the allocation mechanism. But we have an allocation mechanism for this. In the normal case, you apply to ICANN. In an unusual case where the protocol depends on this, then you can use this special-use registry. So you need to show that your protocol needs to depend on this special-use label, and then we can register it under the special use mechanism. Otherwise go to ICANN. +100. I hope everyone here can agree on the above and we get back to discussing the actual draft. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Tue, Feb 04, 2014 at 08:23:33AM +1100, Mark Andrews ma...@isc.org wrote a message of 62 lines which said: There were plenty of people saying Do NOT use a TLD for your private namespace, use a namespace you own in 2002 whether it was for a protocol or a internal network. Hmmm, the experience of many developers is that, no, it is not easy to get advice from the IETF. Some did not even bother but those who did were often turned down immediately. Let's play an experiment. In 2014, Joe Developer has a bright idea of using cryptographic keys as domain names (yes, I know, there is already the zkeys of GNUnet), he is going to write code to implement it and wants a suffix for that, to be sure his domain names won't collide with the ICANN root. Knowing nothing about Internet governance, not having 185 000 US $ and a zillion lawyers at his disposal to request a TLD, not being Apple, with the ability to squatt a TLD and deploy it massively, he sends an email to dnsop or namedroppers asking about advice. What happens? 1) (Most likely) He gets no reply at all because nobody knows him and he never appeared in an IETF meeting 2) He gets a few messages saying that's a bad idea, don't do that, for reasons explained in [insert a long list of RFC] 3) He gets a ton of messages saying it is a stupid idea and he is endangering the security and stability of the Internet 4) He gets a sensible advice, based on a careful study of his proposal, and given by people who forgives him for making a few mistakes such as not being able to know what is the difference between IETF and ICANN In the first three cases, what will he do? He will follow the usual Internet/free software method, implement and distribute and we'll see what happens. And then it will be too late to change what's in his code. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Tue, Feb 04, 2014 at 01:45:11AM +, jonne.soini...@broadcom.com jonne.soini...@broadcom.com wrote a message of 88 lines which said: They are not DNS and not even specified in the IETF. They have taken a design choice where they look like DNS No, that's not a correct description. These proposals use domain names (not things that look like domain names). Domain names are *older* than the DNS (see RFC 810 and many others). They can be resolved by several protocols (DNS, Bonjour, /etc/hosts, LDAP, whatever). It is perfectly sensible to use domain names for new protocols. you want a TLD you go to ICANN. Regardless of what people think of that process, this is the process we have created already a long time ago If we is the US governement, the sentence is true. Otherwise, no, I had no part in the ICANN creation. I remember a discussion with Stuart Cheshire where he explained that IETF, not ICANN, created the entire name space, since it created the rules, and therefore has rights above those of ICANN. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Tue, Feb 04, 2014 at 09:51:34AM +0100, Stephane Bortzmeyer wrote: had no part in the ICANN creation. I remember a discussion with Stuart Cheshire where he explained that IETF, not ICANN, created the entire name space, since it created the rules, and therefore has rights above those of ICANN. With respect, while that is one view of the history, it is surely not the only one, and it seems to me it is one that is not shared by all the actors in this space. Most importantly, it involves a false dichotomy between ICANN and IETF: neither organization existed at the time the DNS name space was created, so it's hard to credit the idea that either of them created the name space. I do not think we want to turn over the rock labelled, Who owns the DNS name space? Under that rock live all manner of creatures from layer 9 and above. We have two allocation procedures: regular allocation via IANA procedures (which happen to be defined right now in ICANN) and RFC 6761. One of those procedures is the one we can exercise, and I still believe the only question is whether any particular registration attempt works under RFC 6761. I agree with Ted Lemon that the question of what happened in the past is not exactly relevant. What _is_ relevant in my view is how these names need to be used in support of the protocols they're supposed to be supporting. This is exactly the same question I had since I first read the grothoff draft; see my earlier review. Best, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On 2014-02-04, at 01:39, John Levine jo...@taugh.com wrote: I suppose the situation with .onion is slightly different, but in concept it's not all that different from .arpa. I think it's quite different. ARPA is really no different from any other TLD. There's a registry, there are rules you need to follow to get a delegation, but it's a zone in the DNS just like COM and ORG. ONION is a namespace convention outside the DNS. There's no registry, it's not a zone, and there is no possibility of getting a delegation. ONION is like LOCAL. Neither are like ARPA (or any other TLD). Joe signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
Joe Abley wrote: ... ONION is like LOCAL. Neither are like ARPA (or any other TLD). How like LOCAL is ONION? ICANN knows it can't sell .LOCAL, but does ICANN know it can't sell .ONION ? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On 2014-02-04, at 10:00, Paul Vixie p...@redbarn.org wrote: Joe Abley wrote: ... ONION is like LOCAL. Neither are like ARPA (or any other TLD). How like LOCAL is ONION? Neither is a zone in the DNS or a domain in the DNS namespace, and both refer to names for which a protocol other than DNS should be used for resolution. (I realise the protocol for LOCAL is DNS-like, but it's not DNS, right?) ICANN knows it can't sell .LOCAL, but does ICANN know it can't sell .ONION ? I was never quite sure what ICANN knew, even when I worked for ICANN. I'm not arguing against the IETF protecting the world from conflicting ONION namespaces in the same way that they did with LOCAL, which would have the effect that ICANN would not sell ONION. I agree that if ICANN sold ONION to someone, the result would be messy. However, I don't think ambiguity in the discussion about the namespaces we're talking about or the failure modes we're hoping to avoid helps us narrow in on anything resembling consensus. Joe signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On 2/4/14, 12:42 AM, Stephane Bortzmeyer wrote: On Mon, Feb 03, 2014 at 09:54:41PM +, jonne.soini...@broadcom.com jonne.soini...@broadcom.com wrote a message of 112 lines which said: maybe we should consider to discuss the principles under which TLDs can be reserved for special use and consider a re-spin or an update to RFC6761. So, RFC 6761 was written just to allow Apple to register .local and, once it is done, we close the door to new registrations? That in and of itself would be a bit of a moral hazard. it's plausible that this one case is simply more clear cut (certainly in the minds of the authors) then others. I don't believe that we did this (6761) so that we could treat this as a one-off event. it's my personal opinion that application specific namespaces should be treated differently in some way, if resolver libraries are being asked to make a decision on the basis of .tld how to handle a query we gone down an extensibility rathole that's hard to get out of. ___ 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] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Thu, Jan 30, 2014 at 11:45:30AM +1100, Mark Andrews ma...@isc.org wrote a message of 74 lines which said: The squatted tld's used by software .onion, .bit etc could be migrated to a new namespaces. :-) squatted is not a bad word here. In the physical world, squatters are often people who do not have the money to rent a home, because some rich people put the price of the housing too high. Here, you will have trouble convincing the users of Tor or Namecoin that it is right to pay 185 000 $ for a TLD and that, if they cannot afford it, they have to stay in the slums. [End of political rant, sorry] ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
In message acf06352-98e5-4368-a8c9-5ab50783c...@hopcount.ca, Joe Abley writes: On 2014-02-03, at 11:15, Paul Hoffman paul.hoff...@vpnc.org wrote: On Feb 3, 2014, at 7:19 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: squatted is not a bad word here. In the physical world, squatters are often people who do not have the money to rent a home, because some rich people put the price of the housing too high. Here, you will have trouble convincing the users of Tor or Namecoin that it is right to pay 185 000 $ for a TLD and that, if they cannot afford it, they have to stay in the slums. [End of political rant, sorry] Your political rant is, however, off-base. Assume for the moment that the Tor folks had registered oniontld.fr for a relatively small amount of money. It could have all of the attributes of .onion: you could hard-wire it into local resolvers, some requests for it would leak to the DNS and therefore possibly be trackable, and so on. For the purposes given in draft-grothoff-iesg-special-use-p2p-names, unsquatted FQDNs would work just as well as squatted TLDs. I made that point somewhat earlier (but my example was onion.eff.org or something). The reasonable response to my instance of that observation was that there's a significant deployed base of users already making use of .onion [1], and we don't have a time machine that we're aware of [2] to allow that to be fixed. Despite the enduring (and endearing, perhaps) optimism that the new gTLD programme would eventually bear fruit, I don't think it's unreasonable to think that in 2002 [3] a new gTLD wasn't really a practical option to choose not to take. So squatting doesn't sound right to me. They choose to use a TLD. There were plenty of people saying Do NOT use a TLD for your private namespace, use a namespace you own in 2002 whether it was for a protocol or a internal network. For $20 a year or less they could have registered a name in just about any TLD and avoided the issue. Joe [1] https://metrics.torproject.org [2] = http://www.huffingtonpost.co.uk/2012/07/02/stephen-hawking-time-travel_n_1= 643488.html [3] http://en.wikipedia.org/wiki/Tor_(anonymity_network)#History -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Mon, Feb 03, 2014 at 04:56:38PM -0500, Ted Lemon wrote: This is a useless discussion. Recriminations do not change the past. True, but effectively what you're saying is that this special-use registry could be used by anyone who's prepared to [squat|use a TLD without registering it] in the right ways to get around the ICANN allocation procedures. I think that's spelled moral hazard in economics. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
Hi everybody, (just for full closure - I'm the IETF technical liaison to the ICANN board, but taking that hat off here) On 2/3/14 11:23 PM, Mark Andrews ma...@isc.org wrote: In message acf06352-98e5-4368-a8c9-5ab50783c...@hopcount.ca, Joe Abley writes: On 2014-02-03, at 11:15, Paul Hoffman paul.hoff...@vpnc.org wrote: On Feb 3, 2014, at 7:19 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: squatted is not a bad word here. In the physical world, squatters are often people who do not have the money to rent a home, because some rich people put the price of the housing too high. Here, you will have trouble convincing the users of Tor or Namecoin that it is right to pay 185 000 $ for a TLD and that, if they cannot afford it, they have to stay in the slums. [End of political rant, sorry] Your political rant is, however, off-base. Assume for the moment that the Tor folks had registered oniontld.fr for a relatively small amount of money. It could have all of the attributes of .onion: you could hard-wire it into local resolvers, some requests for it would leak to the DNS and therefore possibly be trackable, and so on. For the purposes given in draft-grothoff-iesg-special-use-p2p-names, unsquatted FQDNs would work just as well as squatted TLDs. I made that point somewhat earlier (but my example was onion.eff.org or something). The reasonable response to my instance of that observation was that there's a significant deployed base of users already making use of .onion [1], and we don't have a time machine that we're aware of [2] to allow that to be fixed. Despite the enduring (and endearing, perhaps) optimism that the new gTLD programme would eventually bear fruit, I don't think it's unreasonable to think that in 2002 [3] a new gTLD wasn't really a practical option to choose not to take. So squatting doesn't sound right to me. They choose to use a TLD. There were plenty of people saying Do NOT use a TLD for your private namespace, use a namespace you own in 2002 whether it was for a protocol or a internal network. For $20 a year or less they could have registered a name in just about any TLD and avoided the issue. I think we have to distinguish here between the new squatters and the old squatters and the reasons for squatting. For instance in corp and home, the installed base seems to be quite large. It comes from equipment and hardware that might not be easily replaceable and not really under a single organization's control. You cannot change that and ignoring it might cause harm for the Internet. The new technologies (gnu/onion/...) seem to be different. First of all, they don't use DNS but something else. Therefore, there should be no collisions. It seems more that delegating them to the DNS would harm those technologies rather than DNS or Internet getting harmed. The only relationship to the DNS seems to be that they happen to have a structure that is similar to the FQDN. Anyways, I have been following this discussion now for a while. It seems to me that the discussion is not really converging. I would blame it at least partly on RFC6761. Though, RFC6761 isn't that old, it was written in a time before the new gTLD round was ongoing. Rather than discussing the individual strings, maybe we should consider to discuss the principles under which TLDs can be reserved for special use and consider a re-spin or an update to RFC6761. Cheers, Jonne. Joe [1] https://metrics.torproject.org [2] = http://www.huffingtonpost.co.uk/2012/07/02/stephen-hawking-time-travel_n_ 1= 643488.html [3] http://en.wikipedia.org/wiki/Tor_(anonymity_network)#History -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
I am not personally convinced by there are too many people committed arguments. I never have been, and I think the chilling effect of this has been seen time and again. There has always been too many people doing things. Claiming the dead hand of history prevents us from changing course or deploying new things is just wrong. 1 create onion.something.else and mark .onion as suitable for future use under gTLD, if not now 2 release new TOR code and declare sunset period 3 wait for sunset period 4 stop blocking release of .onion We don't expect people to use rlogin or rsh any more. Protocols move on. On Tue, Feb 4, 2014 at 7:54 AM, jonne.soini...@broadcom.com wrote: Hi everybody, (just for full closure - I'm the IETF technical liaison to the ICANN board, but taking that hat off here) On 2/3/14 11:23 PM, Mark Andrews ma...@isc.org wrote: In message acf06352-98e5-4368-a8c9-5ab50783c...@hopcount.ca, Joe Abley writes: On 2014-02-03, at 11:15, Paul Hoffman paul.hoff...@vpnc.org wrote: On Feb 3, 2014, at 7:19 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: squatted is not a bad word here. In the physical world, squatters are often people who do not have the money to rent a home, because some rich people put the price of the housing too high. Here, you will have trouble convincing the users of Tor or Namecoin that it is right to pay 185 000 $ for a TLD and that, if they cannot afford it, they have to stay in the slums. [End of political rant, sorry] Your political rant is, however, off-base. Assume for the moment that the Tor folks had registered oniontld.fr for a relatively small amount of money. It could have all of the attributes of .onion: you could hard-wire it into local resolvers, some requests for it would leak to the DNS and therefore possibly be trackable, and so on. For the purposes given in draft-grothoff-iesg-special-use-p2p-names, unsquatted FQDNs would work just as well as squatted TLDs. I made that point somewhat earlier (but my example was onion.eff.org or something). The reasonable response to my instance of that observation was that there's a significant deployed base of users already making use of .onion [1], and we don't have a time machine that we're aware of [2] to allow that to be fixed. Despite the enduring (and endearing, perhaps) optimism that the new gTLD programme would eventually bear fruit, I don't think it's unreasonable to think that in 2002 [3] a new gTLD wasn't really a practical option to choose not to take. So squatting doesn't sound right to me. They choose to use a TLD. There were plenty of people saying Do NOT use a TLD for your private namespace, use a namespace you own in 2002 whether it was for a protocol or a internal network. For $20 a year or less they could have registered a name in just about any TLD and avoided the issue. I think we have to distinguish here between the new squatters and the old squatters and the reasons for squatting. For instance in corp and home, the installed base seems to be quite large. It comes from equipment and hardware that might not be easily replaceable and not really under a single organization's control. You cannot change that and ignoring it might cause harm for the Internet. The new technologies (gnu/onion/...) seem to be different. First of all, they don't use DNS but something else. Therefore, there should be no collisions. It seems more that delegating them to the DNS would harm those technologies rather than DNS or Internet getting harmed. The only relationship to the DNS seems to be that they happen to have a structure that is similar to the FQDN. Anyways, I have been following this discussion now for a while. It seems to me that the discussion is not really converging. I would blame it at least partly on RFC6761. Though, RFC6761 isn't that old, it was written in a time before the new gTLD round was ongoing. Rather than discussing the individual strings, maybe we should consider to discuss the principles under which TLDs can be reserved for special use and consider a re-spin or an update to RFC6761. Cheers, Jonne. Joe [1] https://metrics.torproject.org [2] = http://www.huffingtonpost.co.uk/2012/07/02/stephen-hawking-time-travel_n_ 1= 643488.html [3] http://en.wikipedia.org/wiki/Tor_(anonymity_network)#History -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
Its a scaling question. Please don't sidetrack into distaste, its the question of preventing progress by saying too many when in fact, its tractable, and its software. .onion is an eminently tractable problem. Arguing otherwise is to argue the current .onion codebase dependency cannot move, therefore any future CVE against TOR cannot be fixed, therefore further code development on TOR is fruitless, therefore lets all stop coding. Breathing even. This IETF mantra of too many to change is wrong. We need to stop invoking the dead weight of the past over future events. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
This is a useless discussion. Recriminations do not change the past. True, but effectively what you're saying is that this special-use registry could be used by anyone who's prepared to [squat|use a TLD without registering it] in the right ways to get around the ICANN allocation procedures. I think that's spelled moral hazard in economics. Not really, because what you get by squatting on a TLD is nothing like what you get if you rent it from ICANN. Squats are all local (mis-)use, with names only leaking onto the public Internet by accident. It also seems implicit in this document that the plan is only to add names to the registry if there is existing evidence that they're significantly squatted, by which time it's too late anyway. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Tue, Feb 04, 2014 at 12:01:10AM -, John Levine wrote: Not really, because what you get by squatting on a TLD is nothing like what you get if you rent it from ICANN. Squats are all local (mis-)use, with names only leaking onto the public Internet by accident. That actually depends on what you're doing with the name. In the case of the names discussed in the chapin draft, that is true. It's less true in all cases. Best, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Feb 3, 2014, at 6:27 PM, George Michaelson g...@algebras.org wrote: .onion is an eminently tractable problem. Arguing otherwise is to argue the current .onion codebase dependency cannot move, therefore any future CVE against TOR cannot be fixed, therefore further code development on TOR is fruitless, therefore lets all stop coding. Breathing even.\ What I'm saying is that it's an obnoxious thing to do, and there's no good reason to do it. We really ought to have a good reason to demand that an organization over which we exert no control at all make a significant and incompatible change to their deployed code purely on the basis that some of us don't like what they did. We need a better reason than that, and thus far none has been stated. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
ok. I see where you are. I can be there, somewhat. Thats not a bad position Ted. So my sense of this is you were advised not to do this, and you didn't respect the process for some value of you What I don't like about that is a schoolmarm/punitive voice. But it has the qualities. Tragedies of the commons don't just take one form, and having s/w develop a dependency on name/locator properties with high visibility, without considering the commons, is (in my opinion) a tragedy. I'm not inherently arguing for ICANN process, or even the DNS. I think a mature sense of the locator/id separation qualities of any endeavour, and the arguments around naming, lead you to caution in seizing names in any space. IETF is constantly advised by w3c people (mark nottingham?) to be mindful of the URI/URL concept, and not to over-egg stipulations on what is meaningful in that space. And I think by and large, thats right. So is what the TOR people did usurping .onion respectful of process? What do you do, when process isn't respected? -G On Tue, Feb 4, 2014 at 11:08 AM, Ted Lemon ted.le...@nominum.com wrote: On Feb 3, 2014, at 6:27 PM, George Michaelson g...@algebras.org wrote: .onion is an eminently tractable problem. Arguing otherwise is to argue the current .onion codebase dependency cannot move, therefore any future CVE against TOR cannot be fixed, therefore further code development on TOR is fruitless, therefore lets all stop coding. Breathing even.\ What I'm saying is that it's an obnoxious thing to do, and there's no good reason to do it. We really ought to have a good reason to demand that an organization over which we exert no control at all make a significant and incompatible change to their deployed code purely on the basis that some of us don't like what they did. We need a better reason than that, and thus far none has been stated. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Mon, Feb 03, 2014 at 08:08:59PM -0500, Ted Lemon wrote: purely on the basis that some of us don't like what they did. We need a better reason than that, and thus far none has been stated. In the particular case of .onion, I'm not sure I agree none has been stated. But let me try again: If you want to use a name in DNS protocol slots, then you need a DNS name. You didn't get a DNS name, and instead you used a label that wasn't under your control. That's been against the rules in the DNS since forever. Now you want to short-circuit the allocation mechanism. But we have an allocation mechanism for this. In the normal case, you apply to ICANN. In an unusual case where the protocol depends on this, then you can use this special-use registry. So you need to show that your protocol needs to depend on this special-use label, and then we can register it under the special use mechanism. Otherwise go to ICANN. What we ought to be arguing about, in effect, is precisely why this needs a special-names registration. Now, _maybe_ there is an argument that this is a DNS-looking series of labels but it never goes into the DNS namespace (that's what I've heard once). In that case, there might be an argument. (Put this in the default local zones, always NXDOMAIN, because we want to protect the DNS.) Maybe the argument is instead that sometimes these names are handed to DNS resolvers and are supposed to resolve. In _that_ case, it seems to me that the this is a DNS name consideration is also pretty high. I'm unsure we've had clear and consistent arguments about this for each of the cases. In the chapin draft, the argument is different, and it appears to be purely a local-resolution-only one -- that is, always protection of the DNS because of de facto resolution and security decisions deployed on the Net. I haven't read it closely enough to decide whether this is true for every label in the list. Best, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Feb 3, 2014, at 8:18 PM, George Michaelson g...@algebras.org wrote: So is what the TOR people did usurping .onion respectful of process? What do you do, when process isn't respected? Until recently there wasn't a process, and they seem to have tried to follow the process that now exists, in a pretty reasonable timeframe. You can definitely ask them for more documentation. If your ask is reasonable, and seems beneficial, there's a decent chance they'll do it. But if your ask is unreasonable, you'll get ignored, and rightly so. I think asking them to change .onion without a solid reason (not you didn't follow process) is in the latter category. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Feb 3, 2014, at 8:21 PM, Andrew Sullivan a...@anvilwalrusden.com wrote: If you want to use a name in DNS protocol slots, then you need a DNS name. You didn't get a DNS name, and instead you used a label that wasn't under your control. This is the you didn't follow process argument. But they couldn't have followed process—there was no realistic process for allocating a special-use TLD before 6761 was published. So this amounts to an emotional appeal, which isn't much of a justification for the change you are demanding of them. I absolutely get why you are saying this. It's a pretty good emotional appeal. But we shouldn't act on it, because that's all it is. We have a process, and they are following it. We should see it through. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
Hi Andrew, On 2/4/14 3:21 AM, Andrew Sullivan a...@anvilwalrusden.com wrote: On Mon, Feb 03, 2014 at 08:08:59PM -0500, Ted Lemon wrote: purely on the basis that some of us don't like what they did. We need a better reason than that, and thus far none has been stated. In the particular case of .onion, I'm not sure I agree none has been stated. But let me try again: If you want to use a name in DNS protocol slots, then you need a DNS name. You didn't get a DNS name, and instead you used a label that wasn't under your control. That's been against the rules in the DNS since forever. Now you want to short-circuit the allocation mechanism. But we have an allocation mechanism for this. In the normal case, you apply to ICANN. In an unusual case where the protocol depends on this, then you can use this special-use registry. So you need to show that your protocol needs to depend on this special-use label, and then we can register it under the special use mechanism. Otherwise go to ICANN. In addition, I would say that perhaps the current rules are targeted towards DNS (or extensions of DNS as mDNS could be considered). These new protocols are something else. They are not DNS and not even specified in the IETF. They have taken a design choice where they look like DNS and therefore, may clash with the DNS namespace. The aspect of reserve these or you'll break the Internet (in some definition of break) isn't really valid. It is more that you interfere with the functionality of these protocols, which is a different magnitude of a problem. Perhaps, it is a different problem all together. What we ought to be arguing about, in effect, is precisely why this needs a special-names registration. Now, _maybe_ there is an argument that this is a DNS-looking series of labels but it never goes into the DNS namespace (that's what I've heard once). In that case, there might be an argument. (Put this in the default local zones, always NXDOMAIN, because we want to protect the DNS.) Maybe the argument is instead that sometimes these names are handed to DNS resolvers and are supposed to resolve. In _that_ case, it seems to me that the this is a DNS name consideration is also pretty high. I'm unsure we've had clear and consistent arguments about this for each of the cases. Right. From there comes the question that if this is a way to work around the process we have in the Internet now - you want a TLD you go to ICANN. Regardless of what people think of that process, this is the process we have created already a long time ago and it has been operational since the beginning of ICANN. There is no other process to get TLDs. In the chapin draft, the argument is different, and it appears to be purely a local-resolution-only one -- that is, always protection of the DNS because of de facto resolution and security decisions deployed on the Net. I haven't read it closely enough to decide whether this is true for every label in the list. Completely agree. The Chapin draft is trying to protect the Internet by reserving names that for various reasons have collisions in the Internet. It would be nice to remove these collisions, but it seems to be currently impossible. So, this is a way to deal with a real problem in the Internet we have today and avoid that these names would be delegated and cause breakage in the Internet. I also believe these two cases should be considered very separately. Cheers, Jonne. Best, A -- Andrew Sullivan a...@anvilwalrusden.com ___ 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] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
Not really, because what you get by squatting on a TLD is nothing like what you get if you rent it from ICANN. Squats are all local (mis-)use, with names only leaking onto the public Internet by accident. That actually depends on what you're doing with the name. In the case of the names discussed in the chapin draft, that is true. It's less true in all cases. I think that all we're talking about here is reserving domain names and saying that they should never resolve on the global Internet. If the IETF finds good technical reasons to reserve some other name for some other reason, e.g., peer to peer exchange of crypto credentials or something, so what? It's one less name for ICANN to sell but I don't see why that would be our problem. I suppose the situation with .onion is slightly different, but in concept it's not all that different from .arpa. It's a domain that people are using for special technical purposes, so it's not available for normal delegation. The only ICANN delegated name that's the least bit interesting is .TEL, an attempt to create an online directory using NAPTR that is a failure, so they're unlikely to do any more. R's, John PS: Because I am not a good person, you can reply to me at j...@m.183.57.64.in-addr.arpa. Or, of course, jo...@taughannock.tel. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On 2014-02-04 02:21, Andrew Sullivan wrote: On Mon, Feb 03, 2014 at 08:08:59PM -0500, Ted Lemon wrote: purely on the basis that some of us don't like what they did. We need a better reason than that, and thus far none has been stated. In the particular case of .onion, I'm not sure I agree none has been stated. But let me try again: If you want to use a name in DNS protocol slots, then you need a DNS name. You didn't get a DNS name, and instead you used a label that wasn't under your control. I would like to express the situation slightly different, or rather, this what you describe is one situation. Another situation which I think is more complicated is when a name is needed that looks like a domain name, but is never to be used in DNS. The only thing you need is a string that is not used as a domain name. So we have (at least): 1. Strings that are used in DNS, allocated as they where intended to be allocated 2. Strings that are to be used in DNS, with special roots 3. Strings that are to be used in DNS, but only in local environments (search path, .local etc) 4. Strings that looks like domain names but are never to be used in DNS, but still needs to be globally unique 5. Strings that looks like domain names but are never to be used in DNS, that does not need to be globally unique We know about 1. We say no to 2. We know about 3. What is new is 4 and 5. Patrik signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Jan 28, 2014, at 9:54 PM, John Levine jo...@taugh.com wrote: I believe that with the considerable sleuthing abilities of the IETF community, we ought to be able to take this initial set of observed data and treat it as a call to action for the IETF community, for someone to step forward and tell us *why* those names are in use, are leaking out to the root name servers, and what the intended use is for these names. Um, we already know. They're used to name things on private networks, often behind a NAT, and they leak out for random not particularly interesting reasons, such as people taking their laptops on trips which then look for the printer that lives on their office LAN when they're connected to the wifi at a coffee shop. All that, plus on their corporate network, there are search lists that allow shortened names; when they take their laptop off that network, they try to type in the shortened name. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Jan 29, 2014, at 7:47 AM, Ralf Weber d...@fl1ger.de wrote: Where shall this stop? From my earlier message: There is a huge, easily-identifiable difference between adding a token *before* the application process that started in 2012 and then later asking for a hold-back, and adding it *after*. All names in draft-chapin-additional-reserved-tlds were in widespread use before the application process. If someone wants to start using a new TLD now, they know where to go ask for it. I also don't think there are risks in delegation these other than the applicants will get lots of traffic. Others disagree. ICANN has documented many scenarios where there are security problems when what was earlier expected to either get local resolution or an NXDOMAIN starts getting real answers. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On 2014-01-29, at 11:40, Ralf Weber d...@fl1ger.de wrote: On 29 Jan 2014, at 08:10, Paul Hoffman paul.hoff...@vpnc.org wrote: I also don't think there are risks in delegation these other than the applicants will get lots of traffic. Others disagree. ICANN has documented many scenarios where there are security problems when what was earlier expected to either get local resolution or an NXDOMAIN starts getting real answers. By risks I meant risks to the Internet as a whole. A risk to the Internet as a whole is that a fragmented namespace (.LAN means something different in John's office than it does at the cafe next door; .HOME meaning something different to the thirty million subscribers of ISP X than it does to others) will restrict communication by name between endpoints on the Internet, and changes the fundamental assumptions on which protocols and applications rely to an extent that is potentially unbounded. This is the end-to-end principle wearing a DNS t-shirt (the IP t-shirt was all cut up by a hundred million NATs, and is no good when it's cold out). The trouble here is not recognising that namespace collisions are bad; it's (a) deciding where to draw the line between bad and good enough and (b) dealing with the political headaches of use it, measure it, reserve it at the IETF which costs $0 and follow the ICANN new gTLD applicant guidebook which costs substantially more. Joe signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
Moin! On 29 Jan 2014, at 10:07, Joe Abley jab...@hopcount.ca wrote: A risk to the Internet as a whole is that a fragmented namespace (.LAN means something different in John's office than it does at the cafe next door; .HOME meaning something different to the thirty million subscribers of ISP X than it does to others) will restrict communication by name between endpoints on the Internet, and changes the fundamental assumptions on which protocols and applications rely to an extent that is potentially unbounded. 1. The fragmented name space is a reality and has been for some time (dns split horizon search on google reveals 500k pages) 2. If endpoints use proper globally registered DNS names they will be able to communicate. If they use something else the behaviour is undefined. I think there is more value in thinking about how we can integrate local and global naming than in trying to protect people by not allowing something to not be registered in the global name space. This is the end-to-end principle wearing a DNS t-shirt (the IP t-shirt was all cut up by a hundred million NATs, and is no good when it's cold out). I don't think the DNS t-shirt looks better. The trouble here is not recognising that namespace collisions are bad; it's (a) deciding where to draw the line between bad and good enough and (b) dealing with the political headaches of use it, measure it, reserve it at the IETF which costs $0 and follow the ICANN new gTLD applicant guidebook which costs substantially more. I do recognise them. The data that we have shows that they exists. I just think that it is nothing the IETF should invest time in. While the IETF cost is significant lower than the ICANN cost I doubt that RFCs will get lawyers out of ICANNs back. I think the ship has sailed and it now is a political (layer 9) problem who can register what in the global DNS name space. So long -Ralf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
In message ee6063ee-a69e-4460-91b4-862096a00...@fl1ger.de, Ralf Weber writes: Moin! On 29 Jan 2014, at 10:07, Joe Abley jab...@hopcount.ca wrote: A risk to the Internet as a whole is that a fragmented namespace (.LAN mean s something different in John's office than it does at the cafe next door; .H OME meaning something different to the thirty million subscribers of ISP X th an it does to others) will restrict communication by name between endpoints o n the Internet, and changes the fundamental assumptions on which protocols an d applications rely to an extent that is potentially unbounded. 1. The fragmented name space is a reality and has been for some time (dns spl it horizon search on google reveals 500k pages) And there is a difference between fragmenting namespace that you control and fragmenting namespace that others control. I have split horizon namespace (dv.isc.org) but I control the contents of all versions of that namespace. Any leaks get answered by nameservers configured for that zone. It doesn't have to cost you anything (other than time to setup the registration) to get a namespace that you have control over. There are infrastructure zones which still do free registrations on best effort basis. This is about fragmented namespaces where the control is not under a single party. This is about pollution of / squatting on the common namespace .. The squatted tld's used by software .onion, .bit etc could be migrated to a new namespaces. Just issue new software that looks / recognises in the new namespace first then in the old one for X years. After X years stop looking in / recognising the old namespace. Set X to about 10 years and there will be very little old code left when you turn off support for the namespace. Set and compile in the drop dead date. 2. If endpoints use proper globally registered DNS names they will be able to communicate. If they use something else the behaviour is undefined. I think there is more value in thinking about how we can integrate local and global naming than in trying to protect people by not allowing something to n ot be registered in the global name space. This is the end-to-end principle wearing a DNS t-shirt (the IP t-shirt was all cut up by a hundred million NATs, and is no good when it's cold out). I don't think the DNS t-shirt looks better. The trouble here is not recognising that namespace collisions are bad; it's (a) deciding where to draw the line between bad and good enough and (b) dealing with the political headaches of use it, measure it, reserve it at th e IETF which costs $0 and follow the ICANN new gTLD applicant guidebook wh ich costs substantially more. I do recognise them. The data that we have shows that they exists. I just thi nk that it is nothing the IETF should invest time in. While the IETF cost is significant lower than the ICANN cost I doubt that RFCs will get lawyers out of ICANNs back. I think the ship has sailed and it now is a political (layer 9) problem who can register what in the global DNS name space. So long -Ralf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On 28 Jan 2014, at 05:26, John Levine jo...@taugh.com wrote: What, if anything, is the plan for dealing the predictable complaints from applicants who (not totally unreasonably) would feel that the rug's been yanked out from under them? Why would they complain or have the rug yanked from under them? [Note too that the draft uses SHOULD and not MUST.] Whatever happens with this draft is unlikely to have any impact on ICANN's current list of new gTLDs. The draft might however become another input into the risk mitigation framework that ICANN is now developing. ie There might be additional measures in place before .home (say) can proceed to delegation. That should not surprise anyone here. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Jan 27, 2014, at 8:40 PM, Stuart Cheshire chesh...@apple.com wrote: 1. The draft states that eight TLDs are to be designated “Special Use”, but doesn’t actually say for any of them *what* the special use is. It does, but it doesn't call it out very well. It the middle of section 3, it says that the list is names that may not be used for top-level domains. That is a special use: a label that can be legally used everywhere other than at the top level. 2. The actual rules specified in the draft are incorrect. For example, for “.home”: Authors of name resolution APIs and libraries SHOULD restrict these names to local resolution and SHOULD NOT allow queries for strings that use these Special-Use Domain Names to be forwarded to the public DNS for resolution. Names like “voyager.home” have been used to refer to a user’s home NAT gateway. The user can type “voyager.home” into their web browser and connect to their home NAT gateway’s administration page. If (as the draft advocates) the client machine’s name resolution library failed to send the “voyager.home” query to its configured DNS server, then this usage would fail. This document should have the effect you say: allow the query to be sent from a host to its configured DNS server. The current wording is wrong. If we want to formalise the current usage of “.home” rather than break it, then I suggest that something more similar to the rules for test names would be more appropriate: 6.2. Domain Name Reservation Considerations for test. The domain test., and any names falling within .test., are special in the following ways: 1. Users are free to use these test names as they would any other domain names. However, since there is no central authority responsible for use of test names, users SHOULD be aware that these names are likely to yield different results on different networks. 2. Application software SHOULD NOT recognize test names as special, and SHOULD use test names as they would other domain names. 3. Name resolution APIs and libraries SHOULD NOT recognize test names as special and SHOULD NOT treat them differently. Name resolution APIs SHOULD send queries for test names to their configured caching DNS server(s). 4. Caching DNS servers SHOULD recognize test names as special and SHOULD NOT, by default, attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve test names. Instead, caching DNS servers SHOULD, by default, generate immediate negative responses for all such queries. This is to avoid unnecessary load on the root name servers and other name servers. Caching DNS servers SHOULD offer a configuration option (disabled by default) to enable upstream resolving of test names, for use in networks where test names are known to be handled by an authoritative DNS server in said private network. 5. Authoritative DNS servers SHOULD recognize test names as special and SHOULD, by default, generate immediate negative responses for all such queries, unless explicitly configured by the administrator to give positive answers for test names. 6. DNS server operators SHOULD, if they are using test names, configure their authoritative DNS servers to act as authoritative for test names. 7. DNS Registries/Registrars MUST NOT grant requests to register test names in the normal way to any person or entity. Test names are reserved for use in private networks and fall outside the set of names available for allocation by registries/registrars. Attempting to allocate a test name as if it were a normal DNS domain name will probably not work as desired, for reasons 4, 5, and 6 above. That seems like a better way to go for all (?) the names in this document. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Jan 27, 2014, at 9:26 PM, John Levine jo...@taugh.com wrote: What, if anything, is the plan for dealing the predictable complaints from applicants who (not totally unreasonably) would feel that the rug's been yanked out from under them? That plan would be for ICANN to design, not us. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Jan 27, 2014, at 9:15 PM, George Michaelson g...@algebras.org wrote: I like the aspect that this draft has drawn on observations of what leaks into the global space, to suggest what might be wise to withhold. thats at least testable, repeatable. As to the decisive qualities? I think the IETF could step over a line very quickly into a place it really doesn't want to be. Inform ICANN? sure. but decide to formally try and exclude a namespace on technical grounds? Thats big. That has implications. You'd want to be on remarkably solid ground. Yes, and this list seems like the most solid ground possible for either the IETF or ICANN. And then theres the future. These are anglo-centric measurements from the current state. At some future point, one can imagine a language group embeds a token in name-lookup logic in some domain of activity, and it winds up hitting the DNS and they come asking for a holdback. There is a huge, easily-identifiable difference between adding a token *before* the application process that started in 2012 and then later asking for a hold-back, and adding it *after*. The jurisdictional qualities around what should or shouldnt be in the DNS just makes me quake in my boots. Sure. But re-read section 3 of this draft. This is not Lyman's and Mark's list, it is a list generated by an ICANN standing committee, then validated by empirical evidence. BTW, India, Pakistan, South Africa, the Carribean, New Zealand, Australia, Sri Lanka all understand the word test to have a meaning in sports, which has very high financial value. The assumption the label .TEST has no financial value in rugby or cricket, when worldwide TV rights negotiate for billions of dollars seems to me to be .. well.. fraught. The document did not make that assumption. It doesn't talk about finance anywhere. For example, there is even financial advantage to owning almost any common label and seeing what is returned, even if you cannot control what is returned. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
What, if anything, is the plan for dealing the predictable complaints from applicants who (not totally unreasonably) would feel that the rug's been yanked out from under them? Why would they complain or have the rug yanked from under them? [Note too that the draft uses SHOULD and not MUST.] Whatever happens with this draft is unlikely to have any impact on ICANN's current list of new gTLDs. Someone paid $185,000 to apply for .EXCHANGE, which is #567 on the priority list. They haven't signed any contracts yet. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Jan 27, 2014, at 11:40 PM, Stuart Cheshire wrote: On 8 Jan, 2014, at 10:18, Suzanne Woolf suzworldw...@gmail.com wrote: Colleagues, This new internet-draft is another request for additions to the RFC 6761 special names registry, this time motivated by an interest in reserving the names most commonly found in recent analysis of TLDs in private name spaces. The special names registration would serve to minimize the chances of collision between private and public DNS namespaces by keeping these names unassigned in the public namespace. In addition to discussion on the merits of this specific request, I would expect the IESG to be interested in any new aspects this request brings up to the discussion we were already having on the p2p special names draft, and the usability and scalability of the process in RFC 6761. I think the goal of the draft is worthy, but there are some details to work out: 1. The draft states that eight TLDs are to be designated “Special Use”, but doesn’t actually say for any of them *what* the special use is. Hi Stuart - The draft was intended to capture existing observed high-volume uses of non-delegated TLD names empirically, rather than trying to determine the circumstances under which local use of a particular TLD name occurs (which might be highly various, depending on the name). Essentially, all of these names are proposed for designation as special use because they are already in widespread special use - that is, they are widely used as TLDs in name spaces that do not resolve (or do not resolve as they were intended to resolve) through the global DNS. I understand that this is different from the original intention of RFC 6761, which assumes that a name should be reserved for special use only when the special use is well understood and well documented. In this case, the names have been observed (see the references in the i-d) in special use contexts, but the nature of the special use in each case is not necessarily evident from the data. The rationale for reserving these names for special use is the potential for name collision if they are also delegated as resolvable entries in the global IANA root, which could disrupt the operation and/or compromise the security of networks that are part of the global Internet but maintain locally-resolved name spaces. From the IETF standpoint, this is an OM issue. ICANN's interest in selling these names to new gTLD applicants is orthogonal to the interest of the IETF in ensuring the stability and robustness of the Internet (including the DNS) for its users - - Lyman For example, I know what “localhost” means; I know what it does and how to use it (it’s a synonym for 127.0.0.1 and ::1). What is “localdomain” and for what would I use it? The intent of RFC 6761 is that the seven Domain Name Reservation Considerations are a required *part* of any specification that is documenting something that requires some special name use, analogous to how all RFC’s have a “Security Considerations” section. But you wouldn’t write an RFC that was only a “Security Considerations” section, and a specification that is *only* a “Domain Name Reservation Considerations” section is equally lacking. The “Domain Name Reservation Considerations” section is a *supplement* to the actual descriptive content of the specification, not a *substitute* for it. I apologise that RFC 6761 did not set a good precedent in this regard. The examples in RFC 6761, like “test” , “invalid” and “example”, were all fairly self-evident and previously documented elsewhere. In retrospect, RFC 6761 should have spelled out more clearly what they are all used for, to set a better example to future documents. 2. The actual rules specified in the draft are incorrect. For example, for “.home”: Authors of name resolution APIs and libraries SHOULD restrict these names to local resolution and SHOULD NOT allow queries for strings that use these Special-Use Domain Names to be forwarded to the public DNS for resolution. Names like “voyager.home” have been used to refer to a user’s home NAT gateway. The user can type “voyager.home” into their web browser and connect to their home NAT gateway’s administration page. If (as the draft advocates) the client machine’s name resolution library failed to send the “voyager.home” query to its configured DNS server, then this usage would fail. If we want to formalise the current usage of “.home” rather than break it, then I suggest that something more similar to the rules for test names would be more appropriate: 6.2. Domain Name Reservation Considerations for test. The domain test., and any names falling within .test., are special in the following ways: 1. Users are free to use these test names as they would any other domain names. However, since there is no central authority responsible for use of test
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On 28 Jan, 2014, at 07:52, Paul Hoffman paul.hoff...@vpnc.org wrote: It does, but it doesn't call it out very well. It the middle of section 3, it says that the list is “names that may not be used for top-level domains. That doesn’t describe what the labels are used for. It describes what they may *not* be used for. What they *are* used for remains unspecified. If the user types “www.host” into their web browser, the name should *not* be resolved in the global DNS. I get that. But what *should* happen with that name? Should it result in NXDOMAIN, like “www.invalid”? Should it result in 127.0.0.1 like “localhost” does? Resolved via mDNS, like “www.local”? Something else? I have no idea. If it’s the same as one of the other existing special-use TLDs, then an argument needs to be made as to why we need another reserved special-use TLD that duplicates the functionality of an existing one. These names are not supposed to be vanity names. The special-use names are there to trigger special behavior by software, and as such we probably don’t need more than one way to trigger each particular special behavior. The current use of various de facto reserved names like “.onion” results from there being no formal IETF mechanism for documenting and discussing such uses. The goal of RFC 6761 was to remedy this omission, and give people who feel they need such names a process to apply for such names and initiate discussion about whether such use is appropriate. That way the IETF community can be involved with these decisions about how names are used, instead of it happening outside the IETF with no IETF scrutiny or input. I think it would be fairly easy to produce a draft documenting what “.onion” is for, how it works, and why resolving those names via the conventional DNS is not appropriate. I’d love to see a draft like that from one of the people who understands the details. For some of the other names I don’t know what those documents would say. If people in the IETF community do know what those names are used for, having those people write and submit a quick two-page draft describing the usage would be a wonderful contribution to greater IETF understanding of what’s going on. Observing that certain weird names are hitting the root name servers is a useful first step. Understanding *why* that’s happening would be even better. Stuart Cheshire ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On 28 Jan, 2014, at 13:56, Lyman Chapin ly...@interisle.net wrote: Hi Stuart - The draft was intended to capture existing observed high-volume uses of non-delegated TLD names empirically, rather than trying to determine the circumstances under which local use of a particular TLD name occurs (which might be highly various, depending on the name). That’s a laudable contribution, thank you. I believe that with the considerable sleuthing abilities of the IETF community, we ought to be able to take this initial set of observed data and treat it as a call to action for the IETF community, for someone to step forward and tell us *why* those names are in use, are leaking out to the root name servers, and what the intended use is for these names. (I assume that “leaking out to the root name servers and getting NXDOMAIN” is *not* the intended use.) Stuart Cheshire ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
I believe that with the considerable sleuthing abilities of the IETF community, we ought to be able to take this initial set of observed data and treat it as a call to action for the IETF community, for someone to step forward and tell us *why* those names are in use, are leaking out to the root name servers, and what the intended use is for these names. Um, we already know. They're used to name things on private networks, often behind a NAT, and they leak out for random not particularly interesting reasons, such as people taking their laptops on trips which then look for the printer that lives on their office LAN when they're connected to the wifi at a coffee shop. On my home network I have a couple of dozen hosts, what with all the networked printers, phones, tablets, laptops, and so forth, and because I am a lazy guy, I give them names like kindle.lan rather than longer global names. My local DNS cache resolves those names to addresses in 192.168/16. I think that's pretty typical of small business networks. It's useful, but I don't see anything worth standardizing other than don't resolve .LAN on the global Internet. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On 8 Jan, 2014, at 10:18, Suzanne Woolf suzworldw...@gmail.com wrote: Colleagues, This new internet-draft is another request for additions to the RFC 6761 special names registry, this time motivated by an interest in reserving the names most commonly found in recent analysis of TLDs in private name spaces. The special names registration would serve to minimize the chances of collision between private and public DNS namespaces by keeping these names unassigned in the public namespace. In addition to discussion on the merits of this specific request, I would expect the IESG to be interested in any new aspects this request brings up to the discussion we were already having on the p2p special names draft, and the usability and scalability of the process in RFC 6761. I think the goal of the draft is worthy, but there are some details to work out: 1. The draft states that eight TLDs are to be designated “Special Use”, but doesn’t actually say for any of them *what* the special use is. For example, I know what “localhost” means; I know what it does and how to use it (it’s a synonym for 127.0.0.1 and ::1). What is “localdomain” and for what would I use it? The intent of RFC 6761 is that the seven Domain Name Reservation Considerations are a required *part* of any specification that is documenting something that requires some special name use, analogous to how all RFC’s have a “Security Considerations” section. But you wouldn’t write an RFC that was only a “Security Considerations” section, and a specification that is *only* a “Domain Name Reservation Considerations” section is equally lacking. The “Domain Name Reservation Considerations” section is a *supplement* to the actual descriptive content of the specification, not a *substitute* for it. I apologise that RFC 6761 did not set a good precedent in this regard. The examples in RFC 6761, like “test” , “invalid” and “example”, were all fairly self-evident and previously documented elsewhere. In retrospect, RFC 6761 should have spelled out more clearly what they are all used for, to set a better example to future documents. 2. The actual rules specified in the draft are incorrect. For example, for “.home”: Authors of name resolution APIs and libraries SHOULD restrict these names to local resolution and SHOULD NOT allow queries for strings that use these Special-Use Domain Names to be forwarded to the public DNS for resolution. Names like “voyager.home” have been used to refer to a user’s home NAT gateway. The user can type “voyager.home” into their web browser and connect to their home NAT gateway’s administration page. If (as the draft advocates) the client machine’s name resolution library failed to send the “voyager.home” query to its configured DNS server, then this usage would fail. If we want to formalise the current usage of “.home” rather than break it, then I suggest that something more similar to the rules for test names would be more appropriate: 6.2. Domain Name Reservation Considerations for test. The domain test., and any names falling within .test., are special in the following ways: 1. Users are free to use these test names as they would any other domain names. However, since there is no central authority responsible for use of test names, users SHOULD be aware that these names are likely to yield different results on different networks. 2. Application software SHOULD NOT recognize test names as special, and SHOULD use test names as they would other domain names. 3. Name resolution APIs and libraries SHOULD NOT recognize test names as special and SHOULD NOT treat them differently. Name resolution APIs SHOULD send queries for test names to their configured caching DNS server(s). 4. Caching DNS servers SHOULD recognize test names as special and SHOULD NOT, by default, attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve test names. Instead, caching DNS servers SHOULD, by default, generate immediate negative responses for all such queries. This is to avoid unnecessary load on the root name servers and other name servers. Caching DNS servers SHOULD offer a configuration option (disabled by default) to enable upstream resolving of test names, for use in networks where test names are known to be handled by an authoritative DNS server in said private network. 5. Authoritative DNS servers SHOULD recognize test names as special and SHOULD, by default, generate immediate negative responses for all such queries, unless explicitly configured by the administrator to give positive answers for test names. 6. DNS server operators SHOULD, if they are using test names, configure their authoritative DNS servers to act as authoritative for test
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
I used to get very unhappy when big name IETF attendees would wander into a room and say this makes me very uncomfortable at the mike. So having said that, and noting I'm nobody special, and certainly not a big name in IETF, or DNS... something about this makes me very uncomfortable we are a long way down a path of governance issues in names which makes reserving a namespace highly politically charged. Look at what .XXX underwent. Look at the issues around name collisions and potential interests in names. I like the aspect that this draft has drawn on observations of what leaks into the global space, to suggest what might be wise to withhold. thats at least testable, repeatable. As to the decisive qualities? I think the IETF could step over a line very quickly into a place it really doesn't want to be. Inform ICANN? sure. but decide to formally try and exclude a namespace on technical grounds? Thats big. That has implications. You'd want to be on remarkably solid ground. And then theres the future. These are anglo-centric measurements from the current state. At some future point, one can imagine a language group embeds a token in name-lookup logic in some domain of activity, and it winds up hitting the DNS and they come asking for a holdback. Are we tooled up for that? the I8n side of things. The jurisdictional qualities around what should or shouldnt be in the DNS just makes me quake in my boots. I guess I am going to have to wear come-backs around the don't over politicize technology discussions and stop trying to have a chilling effect on a technology discussion but I have this memory of some very very cross words being said about .LOCAL a long time ago. and the potential for value in the real world, and the potential for pain, attempting to reserve or conserve a label for undoubtedly good technical reasons, in that context. BTW, India, Pakistan, South Africa, the Carribean, New Zealand, Australia, Sri Lanka all understand the word test to have a meaning in sports, which has very high financial value. The assumption the label .TEST has no financial value in rugby or cricket, when worldwide TV rights negotiate for billions of dollars seems to me to be .. well.. fraught. and I can imagine several voices who could capitalize on .LOCAL, your local supermarket chain amongst them. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
This new internet-draft is another request for additions to the RFC 6761 special names registry, this time motivated by an interest in reserving the names most commonly found in recent analysis of TLDs in private name spaces. Several of these names including MAIL, HOME, CORP, and EXCHANGE have active applications in the ICANN new gTLD round. Some have such egregious collisions with existing practice that the applications seem to be dead, but others such as EXCHANGE aren't. What, if anything, is the plan for dealing the predictable complaints from applicants who (not totally unreasonably) would feel that the rug's been yanked out from under them? R's, John PS: I have some minor technical comments, similar to other people's, but nothing that's hard to fix if we want to move this ahead. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
Colleagues, This new internet-draft is another request for additions to the RFC 6761 special names registry, this time motivated by an interest in reserving the names most commonly found in recent analysis of TLDs in private name spaces. The special names registration would serve to minimize the chances of collision between private and public DNS namespaces by keeping these names unassigned in the public namespace. In addition to discussion on the merits of this specific request, I would expect the IESG to be interested in any new aspects this request brings up to the discussion we were already having on the p2p special names draft, and the usability and scalability of the process in RFC 6761. thanks, Suzanne Begin forwarded message: From: internet-dra...@ietf.org Subject: I-D Action: draft-chapin-additional-reserved-tlds-00.txt Date: January 8, 2014 10:11:28 AM EST To: i-d-annou...@ietf.org Reply-To: internet-dra...@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Additional Reserved Top Level Domains Authors : Lyman Chapin Mark McFadden Filename: draft-chapin-additional-reserved-tlds-00.txt Pages : 26 Date: 2014-01-08 Abstract: The Internet Domain Name System (DNS) defines a tree of names starting with root, ., immediately below which are top level domain (TLD) names such as .com and .us. In June 1999 RFC2606 reserved a small number of TLD names for use in documentation examples, private testing, experiments, and other circumstances in which it is desirable to avoid conflict with current or future actual TLD names in the DNS. There has been significant evolution of Internet engineering and operation practices since RFC2606 was published. In February 2013 RFC6761 defined criteria and procedures for reserving a domain name for special use, and established an IANA registry for such names. This document reserves eight domain name labels for special use in accordance with the criteria and procedures of RFC6761: localdomain, domain, lan, home, host, corp, mail, and exchange. It is important to note that TLD names may be reserved, in other contexts, for policy, political, or other reasons that are distinct from the IETF's concern with Internet engineering and operations. This document reserves TLD names only for operational and engineering reasons. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-chapin-additional-reserved-tlds/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-chapin-additional-reserved-tlds-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
