Returning 127.0.53.53 is potentially dangerous, and my suggestions for an alternative
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.