19

Our ISP also hosts our external DNS. By default they include an entry for localhost.

For example: localhost.example.com. 86400 IN A 127.0.0.1

When I've asked them to remove it they give me a hard time and say that it's just the way Bind works.

I've tried to do some research on why I might want to have that included but I couldn't find much. I did find at least one place that thought it be a possible XSS attack vector. It does appear to be fairly common so I did lookups on the top 20 website domains from alexa and most don't have such an entry but a couple do. A few others have an entry but instead of pointing to 127.0.0.1 they point to another a world route-able IP address.

So anyway, why would I want to have locahost in the zone for my domain? Are their any issues with not having it? Is there any kind of best practice concerning this? Is it indeed a default Bind thing that I'm not aware of?

Thanks

matthew
  • 1,309
  • 1
  • 11
  • 21

3 Answers3

15

localhost.example.com is sometimes included on internal DNS servers to prevent "localhost" requests leaking out to the internet (for the case where John Smith types http://localhost/ in his browser & for whatever reason his resolver doesn't look in the hosts file, appends his search path (example.com) & starts asking name servers what that resolves to).

You don't have to have a localhost entry (and if your ISP thinks that's "the way BIND works" they're either misguided or idiots: BIND serves what's in the zone file, and if they remove the localhost line it will stop serving that record). As a free example, localhost.google.com doesn't resolve, and I bet the NS for that domain is running BIND.

The XSS vector is something I'd never thought of, but it is something of concern: having a localhost entry in your public DNS means any hacked machine could be "in your domain" (by running a webserver on 127.0.0.1) and potentially do all sorts of nasty things. Probably a good enough reason to get rid of the entry.

voretaq7
  • 79,345
  • 17
  • 128
  • 213
  • 1
    Personally I'd think that `localhost.some.test` is just another victim of **not** getting proper dot ending. The reasoning behind having `localhost.` (note the dot!) is clear, but dots are often forgotten in DNS zones. Then it sprung to have its own mysterious life. – poige Oct 01 '15 at 22:26
  • See https://tools.ietf.org/html/rfc1537 Common DNS Data File Configuration Errors which suggest that the localhost entry is correct. – BillThor Apr 28 '16 at 21:46
  • 1
    No, rfc1537 does not specifiy that. It specifies that recursors need to have a localhost. zone and a zone for the reverse. Nowhere does it say your zones need a localhost entry. – Habbie Jun 06 '16 at 09:43
  • @BillThor [The comments on this other answer](http://serverfault.com/a/120784/32986) are relevant to RFC 1537 and its successor (RFC 1912) - As Habbie mentioned the *zone* `localhost.` is something we're supposed to have, but the practice of having a `localhost` *record* in each zone we serve has fallen out of favor. (This question actually lead me down that RFC rabbit hole 5 years ago, maybe I'll update my answer with the new RFC & thoughts from that comment thread later :)) – voretaq7 Jun 20 '16 at 20:42
4

Assuming that your internal name resolution is handling name resolution properly, any DNS request for localhost should never go to your external DNS provider, and so this shouldn't be a problem at all.

One reason why someone would do this, that I can think of off the top of my head, is if someone once used a web authoring tool that screwed up with a load of absolute references to http://localhost, but that assumes that your ISP was also hosting on their DNS boxes and is a long shot.

However, RFC 1537 does specify:

There has been extensive discussion about whether or not to append the local domain to it. The conclusion was that "localhost." would be the best solution; reasons given were:

  • "localhost" itself is used and expected to work on some systems.

  • translating 127.0.0.1 into "localhost.my_domain" can cause some software to connect to itself using the loopback interface when it didn't want to.

Note that all domains that contain hosts should have a "localhost" A record in them.

So strictly speaking it appears as though your ISP is correct to include localhost, but incorrect to use the fully-qualified name.

Community
  • 1
Maximus Minimus
  • 8,937
  • 1
  • 22
  • 36
  • 5
    Looks like RFC-1537 was obsoleted by RFC-1912 which deletes the `Note that ...` language (I'd guess in response to the potential XSS issues which we would have started to be aware of in 1996 :) 1537 Explains why it's in the BIND templates though. – voretaq7 Mar 09 '10 at 16:14
  • do you mean there should be an entry like this in the zone for example.com: localhost. 86400 IN A 127.0.0.1 ; note the period – matthew Mar 09 '10 at 16:18
  • 3
    4.1 of 1912 is actually quite explicit on it: http://www.ietf.org/rfc/rfc1912.txt – Maximus Minimus Mar 09 '10 at 16:23
  • 5 years on but worth clarifying: 4.1 of RFC 1912 is explicit that the `localhost` ***zone*** should exist on the server (so if it gets a request just plain "localhost" it doesn't pass it up the chain to the next server), that's a far cry from including `localhost` in say `example.com`'s zone (creating `localhost.example.com`), which it is equally explicit in saying you should *not* do because of possible unintended side effects. The expectation is for "localhost" to be a special, magical, fully-qualified domain in its own right. – voretaq7 Sep 08 '15 at 21:06
0

I'm not sure what the point would be...By default, the external address would be over-ridden by the hosts file, which nearly always maps localhost to 127.0.0.1.

A default BIND zone file does include a localhost zone, though. Never really thought about it.

Satanicpuppy
  • 5,917
  • 1
  • 16
  • 18
  • This is not the localhost zone (unless its a mis-configuration of that zone). It's also not the fqdn 'localhost.' and would not generally be over-ridden by the local hosts file. – matthew Mar 09 '10 at 15:48