Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I suddenly feel stubborn about my subdomain on localhost not working. My /etc/hosts file looks like this:   localhost broadcasthost
::1             localhost 
fe80::1%lo0 localhost   alomvar.localhost

Putting all host names for one IP in one line like this does not work either:   localhost alomvar.localhost

I also restarted the DNS resolver appropriate for OS X 10.9 Mavericks with the following command:

dscacheutil -flushcache; sudo killall -HUP mDNSResponder

But issuing nslookup alomvar.localhost on terminal yields the following:


** server can't find alomvar.localhost: NXDOMAIN

That is the IP of the router in my local network. It appears like the localhost hosts file is skipped for resolution in this case. Before the process was successfully resolved and pointed to a local Apache virtual host. But now not even that works anymore, same error as above (WTF?). However, looking up plain localhost works fine, still:


Name:   localhost

Update 1: I did a reboot, too, without any change. It seems like DNS queries are not resolved locally at all but sent to my router instead.

What am I missing? Did somebody else try to set up a subdomain for localhost on OS X Mavericks? This is not even about Apache, just the DNS thing.

Here is a screenshot of my DNS configuration in system preferences, by the way. Since I do not have enough reputation yet to embed images, this is a link to external site.

Update 2: I performed checks with host and ping commands in terminal, as dave_thompson_085 pointed out. For localhost it works fine:

$ host localhost
localhost has address

But for the subdomain not:

$ host alomvar.localhost
Host alomvar.localhost not found: 3(NXDOMAIN)

Pinging localhost works fine, too:

$ ping localhost
PING localhost ( 56 data bytes
64 bytes from icmp_seq=0 ttl=64 time=0.048 ms
64 bytes from icmp_seq=1 ttl=64 time=0.078 ms
64 bytes from icmp_seq=2 ttl=64 time=0.085 ms
64 bytes from icmp_seq=3 ttl=64 time=0.076 ms
--- localhost ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.048/0.072/0.085/0.014 ms

And now, irritatingly, so it works as well for the subdomain:

$ ping alomvar.localhost
PING alomvar.localhost ( 56 data bytes
64 bytes from icmp_seq=0 ttl=64 time=0.039 ms
64 bytes from icmp_seq=1 ttl=64 time=0.042 ms
64 bytes from icmp_seq=2 ttl=64 time=0.075 ms
64 bytes from icmp_seq=3 ttl=64 time=0.091 ms
--- alomvar.localhost ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.039/0.062/0.091/0.022 ms

How can I ping without problems but not resolve the subdomain? Apparently it should work like this, when I look on how other people did it around the internet. I am not a crack regarding networking. I probably broke something else than what is directly needed to set this up.

I also executed digon localhost and the subdomain. The output is rather long and I think this question is cluttered enough already. See this file for dig output.

Update 3: When disconnecting my Mac from the network (disabling ethernet network adapter) digand host fail looking up localhost, too.

Update 4: I found out that works within browsers to show the Apache virtual host listening to the so named host. It is not a solution to the problem, but a circumstance I can live and work with. However, I am still interested in resolving the issue. If anybody got any further idea, tell me.

share|improve this question
nslookup (and also dig) ONLY talks to DNS servers, it does not use the full DNS-resolver logic like other (real?) programs. Try host to just resolve, or ping to resolve and do only a few harmless packets. While this is true for most if not all Unix, MacOSX emphasises it in… at "Mac OS X Notice". – dave_thompson_085 Jul 10 '14 at 14:01
Thank you for the hints @dave_thompson_085, I updated my question with the results of host, dig and ping. – Alomvar Jul 10 '14 at 14:38
Sorry, I was half wrong: I remembered host as doing normal resolution, but rechecking the man page I see it also does ONLY DNS server(s). Thus nslookup dig host all ignoring the data in your hosts file is as documented, unfortunately. So go with ping. – dave_thompson_085 Jul 10 '14 at 16:32
I have the same problem subdomain.localhost inside /etc/hosts/. subdomain.localhost pings well, however if I open the browser at http://subdomain.localhost, I get a ERR_NAME_NOT_RESOLVED. Did you find a solution? – user3019105 Aug 27 '15 at 17:04

dig, host, and nslookup all bypass the system name resolver, and query DNS directly. Thus, they won't see names defined in /etc/hosts (unless they're also defined in the DNS service), or any mDNS (aka Bonjour) .local names, or Computer entries in directory services, or...

If you want to see what the system resolver sees, the best tool is dscacheutil. Unfortunately, its syntax is rather clumsy (dscacheutil -q host -a name alomvar.localhost), so it's generally quicker to use something like ping that uses the system name resolver. But if you want full details (e.g. whether a name resolves to multiple addresses), dscacheutil is the way to go.

share|improve this answer
Is it still applicable for OS X Mavericks? I checked out the man pages. Performing the query like in your answer returns any output. dscacheutil -statistics states "Unable to get details from the cache node" (same with -cachedump). I am just asking, since as far as I know there were some changes with Mavericks in that matter. – Alomvar Jul 11 '14 at 17:54
@Alomvar yes, this is still true in Mavericks. Apple has changed how name resolution works quite a bit over the history of OS X, but the DNS tools (dig, host, and nslookup) always bypassed the system policy, and dscacheutil has (since its appearance) followed the system policy. Several of dscacheutil's other functions have broken (e.g. dscacheutil -flushcache now requires sudo, and doesn't seem to entirely work even then...), but it still does lookups ok. Oh, one thing did change in Mavericks: Network's Lookup tab now uses the system policy (it used to use dig). – Gordon Davisson Jul 11 '14 at 18:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .