[dns-operations] Hearing first complains about failing internal resolving due to .prod TLD
fmartin at linkedin.com
Sat Sep 13 09:19:03 UTC 2014
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...
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the dns-operations