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

[Petr Špaček]

On 1.5.2017 14:51, David Conrad wrote:
> 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.

There will be certainly more of these. In my previous job QA folks had
hard time when internal test suite started to fail after seemingly no
change in code ... They found out that the tests depended on
non-existence of some name under new gTLD. The fix was easy and nobody
cared to report it.

>From my perspective the wildcard trick is doing exactly what I want -
break setups [which are alredy broken] early and deterministically.

Petr Špaček

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