All steps to set up and resolve subdomain.localhost to 127.0.0.1?

Question

I suddenly feel stubborn about my subdomain on localhost not working. My /etc/hosts file looks like this:

127.0.0.1   localhost
255.255.255.255 broadcasthost
::1             localhost 
fe80::1%lo0 localhost

127.0.0.1   develop2win.de
127.0.0.1   develop2win.de

127.0.0.1   alomvar.localhost

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

127.0.0.1   localhost alomvar.localhost develop2win.de www.develop2win.de

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:     192.168.178.1
Address:    192.168.178.1#53

** 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 develop2win.de 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:

Server:     192.168.178.1
Address:    192.168.178.1#53

Name:   localhost
Address: 127.0.0.1

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 127.0.0.1

But for the subdomain not:

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

Pinging localhost works fine, too:

$ ping localhost
PING localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.048 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.078 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.085 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.076 ms
^C
--- 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 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.039 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.042 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.075 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.091 ms
^C
--- 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.

Solution

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.

Comments

[dave_thompson_085]

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 developer.apple.com/library/mac/documentation/Darwin/Referen‌​ce/… at "Mac OS X Notice".

[Peter]

Thank you for the hints @dave_thompson_085, I updated my question with the results of host, dig and ping.

[dave_thompson_085]

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.

[user3019105]

I have the same problem 127.0.0.1 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?

[Peter]

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.

[Gordon Davisson]

@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 Utility.app's Lookup tab now uses the system policy (it used to use dig).