[dns-operations] Hearing first complains about failing internal resolving due to .prod TLD

[Kim Davies]

On Sep 11, 2014, at 7:40 PM, Andrew Sullivan <ajs at 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