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

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

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 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?


  • Good question. I never heard of that before. – TomTom Mar 9 '10 at 15:32
  • I have even a "loopback" in my ISPs zone file. WTF? – David Tonhofer Aug 25 '14 at 10:08

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 and potentially do all sorts of nasty things. Probably a good enough reason to get rid of the entry.

| improve this answer | |
  • 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 1 '15 at 22:26
  • See 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 6 '16 at 9:43
  • @BillThor The comments on this other answer 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

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 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.

| improve this answer | |
  • 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 9 '10 at 16:14
  • do you mean there should be an entry like this in the zone for example.com: localhost. 86400 IN A ; note the period – matthew Mar 9 '10 at 16:18
  • 3
    4.1 of 1912 is actually quite explicit on it: ietf.org/rfc/rfc1912.txt – Maximus Minimus Mar 9 '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 8 '15 at 21:06

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

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

| improve this answer | |
  • 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 9 '10 at 15:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.