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

[Joe Abley]

Hi there,

On 2014-01-09, at 19:25, David Conrad <drc at virtualized.org> wrote:

> On Jan 9, 2014, at 1:20 PM, Joe Abley <jabley at hopcount.ca> wrote:
> 
>> The goal of the work that triggered this thread is to keep traffic triggered by the disappearance of NXDOMAIN responses for QNAMEs subordinate (or identical) to new gTLDs local, ideally on the same host that originated them, to avoid mysterious service failures or information leakage.
> 
> Err, not really. The goal is to interrupt service so people will notice and fix it, along the lines of registrations being dropped. Keeping traffic local and avoiding information leakage are side benefits. The choice of 127.0.53.53 was just to maybe provide an additional bit of information to folks who look at the log files on the machines that all of a sudden stopped working the way they used to (assumes the address connections are being attempted to are logged) and reduce the risk that there is actually a listener for a future connection attempt at 127.0.0.1.

OK.

>> What studies exist to confirm that (say) 127.0.53.53 won't attract network traffic from a host?
> 
> Sorry, don't understand the question -- unsure what 'attract network traffic' means. Do you mean whether anyone has looked to see if hosts will accept traffic off the wire at (say) 127.0.53.53?

The other way round -- what hosts, when presented with a destination address of 127.0.53.53, might send traffic to the network, despite the requirements of RFC 1700?

I would hope the answer is "none". But I have seen strange things in the world.

>> and what studies exist for how that traffic might be treated by a variety of hosts?
> 
> Just to clarify, the assumption is a scenario like:
> 
> - Application (probably through a resolver) sends an A query to newly delegated "mumble.abley".
> - Name server for mumble.abley returns 127.0.53.53
> - Application attempts to open a connection to 127.0.53.53
> - Connection attempt fails, logging "connection attempt to 'mumble.abley' (127.0.53.53) didn't return NXDOMAIN: launch the missiles!"
> - In the radioactive wasteland that remains, archeologists uncover the machine and look at the log file, notice 127.0.53.53 and say "Eureka! That's what happened! Damn you DNS search path!"
> 
> Now, with that assumption, what traffic are you talking about?  The connection attempt by the application to 127.0.53.53?

Yeah. So, this proposal is identical to the normal state of things in many respects, but it attempts to trigger local traffic rather than (potentially) traffic across the Internet in the event that an internal name starts to exist in the public namespace.

>> [I like the out-of-boxness of the thinking that triggered all of this, but I don't see it going anywhere. Quite aside from the legal-economic difficulties in rebuilding the new gTLD aircraft in flight alluded to earlier,
> 
> Err, what legal-economic difficulties?

The idea of changing the requirements for the root zone partners or new gTLD registry operators in how they perform a delegation, e.g. for registry operators who have already passed pre-delegation testing and are perhaps already running some new gTLD registries in production. It was a reference to an earlier note to this list.

>> I think the ideas here involve unproved assumptions (e.g. wrt 127.0.53.53), are IPv4-centric and are likely to lead to more headaches than they solve.]
> 
> Could you be explicit in the headaches you see?

It seems like a lot of work for lawyers and developers, it has the small chance of causing unexpected side-effects due to the way the slightly unusual address chosen, it's IPv4-centric, it ignores the impact on protocols that are looking for resources other than A and MX and the benefit is only realised by end-users who read their logs (who, I might suggest, are probably capable of figuring this stuff out anyway, without this proposed modification to the delegation process).

I realise I'm coming across as very negative about the whole idea. This is not a religious crusade against loopback abuse, and as I mentioned earlier I like the general line of thinking. But I don't think the benefits of this approach outweigh the costs.


Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.dns-oarc.net/pipermail/collisions/attachments/20140110/3c6a5c2b/attachment.pgp>