4

What's the best practice when creating A records that point to localhost? Is it considered taboo or are there some valid cases where it's permissible?

I have a dozen domains where I setup "local." subdomains that point to 127.0.0.1 to help when locally developing web applications linked to those domains. Myself and other developers on my team often have to work with multiple sites on our localhosts, and referring to IPs in the URL or keeping a local map of domains in your hosts file tends to cause confusion and gets difficult to maintain over time.

So I thought registering these as subdomains would be a quick and easy way to provide shortcuts for everyone. And it did. It worked for a few weeks, then it suddenly stopped working. So I logged into my provider's DNS controls, and sure enough, all the "local." A records had been deleted.

My host is Godaddy.

Before I go nuclear on Godaddy for modifying my DNS records without my permission, is there a legitimate reason why they would have deleted them? Might they have thought it was some sort of security issue or violation? Godaddy's just a terrible company in general, but switching DNS providers isn't a chore that's high on my list. Is this something that I should be legitimately angry about?

PersianGulf
  • 602
  • 8
  • 21
Cerin
  • 3,600
  • 19
  • 61
  • 79

3 Answers3

2

Although maybe a little odd, I don't know of any specific standard or specification that prohibits doing such a thing within public DNS in general. There could possibly be some quirk of the GoDaddy platform that causes some sort of issue when using loopback addresses, or perhaps it was removed just because it's 'non-standard' or 'odd'.

If the machines are all on the same network and don't leave it, then could you perhaps create these records on your internal DNS?

dbr
  • 1,852
  • 3
  • 23
  • 38
1

If I had to take a guess, this is probably a misguided effort to prevent traffic reflection. Take the following example:

$ORIGIN example.com.

stophittingyourself IN NS ns1.stophittingyourself

ns1.stophittingyourself IN A 127.0.0.1

If I were to send a query for noreally.stophittingyourself.example.com. to a recursive DNS server, it would follow the referral chain and attempt to query 127.0.0.1:53. Odds are high that there is in fact a localhost listener and in most cases the net result is the server talking to itself. This would inevitably result in cacheable failure...but every time you change noreally to somethingelse, that failure has to be cached separately per RFC.

The net result is that the 127.0.0.1 referral can be used to waste resources more effectively than pointing at a random IP that either doesn't respond or isn't authoritative. Trying to prevent it at this layer is strange, particularly since it makes more sense for the victim to declare a list of networks that it should not communicate with for authoritative data (including 127.0.0.0/8), but that's never stopped a business from doing silly things in the name of "security" with finger quotes.

Semi-related tangent: if you run a recursive DNS server and have never thought about referrals being used to funnel traffic in this way, you might want to look into how your DNS software can be configured to ignore those referrals. While a firewall can also help here, I promise that the packet counters on your loopback interface will be much quieter if you handle customer traffic.

BIND-based example:

# refuse to loop back on ourself
server 203.0.113.0/24 { bogus yes; };
server 127.0.0.0/8    { bogus yes; };
server 0000::/3       { bogus yes; };
server fe80::/16      { bogus yes; };
server 169.254.0.0/16 { bogus yes; };

# refuse attempts to funnel requests into private/backbone space
server 172.18.53.1/32  { bogus no; }; # whitelisting example
server 172.18.53.2/32  { bogus no; }; # whitelisting example
server 192.168.0.0/16    { bogus yes; };
server 10.0.0.0/8        { bogus yes; };
server 172.16.0.0/12     { bogus yes; };
server 100.64.0.0/10     { bogus yes; };
Andrew B
  • 32,588
  • 12
  • 93
  • 131
0

A-record that points to 127.0.0.1 is a security risk because it makes XSS attacks possible. More info: http://www.securityfocus.com/archive/1/486606/30/0/threaded

Croco
  • 101
  • 1