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

[Francisco Obispo]

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 <fmartin at linkedin.com> wrote:
> 
> 
>> On Sep 12, 2014, at 1:27 AM, Paul Vixie <paul at 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 at 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