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

[David Conrad]

Franck,

On Sep 13, 2014, at 2:19 AM, Franck Martin <fmartin at linkedin.com> wrote:
> 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.

The source IP is a resolver, not the original querier. I’m guessing Google doesn’t need to be warned :).

> 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.

You might want to look at https://www.jasadvisors.com/namespace-expansion-i.pdf. Interestingly, .prod had only 146 (filtered) unique SLDs in the DITL data. 

This was discussed in the last year or so of ‘discussions’ related to name collision. Trivial to game, difficulties finding the actual source, difficulties in establishing what could be an issue vs. a false positive, etc.

The behavior of returning 127.0.53.53 is specifically intended to interrupt normal behavior in a less damaging way (at least compared to the alternative interruption approaches) so people notice and can go and fix things. See https://www.icann.org/en/system/files/files/name-collision-mitigation-study-06jun14-en.pdf for a longer explanation of the current approach used to deal with name collision.

Regards,
-drc
(ICANN CTO, but speaking only for myself)

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