[Collisions] "controlled interruption" - 127/8 versus RFC1918 space

[Warren Kumari]

On Mon, Jan 13, 2014 at 9:26 AM, Jim Reid <jim at rfc1035.com> wrote:
> On 10 Jan 2014, at 21:08, Jeff Schmidt <jschmidt at jasadvisors.com> wrote:
>
>>> Pointing them at an address in 127/8 or some (presumably ICANN run)
>>> thing which says "you've come here because
>>> of a gTLD collision" is not going to have a happy ending.
>>
>> Please elaborate.
>
> Hi Jeff. I think you might have missed the point. Or maybe I didn't make it clearly enough.
>
> Consider a resolver search list like "foo.bar foo.bar.com". [For the purposes of this discussion, "bar" is one of the new gTLD strings.] The edge device looks up burble and gets an NXDOMAIN. It now looks up burble.foo.bar. That gets an NXDOMAIN too. FWIW some stub resolvers will try to resolve burble.bar and/or burble.com at some point in this process and hopefully these would get NXDOMAIN responses as well. Eventually the stub looks up burble.foo.bar.com which resolves. The user gets access to cute pictures of kittens and much rejoicing takes place.
>
> Suppose someone stands up a web server (or whatever) at foo.bar or maybe burble.bar as part of some collision detection/risk mitigation effort. Once that happens the edge device *doesn't* get an NXDOMAIN for a lookup of burble.foo.bar or burble.bar amy more because these names now resolve. So they get taken somewhere they didn't want to reach and didn't care about instead of reaching the pictures of kittens at burble.foo.bar.com. Much unhappiness ensues. This would happen anyway of course if foo.bar (say) went live for real instead of as a risk mitigation crash test dummy.

Yes. Having the risk be clear and obvious up front, and mitigated by
someone who is (in theory) working for the good of the Internet is
preferable to having various bits break as the SLDs get registered....

>
> The issue here isn't potential leakage from the edge device. It's denial of service. That will almost certainly affect things which are far more important than web sites with kitten pictures.

Sorry, but no -- *nothing* is more important that web sites with
kitten pictures.... :-P


>
> Now it's all well and good to tell the end user or sysadmin it serves them right for doing Stupid Resolver Things and they should stop that. I have a fair bit of sympathy for that PoV.
>
> However it won't be that straightforward. Who foots the bill for explaining that and doing the followup support and hand-holding. Who pays for testing and deploying the fix(es)? Who meets the costs of covering the consequential losses caused by the disruption? Who has liability? ie Because of something the risk mitigator did, someone else lost business because they no longer got access to the kitten pictures.

Yup. I should point out that it is not the risk mitigation here -- it
is the change to an existing, working, deployed system -- the risk
mitigation part is here to try and reduce the risk of the change...

> Or their helpdesk went into meltdown as zillions of customers complain about getting some weird message about name collisions instead of their usual kitten pictures. From their perspective, somebody else changed something that caused them breakage. I understand that in the US this tends to result in lawsuits. YMMV.


Yup, exactly -- *someone changed something*. I believe that it is the
responsibility of the organization who made the change (ICANN) to foot
the bill. They can recover this from the folk they are making the
changes for if they like...

>
> I would be particularly wary about doing this for gTLD strings like sap, mail and oracle which are highly likely to figure in domain names and resolver search configurations that get used for important stuff in corporate networks.

And those are exactly the ones that I think it is most important to do
this for. The alternative is that you wait till some time in the
future when someone registers burble.bar and a: the NXD behavior
changes and / or b: the registrant for burble.bar starts collecting
your oracle credentials / SQL updates....

W


> _______________________________________________
> Collisions mailing list
> Collisions at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/collisions