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] is there a diagnostic tool to obtain delegated ns?
On Fri, Sep 12, 2014 at 12:13:00PM +1000, Mark Andrews ma...@isc.org wrote a message of 57 lines which said: The following will work for any zone w/o a embedded period in a label. Loops endlessly for names like ssi.gouv.fr parent=`expr X$zone : '^[^.]*.\(.*\)'` Should it be parent=`expr X$parent : '^[^.]*.\(.*\)'` ? ___ 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] Dumb question: why is it that some, registries limit the nameservers that can be delegated to?
On 11/09/2014 19:03, dns-operations-requ...@dns-oarc.net wrote: Thanks for the explanation, that helps! If we step back from the practise, do we think it's a good thing? I'm of the opinion that something that can be determined algorithmically (i.e. when glue should or shouldn't be added), should be done exactly that way. A separate registration process prevents this and introduces a whole bunch of other issues, such as who owns the object, who can operate on it, what happens when it gets orphaned, or the parent changes registrar, what happens to dependencies on deletion etc. And I'm also 100% with marka on this. If the server being delegated to can't respond for the name being delegated to, the Registry delegating thereto is just being irresponsible. [with delegation being separate to registration imho] but I increasingly find myself on the losing end of these arguments when money or market entrenchment/forces come into play. --Calvin One the one hand, requiring that nameservers be registered creates downward pressure on the number of active authoritative name server names in the world, which has benefits for cache efficiencies (ie many zones delegated to the same names). One the other hand, it can be beneficial to give every zone unique name server names (in-zone vanity names, or otherwise), even if those names resolve to the same name-servers. That would makes it easier to manage single zone migrations and things like DDOS isolation. These days I think it might be as common to move a single zone around as it is to renumber a host. ___ 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] Dumb question: why is it that some registries limit the nameservers that can be delegated to?
On 11.09.14 21:51, Colm MacCárthaigh wrote: For example if a provider booted a box with an empty configuration, it would be much better to timeout queries than respond with SERVFAIL or REFUSED. The protocol expects and response from the server. If no response, the server is considered down. Some of the proposed ways to fix recent DDoS involve temporarily suspending queries to servers that do not respond (in time). This is what will happen to your authoritative server, if you configure it to exhibit such behavior. What you intend to do is probably best served by connection refused response. 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] Dumb question: why is it that some registries limit the nameservers that can be delegated to?
On 12.09.14 04:24, Andrew Sullivan wrote: On Thu, Sep 11, 2014 at 09:35:40PM -0300, Rubens Kuhl wrote: It was curious to see that a to-be-unnamed TLD registry, a newcomer to the scene many years after the holy wars that ended up defining the current RFCs, writing completely new code, mentioned that they found attributes to be a better option Well, note, the RFCs actually allow you to do one or the other, so there was no victor in the war. Many people when designing a new registry think attributes are better because they don't create cross-object links. If you come from the database side of the house (which I do), you are given shudders because of the potential for data inconsistency in glue. Lots of new registries don't have a glue problem early on, and so this never seems like it's worth worrying about. That's the real reason I prefer the host-object approach. But like Frederico, I don't want to reignite a controversy. If you truly did not want to re-ignite this, you would not have stated opinion -- there is a reason both ways end up in the RFCs, as both work and it's all a matter of diligence (and software). Here is mine The host-object approach is the worst choice, ever. It suits certain operators idea of 'visibility', but does not help with data consistency. Consider the scenario of domain.com delegated to pns1.otherdomain.com and pns2.otherdomain.com. However otherdomain.com is delegated to ns1.otherdomain.com and ns2.otherdomain.com. Obviously, otherdomain.com is the 'service provider'. In theory, the ns1.otherdomain.com and ns2.otherdomain.com need to have glue records. Everything else is extraneous, vanity stuff if you will and add to the maintenance and data consistency burden. variant 1: ns1.otherdomain.com and ns2.otherdomain.com are attributes to the otherdomain.com object. Everything is as it should be. Whoever controls the domain object, controls the glue. The domain object is gone, so is the glue. Perfect! variant 2: ns1.otherdomain.com, ns2.otherdomain.com, pns1.otherdomain.com and pns2.otherdomain.com are all host-objects. Who owns them? Which of them can/do have glue? True, a much more complex (read: more prone to errors and harder to verify) piece of software could handle all the mess. Most of the cases of EPP software are however quite trivial. What happens when otherdomain.com gets deleted? Which host-objects disappear, if any, which glue remains, who ends up managing those records, etc. Zombie host-objects aren't that impossible, right? As a Hollywood cop would say follow the money. Who has most interest for the host objects to exist? Certainly, not the typical domain name owner. better, but for me it indicates that the role in the value chain can play a part in which option is preferred. Yes. Interoperability is way more important that just about anything else on the Internet. You mean... whose operations would be cheaper? :) The bigger fish wins most of the time. 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] is there a diagnostic tool to obtain delegated ns?
In message 20140912074519.gb11...@nic.fr, Stephane Bortzmeyer writes: On Fri, Sep 12, 2014 at 12:13:00PM +1000, Mark Andrews ma...@isc.org wrote a message of 57 lines which said: The following will work for any zone w/o a embedded period in a label. Loops endlessly for names like ssi.gouv.fr parent=`expr X$zone : '^[^.]*.\(.*\)'` Should it be parent=`expr X$parent : '^[^.]*.\(.*\)'` ? Yes. The logic to find a parent isn't hard. -- 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] Dumb question: why is it that some registries limit the nameservers that can be delegated to?
Rubens Kuhl rube...@nic.br wrote: It was curious to see that a to-be-unnamed TLD registry, a newcomer to the scene many years after the holy wars that ended up defining the current RFCs, writing completely new code, mentioned that they found attributes to be a better option, but decided to go with host objects due to registrar support. This doesn't prove which way is better, but for me it indicates that the role in the value chain can play a part in which option is preferred. Nominet is another example along those lines: alongside the .uk namespace change they have switched to a more standard EPP implementation. http://registrars.nominet.org.uk/namespace/uk/registration-and-domain-management/registrar-systems/epp http://registrars.nominet.org.uk/content/what-are-differences-between-nominet-epp-and-standard-epp 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] is there a diagnostic tool to obtain delegated ns?
Paul Vixie p...@redbarn.org wrote: res_findzonecut(), inside libbind (now called netresolv), provides an API that does what you don't want (gets the zone's apex NS RRset), but is implemented with logic you could hack to grab the information you do want (the closest ancestor's delegation NS RRset), as it goes by. I don't think that will work: res_findzonecut talks to a recursive server, but to get the delegation NS RRset you need to talk to the authoritative servers for the parent zone. Also res_findzonecut works from the bottom up and stops just below the zone cut. 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] Dumb question: why is it that some registries limit the nameservers that can be delegated to?
It was curious to see that a to-be-unnamed TLD registry, a newcomer to the scene many years after the holy wars that ended up defining the current RFCs, writing completely new code, mentioned that they found attributes to be a better option, but decided to go with host objects due to registrar support. This doesn't prove which way is better, but for me it indicates that the role in the value chain can play a part in which option is preferred. Nominet is another example along those lines: alongside the .uk namespace change they have switched to a more standard EPP implementation. http://registrars.nominet.org.uk/namespace/uk/registration-and-domain-management/registrar-systems/epp http://registrars.nominet.org.uk/content/what-are-differences-between-nominet-epp-and-standard-epp Commonplace is different from standard. Both are standards, and I disagree with their naming of it. 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] Dumb question: why is it that some registries limit the nameservers that can be delegated to?
On Fri, Sep 12, 2014 at 12:46:29PM +0100, Tony Finch d...@dotat.at wrote a message of 27 lines which said: they have switched to a more standard EPP implementation. This is absolutely NOT more standard. EPP allows both models (in other words, you do not have to implement RFC 5732). ___ 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] Dumb question: why is it that some registries limit the nameservers that can be delegated to?
[ Note: I haven't had my morning coffee yet, this post likely rambling / incoherent... ] What ever happened to the let's use the glue as a service address trick? There was some drama about this a number of years ago, but it died down, possibly as bandwidth and DNS became cheaper... I cannot remember all the details, but basically I create a host object (nameserver) named whatever the service I want to serve is -- so, if I have example.com, I register the nameserver as 'www.example.com', with the IP of my webserver, and now most of my lookups are handled simply by the glue. I also run a nameserver on that address, which has records for everything other than www (or whatever) record. There were some issues (other than agility) that my caffeine deprived brain cannot bring to mind, but... W On Fri, Sep 12, 2014 at 8:28 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Fri, Sep 12, 2014 at 12:46:29PM +0100, Tony Finch d...@dotat.at wrote a message of 27 lines which said: they have switched to a more standard EPP implementation. This is absolutely NOT more standard. EPP allows both models (in other words, you do not have to implement RFC 5732). ___ 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 -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ 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] Dumb question: why is it that some registries limit the nameservers that can be delegated to?
Warren Kumari war...@kumari.net wrote: I cannot remember all the details, but basically I create a host object (nameserver) named whatever the service I want to serve is -- so, if I have example.com, I register the nameserver as 'www.example.com', with the IP of my webserver, and now most of my lookups are handled simply by the glue. That shouldn't work. RFC 2181 says you can't promote glue to an answer: Unauthenticated RRs received and cached from the least trustworthy of those groupings, that is data from the additional data section, and data from the authority section of a non-authoritative answer, should not be cached in such a way that they would ever be returned as answers to a received query. They may be returned as additional information where appropriate. Ignoring this would allow the trustworthiness of relatively untrustworthy data to be increased without cause or excuse. 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
