ICANN ICANN Email List Archives

[comments-name-collision-26feb14]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: Returning 127.0.53.53 is potentially dangerous, and my suggestions for an alternative

  • To: "comments-name-collision-26feb14@xxxxxxxxx" <comments-name-collision-26feb14@xxxxxxxxx>
  • Subject: Re: Returning 127.0.53.53 is potentially dangerous, and my suggestions for an alternative
  • From: Jason A Fesler <jfesler@xxxxxxxxxxxxx>
  • Date: Fri, 28 Mar 2014 15:58:16 +0000

Response to Aaron Beck’s 2014 Feb 28 comments on “Mitigating the Risk of DNS 
Namespace Collisions”

I appreciate the analysis and recommendations put forth by JAS Global Analysis 
in the “Mitigating the Risk of DNS Namespace Collisions” phase 1 report.  In 
general, I concur with the findings and recommendations.  

Furthermore, I appreciate the comments from Mr. Aaron Beck, and his analysis of 
the use of 127.0.53.53 on Linux.  I have verified his findings on multiple 
versions of Linux; as well as on Android.  I have found that _any_ subnet 
configured on loopback, makes all IP addresses in that subnet connectable, due 
to this Linux behavior.  Mr. Beck points out the potential for denial of 
service against one’s own host.

As I re-read the phase 1 report, I am reminded of other values considered; 
particularly that of privacy, and around the risks of honeypots.  The report 
outlines several risks with running honeypots in section 2.1.5.

Mr. Beck recommends the use of address space from TEST-NET-2 and TEST-NET-3 
[RFC5737], prefixes specifically allocated for documentation purposes, and 
specifically, SHOULD be filtered.  The risk of using address space from these 
address ranges is that connections to these addresses may leak from the local 
organization; and be sent to an upstream ISP.   In theory, the ISP should 
filter these.  In practice, this may not always happen. BCP38 [RFC2827] is 
still not widely enough deployed.   The same ISP may accept BGP announcements 
for TEST-NET-2 and TEST-NET-3 from malicious actors, whether directly or 
indirectly.  This effectively creates an external honeypot operated by the 
malicious actor.  The phase 1 report outlines several risks with running 
honeypots. 

I value the contribution by Mr. Beck; but must respectfully disagree with his 
recommendations.  I believe the potential for information leakage and remote 
honeypots to far outweight any risk of local denial of service possibly created 
by the use of “127.0.53.53” from Linux/Android hosts.


Jason Fesler
Architect, Yahoo


<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy