Re: [dns-operations] dotless domains
In message 505fe0c6.50...@dougbarton.us, Doug Barton writes: On 09/23/2012 21:07, Mark Andrews wrote: It does if http://myname; goes to a local machine one day and the next day it goes to a tld the next day because myname was added to the root zone and that zone has A, or SRV records which will be the case if resolvers/browsers are fixed to make simple names match against tld first, which you suggest is a logical consequence of allowing this idiocy to continue. I didn't say that was the only solution, maybe the better idea is test local resolution first, then add a fully-qualifying dot second. My point was not, Here is how to solve the problem, so stop attacking my poor, harmless straw man. :) My point was that we are not limited to the status quo. You then have administators having to check the list of TLDs whenever they add a new machine and rejecting any name that matches a tld to prevent simple - tld becoming simple - local. Simple - TLD + Simple - local cannot be made to work safely. The best solution would be to acknowledge that this is a security problem and fix gethostbyname, getaddrinfo etc. and browsers never treat a simple name as a tld. Simple names are locally resolved not globally resolved. ... and are you saying that if I have foo.example.com, AND I have users that do http://foo, AND someone creates dot-foo, AND my users then try to go to my local site and get the TLD instead; that they will be confused into entering their foo.example password into a form on dot-foo? Or do I misunderstand? They might. Not all interfaces are good at showing what you have connected to or even show anything at all. Think mail user@myname. Which user gets the email? The local user or the TLD user? Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
Logically, shouldn't a right-side dot fix all of this? If I browse to: http://myname./ I would expect to get a gTLD, as the right-side dot represents the root. If I were to browse to: http://myname/ I would expect to hit my local definitions, then search domain, then fail or hit the browser search. Is this a broken view or does it make sense? On Sun, Sep 23, 2012 at 11:51 PM, Mark Andrews ma...@isc.org wrote: In message 505fe0c6.50...@dougbarton.us, Doug Barton writes: On 09/23/2012 21:07, Mark Andrews wrote: It does if http://myname; goes to a local machine one day and the next day it goes to a tld the next day because myname was added to the root zone and that zone has A, or SRV records which will be the case if resolvers/browsers are fixed to make simple names match against tld first, which you suggest is a logical consequence of allowing this idiocy to continue. I didn't say that was the only solution, maybe the better idea is test local resolution first, then add a fully-qualifying dot second. My point was not, Here is how to solve the problem, so stop attacking my poor, harmless straw man. :) My point was that we are not limited to the status quo. You then have administators having to check the list of TLDs whenever they add a new machine and rejecting any name that matches a tld to prevent simple - tld becoming simple - local. Simple - TLD + Simple - local cannot be made to work safely. The best solution would be to acknowledge that this is a security problem and fix gethostbyname, getaddrinfo etc. and browsers never treat a simple name as a tld. Simple names are locally resolved not globally resolved. ... and are you saying that if I have foo.example.com, AND I have users that do http://foo, AND someone creates dot-foo, AND my users then try to go to my local site and get the TLD instead; that they will be confused into entering their foo.example password into a form on dot-foo? Or do I misunderstand? They might. Not all interfaces are good at showing what you have connected to or even show anything at all. Think mail user@myname. Which user gets the email? The local user or the TLD user? Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Kyle Creyts Information Assurance Professional BSidesDetroit Organizer ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
* Paul Vixie: those are country code top level domains. cctld's enjoy national sovereignty Uhm, most of them are companies, and not subjects of international law. Few of them, however, have entered binding contracts with ICANN. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
In message CA+TcGd-6gQ99yAijNCWOwSeAutU0WA=g6spf6ju60h7bvk5...@mail.gmail.com, Kyle Creyts writes: Logically, shouldn't a right-side dot fix all of this? No. If I browse to: http://myname./ I would expect to get a gTLD, as the right-side dot represents the root. If I were to browse to: http://myname/ I would expect to hit my local definitions, then search domain, then fail or hit the browser search. Is this a broken view or does it make sense? It is a broken view. On Sun, Sep 23, 2012 at 11:51 PM, Mark Andrews ma...@isc.org wrote: In message 505fe0c6.50...@dougbarton.us, Doug Barton writes: On 09/23/2012 21:07, Mark Andrews wrote: It does if http://myname; goes to a local machine one day and the next day it goes to a tld the next day because myname was added to the root zone and that zone has A, or SRV records which will be the case if resolvers/browsers are fixed to make simple names match against tld first, which you suggest is a logical consequence of allowing this idiocy to continue. I didn't say that was the only solution, maybe the better idea is test local resolution first, then add a fully-qualifying dot second. My point was not, Here is how to solve the problem, so stop attacking my poor, harmless straw man. :) My point was that we are not limited to the status quo. You then have administators having to check the list of TLDs whenever they add a new machine and rejecting any name that matches a tld to prevent simple - tld becoming simple - local. Simple - TLD + Simple - local cannot be made to work safely. The best solution would be to acknowledge that this is a security problem and fix gethostbyname, getaddrinfo etc. and browsers never treat a simple name as a tld. Simple names are locally resolved not globally resolved. ... and are you saying that if I have foo.example.com, AND I have users that do http://foo, AND someone creates dot-foo, AND my users then try to go to my local site and get the TLD instead; that they will be confused into entering their foo.example password into a form on dot-foo? Or do I misunderstand? They might. Not all interfaces are good at showing what you have connected to or even show anything at all. Think mail user@myname. Which user gets the email? The local user or the TLD user? Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Kyle Creyts Information Assurance Professional BSidesDetroit Organizer -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
Florian, On Sep 24, 2012, at 12:07 AM, Florian Weimer f...@deneb.enyo.de wrote: * Paul Vixie: those are country code top level domains. cctld's enjoy national sovereignty Uhm, most of them are companies, and not subjects of international law. Few of them, however, have entered binding contracts with ICANN. Because ccTLD administration is considered an issue of national sovereignty, ICANN has no license to insert itself between the government and the contractor the government chooses to operate the ccTLD. Regards, -drc ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
On 9/24/12 12:07 AM, Florian Weimer wrote: Uhm, most of them are companies, and not subjects of international law. Few of them, however, have entered binding contracts with ICANN. Is this something you think you have an adequate understanding of, or do you think you may have an inadequte understanding, hence a limited ability to reach issue relevant conclusions? Eric ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
On Fri, 21 Sep 2012, P Vixie wrote: To change the internet so that foo@Microsoft has universal not local meaning would require action by many millions of parties not just by Microsoft. Anyone who did not make the change would be at risk from the new behavior and new content by others while still being compatible with the specs they were born with. Yahoo! No, that doesn't work. Microsoft. Google. Golly gosh darn. That Does Work. FULL STOP: THE DOT MATTERS. (TM) I gladly cede the marketing rights to the dotless blaggers. They'll have to market a rightside dot, of course. -- Fred Morris ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
I don't understand this entire debate. I am sorry. Can somebody please frame it? My understanding is that if there is a rightside dot... that the domain is fully qualified. I know for a fact that, even with the foregoing, if somebody locally wants to rewrite a domain there is nothing that is going to stop them. I think this is a feature, not a bug. OK, sure, you could tunnel out to an objective nameserver if you were trapped in the Hotel California, at least in theory. But if somebody wants to have microsoft.my-bad-private-idaho--nobody-knows-about.info: does anybody outside of Microsoft (r) care? Who cares if they care? So what, exactly, *is* the security implication? I suppose the implication is somebody registering webmaster. or info. or sales. or www. or something else called out in any of a number of RFCs; ands I would *hope* that that has been dealt with in the current TLD application process. So as a thinking exercise let's think about something like sales. Somebody types http://sales/; into their browser. Now if their resolv.conf has warfarin.com in it, we can at least hope that they will be directed to sales.warfarin.com. But if they don't.. and there aren't some commonsense rules, where do they go? What TLD do they get sent to? Is this decided by who the highest bidder is, or the day of the week, or cycle of the moon, or what? Commonsense would be that if it doesn't resolve they go nowhere. More likely, practically speaking, it will be decided by whatever search engine has a deal with the makers of their web browser. Where mail goes may be entirely somewhere... entirely different. So this is not a DNS question at all. I dunno, I guess I don't go to enough meetings. -- Fred Morris ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
On 23 Sep 2012, at 09:38, Fred Morris wrote: I don't understand this entire debate. I am sorry. Can somebody please frame it? Read the SSAC report: http://www.icann.org/en/groups/ssac/documents/sac-053-en.pdf . So what, exactly, *is* the security implication? There are many. You even mention some of them yourself. The short answer is the behaviour of much application software (and stub resolvers) is unpredictable and/or broken whenever they are presented with a domain name which does not contain a dot. Amongst other things, this can mean DNS lookups for QNAMEs which are not the same as that original single label = getting directed to the wrong location or being told that something doesn't exist when it actually does or vice versa. Read that SSAC report. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
On 09/21/2012 15:46, Rick Jones wrote: 2. We are not limited by the status quo. While the _current_ state of things is that we cannot guarantee that single labels will work reliably in all cases, those who are putting very large sums of money into the process of acquiring and operating these domains (especially the .brand domains) will not hesitate to expend effort (and $$) to bring other developers up to speed. For example, in the browser it is a very simple matter to first append a dot to a single label and see if it resolves before trying the search domains. But is that really, consistently the right thing to do? I suppose that browsers are already more than a little bit pregnant with their willingness to append TLDs to single labels, but suppose someone happens to have a subnet with a bunch of machines named for fruit - apple, pear, grape, etc. Are they going to have to go-in and configure their (possibly auto-updated) browsers to not append that dot so the resolv.conf search directive with their subdomain will still let them get to their apple.subdomain rather than go to apple.? Properly configure the search string in your DHCP response. Properly configure your browsers to either do or not do local test resolutions first you are making my point for me that there are numerous ways to make this work, and the browser authors are already not providing a consistent experience. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
On Fri, Sep 21, 2012 at 11:23:02AM -0700, David Conrad d...@virtualized.org wrote a message of 38 lines which said: I'm not sure how ICANN is supposed to do that without 'regulations'. I don't think I said that ICANN should regulate nothing. It is a regulator (even if it denies it, claiming it only has a narrow technical role) so it regulates. But not all regulations are good. And this one is clearly useless. it is appropriate to be conservative in the degrees of freedom in which we can shoot ourselves in the foot. I disagree here. The creators of the DNS (thanks to them, by the way, and congratulations) were quite careful in isolating the problems. Unlike X.509 (where the weakness of one CA breaks the entire system), DNS' tree structure ensure that a problem in .nl won't affect .net and a problem in .info won't be an issue for .jp. There is no need to be conservative here: both theory (DNS decentralized tree structure) and practice (the 15 existing TLD with A or MX at the apex) proves there is nothing to fear for the other TLDs. Given there is one root and that pretty much everybody is dependent upon it, you probably want to minimize the surprises that are associated with the root. The discussion is about TLD, not about whether a A or MX at the root makes sense. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
Stephane Bortzmeyer writes: But not all regulations are good. And this one is clearly useless. Clearly useless is clearly overstated. While it is certainly debatable what the best course of action is to fit with both personal and organizational policy goals, it has been well demonstrated that there are practical problems with service records at toplevel domains. This regulation clearly has a use in trying to address that. Please stick to arguing the merits of it rather than dismissively hand-waving away valid concerns. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
money changes everything. there is more money in brands-composed-of-letters than in novel marks made from exclusively from digits. money changes everything is sufficient to explain rule making restricting digit labels and promoting letter labels where each exhibits context depenedent resolution. -e ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
On Fri, Sep 21, 2012 at 07:38:44PM -0700, P Vixie p...@redbarn.org wrote a message of 77 lines which said: To change the internet so that foo@Microsoft has universal not local meaning would require action by many millions of parties not just by Microsoft. Yes. It is also true for IPv6, DNSSEC and BCP38. In these cases as well, you need millions of parties to act and this is partly why none of these three techniques is fully deployed yet. Nevertheless, you were and are a vocal supporter of IPv6, DNSSEC and BCP38. Probably because you believe that things *can* change. So, it can work for one-label domains as well. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
On 9/22/2012 8:48 PM, Stephane Bortzmeyer wrote: On Fri, Sep 21, 2012 at 07:38:44PM -0700, P Vixie p...@redbarn.org wrote a message of 77 lines which said: To change the internet so that foo@Microsoft has universal not local meaning would require action by many millions of parties not just by Microsoft. Yes. It is also true for IPv6, DNSSEC and BCP38. No. Thank you for saying so, because the way in which they differ is exemplary. Half the Internet can adopt IPv6 and the other half who still uses only IPv4 will not be hurt by this. Not so if half the internet decides that @Microsoft is local. The other half can be badly hurt. The exemplary difference is between a correctness preserving transformation or backward compatible upgrade in one case, as against a correctness destroying transformation or forklift upgrade in the other. Paul -- I suspect I'm not known as a font of optimism. (VJS, 2012) ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
Paul Vixie (paul) writes: those are country code top level domains. cctld's enjoy national sovereignty -- it is not up to ietf or icann or anybody else to tell them what they can't do. thus they are unaffected by icann policy, and their choices cannot guide our discussions of icann policy. But surely they can be used to illustrate the issues that this will cause with applications... ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
Randy Bush (randy) writes: But surely they can be used to illustrate the issues that this will cause with applications... perhaps narrowing core technologies to the intersection of the un-flawed abilities of all applications will be an increasingly narrowing path which leads no place pleasant. True. I'm not particularly against the idea of using dotless domains, but we know who's going to live with the support questions when users start complaining. Paul's piece on CircleID sums it up nicely. Caveat emptor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
perhaps narrowing core technologies to the intersection of the un-flawed abilities of all applications will be an increasingly narrowing path which leads no place pleasant. True. I'm not particularly against the idea of using dotless domains, but we know who's going to live with the support questions when users start complaining. Paul's piece on CircleID sums it up nicely. Caveat emptor. there is a difference between how we operationally choose to deploy things prudently and a political forum hamstringing a technology while stepping into the turf of the ietf. randy ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
On 21 Sep 2012, at 09:28, Stephane Bortzmeyer wrote: Worked fine with Chromium and lynx, despite the ICANN FUD. Not for me with any of the browsers I had available: Opera, Firefox, Chrome, Safari, Camino, or lynx. YMMV, I guess ... /Niall ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
Phil Regnauld wrote: Surprised no one's brought up http://dk/ as an already existing scenario that doesn't work (try it in various browsers). Bad example. The first *four* browsers I tried (firefox, chrome, safari, and opera on osx) handle this perfectly. B ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
Le 21/09/2012 10:07, Bart Smit a écrit : Phil Regnauld wrote: Surprised no one's brought up http://dk/ as an already existing scenario that doesn't work (try it in various browsers). Bad example. The first *four* browsers I tried (firefox, chrome, safari, and opera on osx) handle this perfectly. B I also succeed opening that url with firefox, chromium and lynx in my ubuntu box. + ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
On 21 Sep 2012, at 10:07, Bart Smit wrote: Phil Regnauld wrote: Surprised no one's brought up http://dk/ as an already existing scenario that doesn't work (try it in various browsers). Bad example. The first *four* browsers I tried (firefox, chrome, safari, and opera on osx) handle this perfectly. Who cares? It's not about which flavour-of-the-month browsers handle this and which ones don't. It's already clear that address records in TLDs lead to unpredictable behaviour. The mutually exclusive results you and Phil got prove this. So it just doesn't matter if it's particular versions of particular browsers that are at fault; or the (configuration) of their stub resolvers; or the local DNS setup; or something else in the underlying OS. The outcome is the same. BTW, I used to have an email address of j@?? at a ccTLD. Its DNS admin had sneaked in an A record for just that purpose. [The registry database wouldn't add MX records.] However very few MTAs and MUAs were able to handle this email address correctly. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
Bart Smit (bit) writes: Phil Regnauld wrote: Surprised no one's brought up http://dk/ as an already existing scenario that doesn't work (try it in various browsers). Bad example. The first *four* browsers I tried (firefox, chrome, safari, and opera on osx) handle this perfectly. Chrome doesn't. I had to enter http://dk./ Internet Explorer doesn't. And try sending mail to test@dk. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
On Fri, 21 Sep 2012, Bart Smit wrote: Bad example. The first *four* browsers I tried (firefox, chrome, safari, and opera on osx) handle this perfectly. I might be a bit daft, but there's a very big difference in my techy-education with typing in URL's versus the regular people who just type something into an input field. Most browsers and/or applications will work very differently when getting the input of something without dots vs something with dots vs something that could be url-sh, often application version, user-settings and OS make/model/version are the behavioral differentiators... :( Kind regards, JP Velders ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
It probably depends on how your O/S handles the resolution - typically Windows systems will try and resolve a dot-less name using a local LAN broadcast looking typically for a PC on the same LAN segment by that name - but it will depend on your config (e.g. domain controller or not, LAN Manager settings etc.etc YMMV etc) IMHO, if they work or not, BRAND holders should simply be aware they probably won't, but they can try if they like, its within RFC. I guess the other issue is do you allow a GLUE record for it in the ROOT zone and if so, how often will you allow those to be updated. On Chrome+Win7 I get different responses for http://dk/ , http://dk./ and https://dk./ but none work :) On 21/09/2012 10:07, Bart Smit wrote: Phil Regnauld wrote: Surprised no one's brought up http://dk/ as an already existing scenario that doesn't work (try it in various browsers). Bad example. The first *four* browsers I tried (firefox, chrome, safari, and opera on osx) handle this perfectly. B ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
On Fri, Sep 21, 2012 at 10:12:42AM +0200, Phil Regnauld wrote: Paul Vixie (paul) writes: gentlefolk, i call your attention to this: http://www.icann.org/en/news/public-comment/sac053-dotless-domains-24aug12-en.htm i've already explained as best i can: http://www.circleid.com/posts/20110620_domain_names_without_dots/ but the icann call for comments remains open, and i urge you to let your voices be heard there. Surprised no one's brought up http://dk/ as an already existing scenario that doesn't work (try it in various browsers). My NetGear router's DNS server doesn't like it: nslookup dk. Server: 192.168.1.1 Address:192.168.1.1#53 ** server can't find dk.: NXDOMAIN ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
Out of 315 TLDs, there are already 17 dotless ones: [list omitted]. This fails to observe the existence of at least two label allocation regimes, one contemporanious with publication of rfc1591 (1994) and one or more that were introduced subsequently, by government contractors. As Paul observed, and a careful reading of the contractor's performance requirement contained in the most recent IANA Function RFI and RFP I and RFP II language supports, the policy for the earlier allocation regime is independent of a notice and comment period announced by the government contractor. The observation that correct function was not certain was dispositive to the decision to bar proposed allocations of labels composed from the range 30--39 (ASCII digits). Independent of whether correct funtion is presently available, allocation without sub-allocation vacates policy stated in rfc1591, and restated as a government contractor policy document (ICP-1). Neither rfc1591 nor ICP-1 have been obsoleted by either the IETF or the government contractor. Independent of the document management policy of the government contractor, no notice and comment period is in the record for a policy of allocations of labels to private persons for the exclusive use by the private person, of which the dotless label applications to the government contractor are a subset. I do not share the perspective offered that there are too many rules, nor do I share the perspective that scale is the only relevant engineering issue posed by label allocation regimes. Eric ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
On Sep 21, 2012, at 4:12 AM, Phil Regnauld regna...@nsrc.org wrote: Paul Vixie (paul) writes: gentlefolk, i call your attention to this: http://www.icann.org/en/news/public-comment/sac053-dotless-domains-24aug12-en.htm i've already explained as best i can: http://www.circleid.com/posts/20110620_domain_names_without_dots/ but the icann call for comments remains open, and i urge you to let your voices be heard there. Surprised no one's brought up http://dk/ as an already existing scenario that doesn't work (try it in various browsers). I'd like to point at a comment submitted by Dmitry Kohmanyuk, one of the admins for the .UA ccTLD, and his dot less experience…. http://forum.icann.org/lists/sac053-dotless-domains/msg2.html W Phil ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
On Fri, 21 Sep 2012, Edward Lewis wrote: In Safari, http://dk./ worked while http://dk/ didn't. Yes. I was going to point that out: the rightmost dot. Traditionally without the rightmost dot is a resource or relative (or whatever you want to call it) and the rightmost dot makes it a /fully/ qualified domain name. (This concept should be familiar to anyone who's edited a zonefile, although ironically it's not easy to find an RFC which defines the FQDN.) The laziness is in how we all talk about root name servers: I never hear anybody say dot name servers. (1034 refers to the 'root .') Or stating it another way: demeter:~ demeter$ dig . ns ; DiG 9.6-ESV-R4-P3 . ns ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 22941 ;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 283 IN NS d.root-servers.net. . 283 IN NS m.root-servers.net. . 283 IN NS h.root-servers.net. . 283 IN NS g.root-servers.net. . 283 IN NS l.root-servers.net. . 283 IN NS b.root-servers.net. . 283 IN NS i.root-servers.net. . 283 IN NS f.root-servers.net. . 283 IN NS j.root-servers.net. . 283 IN NS e.root-servers.net. . 283 IN NS c.root-servers.net. . 283 IN NS a.root-servers.net. . 283 IN NS k.root-servers.net. I don't see root in there anywhere. What I see is .. http://www.google.com./ works fine for me. ;-) -- Fred Morris ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
Stephane, On Sep 21, 2012, at 1:40 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: I'm not particularly against the idea of using dotless domains, but we know who's going to live with the support questions when users start complaining. Paul's piece on CircleID sums it up nicely. Caveat emptor. For the consultation mentioned in Paul Vixie's original message, the issue is not whether one-label domains are a good idea or not but whether ICANN has really nothing better to do than to add yet another stupid regulation in an already very thick book. According to its bylaws, ICANN's responsibility is to ensure the security and stability of the top level of the DNS (among other resources) at the same time as it is supposed to increase competition to improve service, reduce cost, foster innovation, blah blah blah. I'm not sure how ICANN is supposed to do that without 'regulations'. The ICANN community has, through a 10+ year excruciatingly painful process, decided to allow for an unprecedented expansion of the root zone. Regardless of whether the expansion is a good idea, I personally believe that given it is going to occur, it is appropriate to be conservative in the degrees of freedom in which we can shoot ourselves in the foot. As documented in SAC053 (and discussed on this list), weird shit happens because many software developers assumed that a domain name has a dot in it. Given there is one root and that pretty much everybody is dependent upon it, you probably want to minimize the surprises that are associated with the root. To me, this means that you make exceptions to allow for surprises rather than the opposite. Over time, as software developers fix their broken code, it should become easier to get those exceptions for folks that care. Regards, -drc ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
Surprised no one's brought up http://dk/ as an already existing scenario that doesn't work (try it in various browsers). Bad example. The first *four* browsers I tried (firefox, chrome, safari, and opera on osx) handle this perfectly. http://dk/ doesn't work particularly well on my Win 7 laptop: Opera 12.02 - gets me http://www.dk.no/ Firefox 15.01 - gets me http://www.dk.com/ Chrome 21.0.1180.89 - gets me Oops! Google Chrome could not find dk I think it's safe to say that http://dk/ does not *reliably* work the way it's supposed to work. Nobody on this list should be surprised... Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
On 21 Sep 2012 at 10:28, Stephane Bortzmeyer wrote: On Fri, Sep 21, 2012 at 10:12:42AM +0200, Phil Regnauld regna...@nsrc.org wrote a message of 23 lines which said: Surprised no one's brought up http://dk/ as an already existing scenario that doesn't work (try it in various browsers). Worked fine with Chromium and lynx, despite the ICANN FUD. Even if a particular browser supports it and even if it does not exist in a search list, let's not forget all the enterprise networks that restrict access to the web to proxy servers and utilize proxy.pac autoconfiguration scripts. How many of those will include the following line? if (isPlainHostName(host)) return DIRECT; Just another illustration in the long list of reasons it's a really bad idea. It will be a long, long time before a dotless domain would return any sort of vaguely consistent behavior. Scott ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
On 09/21/2012 11:33 AM, sth...@nethelp.no wrote: Surprised no one's brought up http://dk/ as an already existing scenario that doesn't work (try it in various browsers). Bad example. The first *four* browsers I tried (firefox, chrome, safari, and opera on osx) handle this perfectly. http://dk/ doesn't work particularly well on my Win 7 laptop: Opera 12.02 - gets me http://www.dk.no/ Firefox 15.01 - gets me http://www.dk.com/ Chrome 21.0.1180.89 - gets me Oops! Google Chrome could not find dk For FF at least you're experiencing the helpful features that try to guess what you might have meant when you type in single words. I'm pretty sure that Opera has a similar feature, and I know that Chrome does. I have the following settings for FF to turn off that crap: user_pref(keyword.enabled, false); user_pref(browser.fixup.alternate.enabled, false); I think it's safe to say that http://dk/ does not *reliably* work the way it's supposed to work. Nobody on this list should be surprised... No, not surprised. However, I also do not think that the fact that it doesn't work reliably is a reason to forbid it contractually. 1. ccTLDs will always be able to do it, and a non-zero number of them already do. As a result, not allowing gTLDs to do it creates a feature disparity that would have to be justified by serious security and stability considerations. As in, it actually *breaks* something, as opposed to it doesn't work reliably. 2. We are not limited by the status quo. While the _current_ state of things is that we cannot guarantee that single labels will work reliably in all cases, those who are putting very large sums of money into the process of acquiring and operating these domains (especially the .brand domains) will not hesitate to expend effort (and $$) to bring other developers up to speed. For example, in the browser it is a very simple matter to first append a dot to a single label and see if it resolves before trying the search domains. This isn't speculation BTW, we had a similar push to educate developers when the last TLD round went through, and it was necessary to update a lot of software that had old, hard-coded assumptions about what TLD strings were valid. It took a long time to fix it, but we're far out on the tail end of that particular bell-shaped curve atm. 3. It's Ok if they fail. I realize that this idea rankles those of us who have dedicated a lot of energy into making sure that things DON'T break for the end users, but there are a LOT of risks inherent in the latest round of gTLD apps. This particular problem is a relatively minor technical issue that has readily available technical solutions. In all likelihood it can be made to work. Or maybe it can't, so rational gTLD operators will stop doing it. Either way, the risk is on them, and absent actual breakage of something other than the connection between the end user and the gTLD, I personally am happy to allow the gTLD operator to assume that risk. Doug ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
2. We are not limited by the status quo. While the _current_ state of things is that we cannot guarantee that single labels will work reliably in all cases, those who are putting very large sums of money into the process of acquiring and operating these domains (especially the .brand domains) will not hesitate to expend effort (and $$) to bring other developers up to speed. For example, in the browser it is a very simple matter to first append a dot to a single label and see if it resolves before trying the search domains. But is that really, consistently the right thing to do? I suppose that browsers are already more than a little bit pregnant with their willingness to append TLDs to single labels, but suppose someone happens to have a subnet with a bunch of machines named for fruit - apple, pear, grape, etc. Are they going to have to go-in and configure their (possibly auto-updated) browsers to not append that dot so the resolv.conf search directive with their subdomain will still let them get to their apple.subdomain rather than go to apple.? Or will they have to start typing apple.subdomain because they cannot shower as much incentive on browser developers as a .brand holder? It seems like the rules for automagic completion of incomplete names typed into browsers are going to start to look like those for the game of fizbin. rick jones speaking for myself alone ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
David Conrad (drc) writes: As documented in SAC053 (and discussed on this list), weird shit happens because many software developers assumed that a domain name has a dot in it. Given there is one root and that pretty much everybody is dependent upon it, you probably want to minimize the surprises that are associated with the root. To me, this means that you make exceptions to allow for surprises rather than the opposite. Over time, as software developers fix their broken code, it should become easier to get those exceptions for folks that care. I suspect that a non negligible number of gTLD applicants *expect* to be able to use http://wibble/ and mailto:bob@wibble I don't know (and don't care) if the reason that this is suddenly being floated is because of the imminent collision between expectations of applications and the hard limitations of existing implementations (and standards), but I'm pretty sure there will be a lot of pressure to Make Things Work. Contractual obligations to not have anything else than NS/SOA/DNSKEY at the apex might be hard to swallow when you plunk down 200K. So, comment away! (sac053-dotless-doma...@icann.org) P. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
To change the internet so that foo@Microsoft has universal not local meaning would require action by many millions of parties not just by Microsoft. Anyone who did not make the change would be at risk from the new behavior and new content by others while still being compatible with the specs they were born with. The case for public benefit and public safety in the eyes and decisions of ICANN's board could not be more clear. This conversation feels surreal. Paul Randy Bush ra...@psg.com wrote: I suspect that a non negligible number of gTLD applicants *expect* to be able to use http://wibble/ and mailto:bob@wibble and they probably have the leverage to get the significant applications fixed. one of the few benefits of the gtld st00pidity is that microsoft might actually fix lookout so that foo@microsoft will work :) randy ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dotless domains
On 2012-09-22 1:50 AM, e...@abenaki.wabanaki.net wrote: ... finding actionable harm in a restriction on zone data that restricts only private persons who intentionally propose to offer an withdrawn hostname semantic, and only through a few ports and single transport protocol, while overlooking restrictions on general registry operators that have the effect of restricting access to namespaces to tenants of, or implementors of, more highly capitalized registry service platforms than nearly all prior operators, for no discernable reason, is peculiar. -e money changes everything. paul -- It seems like the rules for automagic completion of incomplete names typed into browsers are going to start to look like those for the game of fizbin. --rick jones ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
