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

[Warren Kumari]

On Thu, Jan 9, 2014 at 8:01 PM, Wayne MacLaurin <Wayne at demandmedia.com> wrote:
> 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.


Yup, that was part of the original proposal (and personally what I
like the most) -- a web page that says:
"Whoops, you probably didn't intend to get here -- hare are a bunch of
resources to explain the issue."
Same thing can be implemented for a whole heap-o-other protocols, like
SMTP, Telnet/SSH, etc (I made a list somewhere).

Apart from providing feedback to the user this also allows *much*
better monitoring of the issue -- serving a A record gives you no real
visibility into who is actually affected (just their NS) -- having the
client connect gives you way more information about who and number.

The big bugaboo here is what happens with the data -- but presumably
ICANN could have a reasonable privacy policy...

W





>
> 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.
> _______________________________________________
> Collisions mailing list
> Collisions at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/collisions