Re: [dns-operations] Hearing first complains about failing internal resolving due to .prod TLD
On 13.09.14 17:54, Phillip Hallam-Baker wrote: On Thu, Sep 11, 2014 at 9:12 PM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Sep 11, 2014, at 4:27 PM, Paul Vixie p...@redbarn.org wrote: for the time being, and perhaps for a long time to come, the people who call the presence of .PROD a bug and/or depend on its absence as a feature, outnumbers and will outnumber the people who call it a feature or who will call its absence a bug. How do you measure that? This is a serious question, one that affects DNS operators. If you have a way of determining how many enterprises are negatively affected as a new gTLD rolls out, that would be very useful information. My advice to enterprises is to consider the following: Let the value to your enterprise of resolving the new domains be X Let the value at risk due to resolving the new domains be Y Let the cost of disabling new domain resolution be Z If Y X-Z then the obvious choice is to turn off resolution of new domains. Since X and Z are both zero the choice is obvious. However nice this sounds in theory, the reality is that you can never tightly control name resolution. Of course, you could try to control it, and that attempt too has it's costs, which you should add to the right part of the expression.These costs are far from zero. Daniel ___ 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] Hearing first complains about failing internal resolving due to .prod TLD
On 09/13/2014 10:45 AM, David Conrad wrote: On Sep 13, 2014, at 2:19 AM, Franck Martin fmar...@linkedin.com wrote: I’m not sure why the dot prod was not first set up to return NXDOMAIN, queries logged, and then source IP contacted to warn them May be this is an insight now, may be this is something to do for ALL newly introduced TLDs, set up the resolution for a month with NXDOMAIN and then analyze the logs and see if it could be an issue. You might want to look at https://www.jasadvisors.com/namespace-expansion-i.pdf. Interestingly, .prod had only 146 (filtered) unique SLDs in the DITL data. This was discussed in the last year or so of ‘discussions’ related to name collision. Trivial to game, difficulties finding the actual source, difficulties in establishing what could be an issue vs. a false positive, etc. I've tried (I hope) to make it clear whenever opportune, that OARC's DITL data should only ever have been regarded as *a* source of policy-informing analysis for Name Collisions, and should not in any way be regarded as comprehensive or definitive. We were more than happy to step up with what we had in the absence of anything else, but other data sources would have been and would remain welcome. It seems we may be seeing the first signs of the gap between reality and the dimensionally-constrained worldview of OARC data. Here's a couple of ideas I'd like to put out there: - now that various of the nTLDs have been delegated into Controlled Interruption mode, would it be helpful for OARC to do an additional (or periodic) DITL capture(s), so we can get some comparison between what we thought we'd be seeing and what are seeing ? - are there any other types of data-gathering that OARC could perform for the community that would help us understand these issues better (and if so what, and who would like to help) ? There were some proposals for such data gathering mooted, but AIUI did not get sufficient support in the ICANN process to be mandated. Keith ___ 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] Hearing first complains about failing internal resolving due to .prod TLD
On Sep 12, 2014, at 1:27 AM, Paul Vixie p...@redbarn.org wrote: On 9/11/2014 9:07 AM, Paul Wouters wrote: Guess the first people are now finding out that .prod went live. I heard from a large webhoster that their sysadmins use db1.prod for a shorthand of db1.prod.corp.com. They are now attempting to go to the 127.0.53.53 warning pit. I had never through of prod being a problem. but it might actualy be a pretty big one, along with stag if that is ever delegated. i've been helping folks configure DNS RPZ on their recursive name servers in a way that reverts .PROD lookups to the previous NXDOMAIN behaviour, thus fixing their apparent stub-resolver client breakage. of course the real problem is using nonqualified names, but since that has worked reliably for several decades, we can expect a long tail of adaptation. for the time being, and perhaps for a long time to come, the people who call the presence of .PROD a bug and/or depend on its absence as a feature, outnumbers and will outnumber the people who call it a feature or who will call its absence a bug. see also https://www.icann.org/en/system/files/files/sac-064-en.pdf. I’m not sure why the dot prod was not first set up to return NXDOMAIN, queries logged, and then source IP contacted to warn them of such upcoming change. May be this is an insight now, may be this is something to do for ALL newly introduced TLDs, set up the resolution for a month with NXDOMAIN and then analyze the logs and see if it could be an issue. signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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] Hearing first complains about failing internal resolving due to .prod TLD
Because as tld operators we see queries from the recursive resolver, not the end user, Francisco Obispo On Sep 13, 2014, at 2:19 AM, Franck Martin fmar...@linkedin.com wrote: On Sep 12, 2014, at 1:27 AM, Paul Vixie p...@redbarn.org wrote: On 9/11/2014 9:07 AM, Paul Wouters wrote: Guess the first people are now finding out that .prod went live. I heard from a large webhoster that their sysadmins use db1.prod for a shorthand of db1.prod.corp.com. They are now attempting to go to the 127.0.53.53 warning pit. I had never through of prod being a problem. but it might actualy be a pretty big one, along with stag if that is ever delegated. i've been helping folks configure DNS RPZ on their recursive name servers in a way that reverts .PROD lookups to the previous NXDOMAIN behaviour, thus fixing their apparent stub-resolver client breakage. of course the real problem is using nonqualified names, but since that has worked reliably for several decades, we can expect a long tail of adaptation. for the time being, and perhaps for a long time to come, the people who call the presence of .PROD a bug and/or depend on its absence as a feature, outnumbers and will outnumber the people who call it a feature or who will call its absence a bug. see also https://www.icann.org/en/system/files/files/sac-064-en.pdf. I’m not sure why the dot prod was not first set up to return NXDOMAIN, queries logged, and then source IP contacted to warn them of such upcoming change. May be this is an insight now, may be this is something to do for ALL newly introduced TLDs, set up the resolution for a month with NXDOMAIN and then analyze the logs and see if it could be an issue. ___ 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] Hearing first complains about failing internal resolving due to .prod TLD
Franck, On Sep 13, 2014, at 2:19 AM, Franck Martin fmar...@linkedin.com wrote: I’m not sure why the dot prod was not first set up to return NXDOMAIN, queries logged, and then source IP contacted to warn them of such upcoming change. The source IP is a resolver, not the original querier. I’m guessing Google doesn’t need to be warned :). May be this is an insight now, may be this is something to do for ALL newly introduced TLDs, set up the resolution for a month with NXDOMAIN and then analyze the logs and see if it could be an issue. You might want to look at https://www.jasadvisors.com/namespace-expansion-i.pdf. Interestingly, .prod had only 146 (filtered) unique SLDs in the DITL data. This was discussed in the last year or so of ‘discussions’ related to name collision. Trivial to game, difficulties finding the actual source, difficulties in establishing what could be an issue vs. a false positive, etc. The behavior of returning 127.0.53.53 is specifically intended to interrupt normal behavior in a less damaging way (at least compared to the alternative interruption approaches) so people notice and can go and fix things. See https://www.icann.org/en/system/files/files/name-collision-mitigation-study-06jun14-en.pdf for a longer explanation of the current approach used to deal with name collision. Regards, -drc (ICANN CTO, but speaking only for myself) signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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] Hearing first complains about failing internal resolving due to .prod TLD
On Sep 13, 2014, at 2:19 AM, Franck Martin fmar...@linkedin.com wrote: I’m not sure why the dot prod was not first set up to return NXDOMAIN, queries logged, and then source IP contacted to warn them of such upcoming change. Because ICANN decided to do it a different way, as has already been described a few times earlier in this thread. May be this is an insight now, may be this is something to do for ALL newly introduced TLDs, set up the resolution for a month with NXDOMAIN and then analyze the logs and see if it could be an issue. Proposal: we don't use this mailing list to re-debate what ICANN should have done for new gTLDs. There was plenty of earlier discussion in ICANN and at the Verisign workshop. ICANN made a decision and implemented it. Arguing about that history here is about as useful as arguing about the history of BIND. --Paul Hoffman ___ 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] Hearing first complains about failing internal resolving due to .prod TLD
On Thu, Sep 11, 2014 at 08:42:45PM -0700, Doug Barton wrote: 3. You respond with the same URL, plus pontification on various topics, If by pontification on various topics you mean the bit about how the new gTLD database actually can tell you what stuff has passed all the hurdles, even if it's not in a form trivially useful to geeks, then I suppose you're right. including a list of already delegated TLDs that you point out is not updated in real time I didn't point that out, the page itself did. I am prepared to grant it mystifying to me that ICANN, which holds the IANA contract, is unable to mirror content from IANA pages into ICANN pages, but I am not prepared to comment further. about the need for ICANN to publish 'Here's what we plan to delegate next,' without perhaps giving a time. Which, FWIW, is the exact content of the URL that I (and you) responded to Joshua with in the first place. If that were actually the exact content of that URL, then I'd have posted the URL in the first place and said nothing more. It is nowhere clear that that's what it is on any site that I've yet found, and certainly the page itself does not indicate that. I'd be pleased to learn that http://newgtlds.icann.org/en/program-status/delegated-strings includes dates in the future (or even pending in the date column), but I've no evidence to support that. If you have it, then I'd be super interested in seeing it. Now, did I get all that right? Apparently not. Because I really want to benefit from your wisdom here. :) Many will tell you, in case you have not already figured this out yourself, that the wisdom I proffer is pretty thin gruel. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ 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] Hearing first complains about failing internal resolving due to .prod TLD
On Fri, Sep 12, 2014 at 02:35:37PM +1000, Mark Andrews wrote: WARNING: The partially qualified name '%s' resulted in a search list match. The use of partially qualified names is a unsafe practice. Fix your configuration to use the fully qualified name '%s'. Linux developers do stuff like this for deprecated system calls where the user has zero control. Here the user can correct the configuration / behaviour. With respect, do you think there is a difference between the responses of Linux kernel (or kernel module) developers and their response to syslog entries, and the responses of random name server operators around the Internet? I can think of possibly one or two relevant considerations. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ 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] Hearing first complains about failing internal resolving due to .prod TLD
Paul Ferguson fergdawgs...@mykolab.com wrote: https://mm.icann.org/mailman/listinfo/gtldnotification There's a big lag between notifications on that list and actual delegation, e.g. the cymru agreement was signed in May and delegation happened this month. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly 5 or 6. Slight or moderate. Showers in northwest. Good. ___ 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] Hearing first complains about failing internal resolving due to .prod TLD
On 12.09.14 05:47, Paul Vixie wrote: in fairness, had we adopted the left-to-right presentation format preferred at first by our UK colleagues, we would have always had to write fully qualified names as .tld.sld.3ld, that is, the root dot would not have been optional, and there would have been no confusion between unqualified, partially qualified, and fully qualified domain names. Even better, the DNS would not have turned into the vanity show it is today. But then, that means none of today's behemoths would exist. I find this all ironic. It was known creating 'arbitrary' labels at the root will lead to that. Not that the very same problem does not exist with old TLDs, good example being the ws ccTLD. I got bit by that creating a 'ws' server and trying to address it with unqualified name just like any of the rest. Imagine, if .corp decide to have an A/ (or some other fancy) record one could not have a 'corp' server too. Pick your favorite new gTLD for better example... It's too late to teach Internet users and existing setups/applications to use fully qualified names and put a dot at the end (because of the TLD.TLD problem, too). One could even argue the damage in wasted resources, lost business, bad service etc for all concerned is way more than the benefits being created by the new gTLDs for a much smaller group of people. C'est la vie.. Daniel ___ 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] Hearing first complains about failing internal resolving due to .prod TLD
On 12.09.14 07:35, Mark Andrews wrote: In message 541271ba.2000...@redbarn.org, Paul Vixie writes: like i said this seems insane now. mark was right, we should have broken the bad stuff as early as possible. It isn't impossible. Emit warnings whenever a partially qualified name matches and syslog / EventLog it. WARNING: The partially qualified name '%s' resulted in a search list match. The use of partially qualified names is a unsafe practice. Fix your configuration to use the fully qualified name '%s'. How many end users do you know that look at log files? How many even know log files exist and where/how to find them? Would you expect a browser, mail client, IM etc software author to agree to pop up such a message to the end user? These will likely first look for a way to silence the warnings. Likewise, while the SSAC research and recommendations on the topic are useful for those in the know (mostly, to explain why some of the long standing presumptions are indeed wrong) --- it is highly unlikely the general public will be either aware of these findings, able to implement the suggested solutions or even care About the only way to 'fix' this is to implement it in code and distribute the code as widely as possible. Such fixed code will sure break many things.. similarly as DNSSEC breaks/identifies bad DNS setups. Daniel ___ 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] Hearing first complains about failing internal resolving due to .prod TLD
Em 11/09/2014, à(s) 22:58:000, Joshua Smith juice...@gmail.com escreveu: Probably something I should know. But what's the best way to get notified of new TLDs coming online to help arm the NOC? Two ways: signing up to https://mm.icann.org/mailman/listinfo/gtldnotification where you know a contract has been signed (which predates root delegation by some weeks) or monitoring https://newgtlds.icann.org/newgtlds.csv for the same information. CSV will also indicate delegation, but that is not as real time as IANA information. Rubens ___ 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] Hearing first complains about failing internal resolving due to .prod TLD
On Sep 11, 2014, at 7:40 PM, Andrew Sullivan a...@anvilwalrusden.com wrote: https://data.iana.org/TLD/tlds-alpha-by-domain.txt Yes, but that's what's already in fact delegated, not what is about to (so it's the same as just getting the root zone, AFAICT). I think what would have been better is a feed that said, Here's what we plan to delegate next, without perhaps giving a time. But I understand why ICANN decided it couldn't do that. I guess it would be helpful to better understand the use cases this information would be used for prior to delegation to inform how what is already published could be expanded. From my perspective, we don't have a guarantee that a specific TLD is going to be delegated until we see it with our own eyes being propagated to the root servers. The prospect of a prod TLD, along with all the other candidate new gTLDs, was announced on 13 June 2012. Since then with the various strings we have had increasing levels of confidence certain strings are likely to be delegated. From application, there are a series of steps including initial evaluation, pre-delegation testing, contracting, delegation request etc. with the passing of each step making it increasingly more likely a given string will be delegated. Verisign does the final publication and dissemination of a revised root zone, and signals back to ICANN shortly prior to a root zone push (minutes or hours) that a particular root zone change is ancticipated to be reflected in the next zone push. I think even then it still does not provide a guarantee that it won't be pulled back due to a last minute issue. I would ask, what is gained by tracking in the hours, days or weeks in advance that a TLD is likely to be delegated? How will it help compared to having the list from 2012 of all the strings being considered already in hand? kim ___ 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] Hearing first complains about failing internal resolving due to .prod TLD
On Sep 12, 2014, at 6:46 AM, Daniel Kalchev dan...@digsys.bg wrote: It's too late to teach Internet users and existing setups/applications to use fully qualified names and put a dot at the end (because of the TLD.TLD problem, too). I disagree with this comment, we need to fix what’s broken and move on. One could even argue the damage in wasted resources, lost business, bad service etc for all concerned is way more than the benefits being created by the new gTLDs for a much smaller group of people. How about in 20 years? would it be the same? I don’t think so. My daughter who is 3 years old will not know the difference between a .COM and a .LINK name, I believe it is a generational issue. Remember that when you mention a “smaller group of people” also include the of new TLDs that are IDNs, which now enables people to type URLs in their native languages.. The Internet needs to evolve to be more inclusive and new TLDs are just a part of that. -- Francisco Obispo CTO - Registry Operations fobi...@uniregistry.com PGP Key ID: 0xB38DB1BE ___ 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] Hearing first complains about failing internal resolving due to .prod TLD
On 9/11/14 10:58 PM, Andrew Sullivan wrote: On Thu, Sep 11, 2014 at 08:42:45PM -0700, Doug Barton wrote: 3. You respond with the same URL, plus pontification on various topics, If by pontification on various topics you mean the bit about how the new gTLD database actually can tell you what stuff has passed all the hurdles, even if it's not in a form trivially useful to geeks, then I suppose you're right. including a list of already delegated TLDs that you point out is not updated in real time I didn't point that out, the page itself did. From your message to Joshua: There's also http://newgtlds.icann.org/en/program-status/delegated-strings, but it explicitly says that it's not being updated in real time. But maybe that's what you meant ... it's really quite hard for me to tell what the heck you're talking about at this point. :) I am prepared to grant it mystifying to me that ICANN, which holds the IANA contract, is unable to mirror content from IANA pages into ICANN pages, but I am not prepared to comment further. On this we are in agreement. Kim, if you're following this, your message today about the process that's followed by Verisign in updating ICANN about changes matches my recollection of the process, which is either comforting, or disturbing, I'm not sure which. :) It would be appreciated if you could communicate internally that the IANA department within ICANN has a process to keep the protocol parameters list up to date in (near) real time, and that there is a community expectation (quite reasonable IMO) that the equivalent ICANN pages also be updated in a timely manner. about the need for ICANN to publish 'Here's what we plan to delegate next,' without perhaps giving a time. Which, FWIW, is the exact content of the URL that I (and you) responded to Joshua with in the first place. If that were actually the exact content of that URL, then I'd have posted the URL in the first place and said nothing more. So here is where the conversations goes off the rails. This page: https://gtldresult.icann.org/application-result/applicationstatus shows the list of applications, which ones have been approved, and the order in which they will be delegated. It doesn't have dates, but as far as I can see it completely meets your requirements for, 'Here's what we plan to delegate next,' without perhaps giving a time. I'm also not sure how a form trivially useful to geeks fits into the equation here, as this kind of list (per Joshua's original request) is really more of an FYI sort of thing, and not intended to be machine parsable. It's not clear to me why you'd want a machine parsable list of here's what's going to be delegated next, but if you can come up with a use case, Kim may be able to hook you up. :) Maybe the source of your confusion is that the URL above and the delegated-strings page that you keep going on about are actually quite different things? Have you visited the applicationstatus page? If not, I think you'll be quite pleasantly surprised. :) It is nowhere clear that that's what it is on any site that I've yet found, and certainly the page itself does not indicate that. I'd be pleased to learn that http://newgtlds.icann.org/en/program-status/delegated-strings includes dates in the future (or even pending in the date column), but I've no evidence to support that. If you have it, then I'd be super interested in seeing it. Now, did I get all that right? Apparently not. Because I really want to benefit from your wisdom here. :) Many will tell you, in case you have not already figured this out yourself, that the wisdom I proffer is pretty thin gruel. And yet the thing that's great about you, Andrew, is that you never let that stop you from offering it anyway. In all seriousness, I keep belaboring this point because I think it's useful for the community to know that the very thing that Joshua asked for is actually being provided by ICANN, and that it's a worthwhile exercise to review that list to see if any of your internal-only TLDs are on it. It's also worthwhile to give this a read: https://www.icann.org/en/system/files/files/name-collision-mitigation-01aug14-en.pdf since it describes the 127.0.53.53 stuff, as well as provides the interesting news that ICANN will indefinitely defer delegating three TLDs: .corp, .home, and .mail. The doc goes on to explain that indefinitely does not mean forever. hth, 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] Hearing first complains about failing internal resolving due to .prod TLD
Daniel Kalchev writes: On 12.09.14 05:47, Paul Vixie wrote: in fairness, had we adopted the left-to-right presentation format preferred at first by our UK colleagues, we would have always had to write fully qualified names as .tld.sld.3ld, that is, the root dot would not have been optional, and there would have been no confusion between unqualified, partially qualified, and fully qualified domain names. Even better, the DNS would not have turned into the vanity show it is today. How do you figure? ___ 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] Hearing first complains about failing internal resolving due to .prod TLD
Hi, Guess the first people are now finding out that .prod went live. I heard from a large webhoster that their sysadmins use db1.prod for a shorthand of db1.prod.corp.com. They are now attempting to go to the 127.0.53.53 warning pit. I had never through of prod being a problem. but it might actualy be a pretty big one, along with stag if that is ever delegated. Paul ___ 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] Hearing first complains about failing internal resolving due to .prod TLD
Perhaps they need to set the ‘ndots’ option in resolv.conf to trigger absolute queries if they find more than 1 dot, so something like: options ndots 2 would prevent a query to the .prod. TLD. from ‘man resolv.conf’ ndots:n sets a threshold for the number of dots which must appear in a name given to res_query(3) (see resolver(3)) before an initial absolute query will be made. The default for n is 1, meaning that if there are any dots in a name, the name will be tried first as an absolute name before any search list elements are appended to it. The value for this option is silently capped to 15. francisco On Sep 11, 2014, at 9:07 AM, Paul Wouters p...@nohats.ca wrote: Hi, Guess the first people are now finding out that .prod went live. I heard from a large webhoster that their sysadmins use db1.prod for a shorthand of db1.prod.corp.com. They are now attempting to go to the 127.0.53.53 warning pit. I had never through of prod being a problem. but it might actualy be a pretty big one, along with stag if that is ever delegated. Paul ___ 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] Hearing first complains about failing internal resolving due to .prod TLD
On 9/11/2014 9:07 AM, Paul Wouters wrote: Guess the first people are now finding out that .prod went live. I heard from a large webhoster that their sysadmins use db1.prod for a shorthand of db1.prod.corp.com. They are now attempting to go to the 127.0.53.53 warning pit. I had never through of prod being a problem. but it might actualy be a pretty big one, along with stag if that is ever delegated. i've been helping folks configure DNS RPZ on their recursive name servers in a way that reverts .PROD lookups to the previous NXDOMAIN behaviour, thus fixing their apparent stub-resolver client breakage. of course the real problem is using nonqualified names, but since that has worked reliably for several decades, we can expect a long tail of adaptation. for the time being, and perhaps for a long time to come, the people who call the presence of .PROD a bug and/or depend on its absence as a feature, outnumbers and will outnumber the people who call it a feature or who will call its absence a bug. see also https://www.icann.org/en/system/files/files/sac-064-en.pdf. vixie ___ 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] Hearing first complains about failing internal resolving due to .prod TLD
On 9/11/2014 6:30 PM, Paul Vixie wrote: ... i have a lot of data but no obvious way to distill this determination out of it. as to this part, let me quote what i said on another mailing list earlier today, on a similar thread (.PROD collisions): On 9/11/2014 2:57 PM, Paul Vixie wrote: ... so, we (farsight security; home of SIE and DNSDB) do not currently store or measure NXDOMAIN traffic, but it has seemed to me that with ~350 name servers sending us ~150K cache miss transactions per second, we ought to be able to see contrails from gTLD collisions. if anybody has a proposal for a (not-for-fee) experiment, or (not-for-fee) continuous monitoring, i'm all ears. vixie that offer is generally open to unfunded nonprofit DNS researchers who want to help study collisions. contact me directly if you're interested. vixie ___ 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] Hearing first complains about failing internal resolving due to .prod TLD
Probably something I should know. But what's the best way to get notified of new TLDs coming online to help arm the NOC? -- Josh Smith KD8HRX Email/jabber: juice...@gmail.com Phone: 304.237.9369(c) Sent from my iPhone. On Sep 11, 2014, at 9:32 PM, Paul Vixie p...@redbarn.org wrote: On 9/11/2014 6:30 PM, Paul Vixie wrote: ... i have a lot of data but no obvious way to distill this determination out of it. as to this part, let me quote what i said on another mailing list earlier today, on a similar thread (.PROD collisions): On 9/11/2014 2:57 PM, Paul Vixie wrote: ... so, we (farsight security; home of SIE and DNSDB) do not currently store or measure NXDOMAIN traffic, but it has seemed to me that with ~350 name servers sending us ~150K cache miss transactions per second, we ought to be able to see contrails from gTLD collisions. if anybody has a proposal for a (not-for-fee) experiment, or (not-for-fee) continuous monitoring, i'm all ears. vixie that offer is generally open to unfunded nonprofit DNS researchers who want to help study collisions. contact me directly if you're interested. vixie ___ 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] Hearing first complains about failing internal resolving due to .prod TLD
On Thu, Sep 11, 2014 at 09:58:59PM -0400, Joshua Smith wrote: Probably something I should know. But what's the best way to get notified of new TLDs coming online to help arm the NOC? Probably the _best_ way is to get copies of the root zone. There's also http://newgtlds.icann.org/en/program-status/delegated-strings, but it explicitly says that it's not being updated in real time. You can find out whether something will _eventually_ be delegated by looking at https://gtldresult.icann.org/application-result/applicationstatus. If you look at completed PDT, that tells you that they've completed the pre-delegation testing, so they're going to be delegated at some point. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ 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] Hearing first complains about failing internal resolving due to .prod TLD
In message 45b62715-b7f9-439e-81b3-6c7356e88...@vpnc.org, Paul Hoffman writes : On Sep 11, 2014, at 4:27 PM, Paul Vixie p...@redbarn.org wrote: for the time being, and perhaps for a long time to come, the people who call the presence of .PROD a bug and/or depend on its absence as a feature, outnumbers and will outnumber the people who call it a feature or who will call its absence a bug. How do you measure that? This is a serious question, one that affects DNS ope rators. If you have a way of determining how many enterprises are negatively affected as a new gTLD rolls out, that would be very useful information. I just wish I had been able to convince Paul to remove support for partially qualified names back when RFC 1535 came out. We knew then that they were a bad idea. ndots minimises the damage of using partially qualified names. It doesn't remove it. The real fix is make the resolver libraries not append search lists entries to names with multiple labels. Yes, people need to type slightly long names or add more search list entries. Yes there will be some pain but it is something better done sooner rather than later. Mark -- 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] Hearing first complains about failing internal resolving due to .prod TLD
On 9/11/14 6:58 PM, Joshua Smith wrote: Probably something I should know. But what's the best way to get notified of new TLDs coming online to help arm the NOC? https://gtldresult.icann.org/application-result/applicationstatus hth, 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] Hearing first complains about failing internal resolving due to .prod TLD
On 9/11/2014 7:08 PM, Mark Andrews wrote: ... I just wish I had been able to convince Paul to remove support for partially qualified names back when RFC 1535 came out. We knew then that they were a bad idea. ndots minimises the damage of using partially qualified names. It doesn't remove it. at the time (1993?) i felt it was best not to break anybody's existing configuration. that seems insane now. The real fix is make the resolver libraries not append search lists entries to names with multiple labels. Yes, people need to type slightly long names or add more search list entries. Yes there will be some pain but it is something better done sooner rather than later. partially qualified names (so, has an interior dot) should never have been allowed to work, anywhere, not even for a day. once they existed, it should have been somebody's job to stomp them to death. for my part in these events, i apologize to one and all. in fairness, had we adopted the left-to-right presentation format preferred at first by our UK colleagues, we would have always had to write fully qualified names as .tld.sld.3ld, that is, the root dot would not have been optional, and there would have been no confusion between unqualified, partially qualified, and fully qualified domain names. or with a little bit of arm twisting at the right time in the right place, search lists could have been explicit, as in, if you want FOO.BAR to be looked up in the client's preferred local contexts, you'd write it as FOO.BAR.+ or similar. the presentation layer is where DNS shows its greatest design weaknesses. (just ask the IDN folks, they'll tell you.) vixie vixie ___ 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] Hearing first complains about failing internal resolving due to .prod TLD
On 9/11/14 7:40 PM, Andrew Sullivan wrote: On Thu, Sep 11, 2014 at 07:15:03PM -0700, Doug Barton wrote: If you want a text list of TLDs that *is* updated in real time, you can use this: https://data.iana.org/TLD/tlds-alpha-by-domain.txt Yes, but that's what's already in fact delegated, not what is about to (so it's the same as just getting the root zone, AFAICT). Right. I was responding to your comment about http://newgtlds.icann.org/en/program-status/delegated-strings not being updated in real time. The IANA list is updated at the same time a new string goes into the root zone. So like the list you mentioned, it contains the list of delegated strings, but IS actually updated in real time. Am I missing something here? 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] Hearing first complains about failing internal resolving due to .prod TLD
On Thu, Sep 11, 2014 at 07:48:27PM -0700, Doug Barton wrote: Am I missing something here? Only the point of the part of the message you elided in your response. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ 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] Hearing first complains about failing internal resolving due to .prod TLD
On 9/11/14 7:53 PM, Andrew Sullivan wrote: On Thu, Sep 11, 2014 at 07:48:27PM -0700, Doug Barton wrote: Am I missing something here? Only the point of the part of the message you elided in your response. Ok, so let's recap, to make sure I get the point. Because I like to, yaknow, learn stuff. :) 1. Joshua asks if there is a way to be notified of new TLDs coming online 2. I respond with the URL that addresses his concern 3. You respond with the same URL, plus pontification on various topics, including a list of already delegated TLDs that you point out is not updated in real time 4. I respond to say that if you want such a list of already-delegated TLDs that is updated in real time, the IANA has one 5. You respond, apparently to reiterate the point that this list contains the TLDs that have already been delegated, along with more pontification about the need for ICANN to publish 'Here's what we plan to delegate next,' without perhaps giving a time. Which, FWIW, is the exact content of the URL that I (and you) responded to Joshua with in the first place. Now, did I get all that right? Because I really want to benefit from your wisdom here. :) 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] Hearing first complains about failing internal resolving due to .prod TLD
On 9/11/2014 8:22 PM, Mark Andrews wrote: In message 54125edc.6000...@redbarn.org, Paul Vixie writes: On 9/11/2014 7:08 PM, Mark Andrews wrote: ... I just wish I had been able to convince Paul to remove support for partially qualified names back when RFC 1535 came out. We knew then that they were a bad idea. ndots minimises the damage of using partially qualified names. It doesn't remove it. at the time (1993?) i felt it was best not to break anybody's existing configuration. that seems insane now. The configuration is *already* broken. If you are depending upon partially qualified names then they are a time bomb waiting to happen. you know what would be cool is if i still used MH and could usefully search my e-mail archives to prove that paul vixie and mark andrews just now (2014-09-11) repeated almost verbatim a debate we had some time in 1993 or 1994. it would not just be funny, but perhaps also depressing, and it would save time. i believe that the next line of dialogue from this play is: vixie: your definition of 'break' is academic, mine is practical. right now the people who are using unqualified names are getting work done and they are not calling me to report bugs in the BIND resolver. if i make the change you are suggesting, they stop getting work done and they will look me up in WHOIS and call my phone. like i said this seems insane now. mark was right, we should have broken the bad stuff as early as possible. Today the resolver does as entered, if it has a period then applies the search list. If ndots != 0 and it has a period then it applies the search list and then as is. Unqualified search list then as is. Note the search list is always applied and it continues on NODATA, SERVFAIL which is also a security issue. NXDOMAIN should be the *only* result which moves to the next search list element. If a zone in the search list is broken, then fix it. Users can type fully qualified names to work around the issue and configuration files should only ever have fully qualified names. those words, the resolver, may not mean any more what you think they mean. the most widely cloned and forked resolver logic on the internet remains BIND 4's. not even the libbind (now netresolv) logic comes close to the footprint of that old crappy pre-ndots logic. all growth will be in the form of either dnsget API or ietf getaddrinfo / getnameinfo. i feverishly hope that both of these will subscribe to the logic described in: https://www.icann.org/en/system/files/files/sac-064-en.pdf if your resolver is to be used as a stub by any system library anywhere, i hope it will subscribe to the SAC064 logic. The best long term solution is if it has a period, try as is. If it does not have a period append search list against the DNS. localhost matches against /etc/hosts or becomes a explict exception. you sound like a man about to author an internet draft for IETF DNSOP. Iterim if it has a period, try as is. If ndots != 0 then try search list then try as is. If it does not have a period append search list against the DNS. localhost matches against /etc/hosts or becomes a explict exception. Ndots is a explict trigger for broken behaviour. yeah i don't think that anything like ndots could be standardized or should be implemented at this point in time. ndots was my suggested workaround for the EDU.COM problem, and shows that more review was needed. vixie ___ 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] Hearing first complains about failing internal resolving due to .prod TLD
In message 541271ba.2000...@redbarn.org, Paul Vixie writes: On 9/11/2014 8:22 PM, Mark Andrews wrote: In message 54125edc.6000...@redbarn.org, Paul Vixie writes: On 9/11/2014 7:08 PM, Mark Andrews wrote: ... I just wish I had been able to convince Paul to remove support for partially qualified names back when RFC 1535 came out. We knew then that they were a bad idea. ndots minimises the damage of using partially qualified names. It doesn't remove it. at the time (1993?) i felt it was best not to break anybody's existing configuration. that seems insane now. The configuration is *already* broken. If you are depending upon partially qualified names then they are a time bomb waiting to happen. you know what would be cool is if i still used MH and could usefully search my e-mail archives to prove that paul vixie and mark andrews just now (2014-09-11) repeated almost verbatim a debate we had some time in 1993 or 1994. it would not just be funny, but perhaps also depressing, and it would save time. i believe that the next line of dialogue from this play is: vixie: your definition of 'break' is academic, mine is practical. right now the people who are using unqualified names are getting work done and they are not calling me to report bugs in the BIND resolver. if i make the change you are suggesting, they stop getting work done and they will look me up in WHOIS and call my phone. like i said this seems insane now. mark was right, we should have broken the bad stuff as early as possible. It isn't impossible. Emit warnings whenever a partially qualified name matches and syslog / EventLog it. WARNING: The partially qualified name '%s' resulted in a search list match. The use of partially qualified names is a unsafe practice. Fix your configuration to use the fully qualified name '%s'. Linux developers do stuff like this for deprecated system calls where the user has zero control. Here the user can correct the configuration / behaviour. Mark -- 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
