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

[Franck Martin]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20140913/592ad2aa/attachment.sig>