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

[Jeff Schmidt]

Jim: my apologies, but it was I who wasn't clear!  :-)

One of the things I'm particularly interested in probing is potential
unintended consequences related specifically to returning an IP in
Internet, 1918, or 127/8 space.  Specifically - unintended consequences
apart from the "normal" issues related to collisions if/when things stop
returning NX that have already been discussed and I believe fairly well
understood at a high level.  I thought you were suggesting specific
repercussions of the Internet or 127/8 approach that were "abnormal" in
this context.  For example, we're looking right now at RFC 1700 compliance
in embedded devices to see how safe the assumption is that traffic to
127.0.53.53 won't leave the host.  Using 1918 space could wind-up with
traffic sent to a printer, as Warren (I think) pointed out.  Using an
Internet IP may result in something (application layer) being transmitted
that was never transmitted before.  I'm interested in other potential
gotchas like those specific to the suggestions floating around.  Does that
make more sense?  Sorry I wasn't at all clear!

Thx,
Jeff



On 1/13/14 8: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.
>
>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.
>
>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. 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.
>
>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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4376 bytes
Desc: not available
URL: <http://lists.dns-oarc.net/pipermail/collisions/attachments/20140113/d674c648/attachment.bin>