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

[Aaron Beck <A.Beck@xxxxxx>]

Greetings!

Many Linux systems will respond to requests made of the 127.0.53.53 address, 
and in general any packet addressed within 127.0.0.0/8 unless specifically 
configured otherwise.  I've include an example from an Ubuntu 12.04 machine:

ab@phrygian:~$ ping -c 1 127.0.53.53
PING 127.0.53.53 (127.0.53.53) 56(84) bytes of data.
64 bytes from 127.0.53.53: icmp_req=1 ttl=64 time=0.031 ms

--- 127.0.53.53 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.031/0.031/0.031/0.000 ms


This may present a denial of service vector wherein these "friendly" looking 
gTLDs could inadvertently lead someone to direct traffic to many sensitive 
daemons.  This could also present opportunities to traverse tunneled services 
over a VPN or tethered connection that would otherwise not be available, where 
both technologies often make use of the 127.0.0.0/8 address space and may 
assign 127.0.53.53 to something listening.

To avoid the above DoS vectors, I suggest looking at returning an address from 
the TEST-NET2 or TEST-NET3 ranges, as defined by RFC 5737.   I believe that an 
address from TEST-NET in RFC 1166 is likely to conflict with the most existing 
documentation.  In light of that and alongside inspiration from 127.0.53.53, I 
quote two sections from RFC 5737 as my basis for a recommendation of the 
address 198.51.100.53:

"

1<http://tools.ietf.org/html/rfc5737#section-1>.  Introduction


   This document describes three IPv4 address blocks that are provided
   for use in documentation.  The use of designated address ranges for
   documentation and examples reduces the likelihood of conflicts and
   confusion arising from the use of addresses assigned for some other
   purpose.


   [RFC1166] reserves the first of the three address blocks,
   192.0.2.0/24.  The other two address blocks have recently been
   allocated for this purpose, primarily to ease the writing of examples
   involving addresses from multiple networks.

"


"
      Addresses within the TEST-NET-1, TEST-NET-2, and TEST-NET-3 blocks

   SHOULD NOT appear on the public Internet and are used without any
   coordination with IANA or an Internet registry 
[RFC2050<http://tools.ietf.org/html/rfc2050>].  Network
   operators SHOULD add these address blocks to the list of non-
   routeable address spaces, and if packet filters are deployed, then
   this address block SHOULD be added to packet filters.

   These blocks are not for local use, and the filters may be used in
   both local and public contexts.


"


I believe the future from RFC 6890 could be considered now.  Therefore, another 
approach may be an assignment from the 240.0.0.0/4 address space.  240.0.0.53 
is my recommendation from this space, so that only the first /26 of is 
"tainted" by actual assignment.

Thanks for listening,  Aaron Beck.