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

Wayne MacLaurin Wayne at demandmedia.com
Fri Jan 10 01:01:29 UTC 2014


Hi folks.. I posted a longer reply on Domainincite but basically, if we are going to accept that returning something other than NXDOMAIN is ok, why don’t we just make it useful  and avoid the Internet sleuthing for the true meaning of 127.0.53.53?

Get ICANN to host a nice informative website and point the IPs there.. If its not a human, its not going to work anyway.  If it is a human, then we have ICANN’s backing as to the how and why and what can be done to fix the problem.

Wayne
On Jan 9, 2014, at 4:25 PM, David Conrad <drc at virtualized.org> wrote:

> Joe,
>
> On Jan 9, 2014, at 1:20 PM, Joe Abley <jabley at hopcount.ca> wrote:
>>> To an engineer, 127.0.53.53 is unusual enough to alert them as well as not send them chasing down non-problems.
>> A correct host implementation will not send datagrams to the network with a source or destination address within 127/8 [RFC1700] or ::1/128 [RFC 4291].
>
> Yep.
>
>> However, it's not obvious what implementations do in real life. RFC3330 comments that the IPv4 loopback address is "ordinarily implemented using only 127.0.0.1/32", for example.
>
> I'm told Linux implements loopback as 127/8, but don't have one handy to test myself.
> MacOSX appears to time out going to anything in 127/8 other than 127.0.0.1
> FreeBSD 8.2 and 9.1 says "sendto: can't assign requested address"
>
>> 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.
>
>> So, the specification suggests that for IPv6 there's only one address to play with, ::1/128.
>
> Yep.
>
>> 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?
>
>> What is the expected analogue to 127.0.53.53 for IPv6,
>
> Doesn't explicitly exist (of course). As mentioned, the intent is to hopefully provide a bit of help to folks who are unaware of the situation and who are trying to track down the problem. Personally I'd think for the purposes of this effort, we could squat on ::53 given the small likelihood that 0::0/122 will be allocated in the foreseeable future, but I can see that this position might be ... controversial (:)).
>
>> 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?
>
>> [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?
>
>> 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?
>
> Thanks,
> -drc
>
> _______________________________________________
> Collisions mailing list
> Collisions at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/collisions


Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Demand Media, Inc. Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful.  If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.


More information about the Collisions mailing list