[dns-operations] gTLD controlled interruption for fun and profit

[David Conrad]

Hi,

On Apr 30, 2017, 5:05 AM -0400, Jim Reid <jim at rfc1035.com>, wrote:
> > On 29 Apr 2017, at 19:27, Warren Kumari <warren at kumari.net> wrote:
> > I personally believe that name collisions have to potential to cause real issues,

Define "real".

> I thought so too Warren. But so far there’s been no sign of those real issues actually happening.

I believe ICANN received 37 reports of problems with name collisions, all of which (to my knowledge) were dealt with by putting the impacted party together with the registry in which the name collision occurred.

Some quick searches show there are also reports like:

https://www.reddit.com/r/sysadmin/comments/36k36v/cisco_name_collision_fyi/
https://serverfault.com/questions/626612/dns-just-started-resolving-my-server-prod-addresses-to-127-0-53-53
http://stackoverflow.com/questions/25662590/domain-foo-bar-points-127-0-53-53-why/25665936
etc.

that do not appear to have reached ICANN directly.

> That could well change of course if .home, .corp, .mail, etc ever got delegated.

Name collision is, of course, NOT limited to top-level domains.

> Has anyone documented an actual instance of a name collision event or problem with any of the recently created gTLDs?
>
> I alo wonder if anyone has found a collision and reported it to ICANN after they'd stumbled across this controlled interruption tripwire.

As above.

> > but that the way that ICANN chose to "mitigate" them (the
> > above) is entirely inadequate / basically a no-op.
> It’s almost certainly a no-op.

Not really. It appears to have done precisely as intended in the cases mentioned above.

> > Controlled interruption might not be working (for some definition of working) because nothing is triggering a noticeable collision event.

Controlled interruption was never intended to prevent collisions, rather it was to provide bread crumbs for folks who encountered difficulties to help them find where they were leaking queries so they could fix those leaks. It is, of course, impossible to know how well it worked (or not) since it's likely most system administrators who ran into the problem went and fixed it without bothering to tell anyone.

Regards,
-drc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20170501/8eb9bd2e/attachment.html>