Unable to resolve hosts supplied by local DNS server

Question

Level 1

0 points

Unable to resolve hosts supplied by local DNS server

I have run into a very annoying DNS problem in our company:

We have a pfSense box providing DHCP and DNS to the client macbooks. The DNS server hands out the ip addresses of local machines, so that users that connect can be reached by their hostname (i.e. "ping jwoelper" (my machine) should work).

It turns out that many hosts do not resolve. The problematic thing is: it is very hard to diagnose. Take for instance this:

(the DNS server has a manual mapping of 192.168.1.66 to "server")

on any linux or windows box, "ping server" works and resolves to 192.168.1.66.

On Yosemite, ping server replies with "ping: cannot resolve server: Unknown host".

Now the really strange thing:

When I run dig server

<<>> DiG 9.8.3-P1 <<>> server
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54680
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0


;; QUESTION SECTION:
;server. IN A


;; ANSWER SECTION:
server. 3600 IN A 192.168.1.66


;; Query time: 3 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Tue Jan  6 11:01:32 2015
;; MSG SIZE  rcvd: 40

dig correctly resolves "server" to 192.168.1.66.

When i run nslookup server it resolves correctly, too:

Server: 192.168.1.1
Address: 192.168.1.1#53

Name: server
Address: 192.168.1.66

If I append a dot to the hostname, ping does work:

ping server.

PING server (192.168.1.66): 56 data bytes
64 bytes from 192.168.1.66: icmp_seq=0 ttl=64 time=2.592 ms
64 bytes from 192.168.1.66: icmp_seq=1 ttl=64 time=1.611 ms

Before you ask: This happens on all macbooks (about 10) in all sorts of configurations. Windows and Linux DHCP clients resolve these hostnames just fine.

Needless to say, pointing a browser to "http://server" does not work. "http://server." does.

my /etc/hosts file is untouched:

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1       localhost
255.255.255.255 broadcasthost
::1             localhost

my resolv.conf, as passed to the client by my DHCP server (192.168.1.1 is DNS and DHCP server)

#
# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.
#
# This file is automatically generated.
#
domain mydomain
nameserver 192.168.1.1
nameserver 8.8.4.4

It would be great if somebody could shed some light on this. The most annoying thing is that OSX does not handle DNS consistently. This makes administrating it very hard if standard diagnose tools (dig, nslookup) can not be relied on.

Thanks in advance everyone!

MacBook Pro with Retina display, OS X Yosemite (10.10.1), null

Posted on Jan 6, 2015 2:25 AM

Reply

Answer 1

Linc Davis

Level 10

209,535 points

Jan 6, 2015 9:34 PM in response to jwoelper

An FQDN should consist of a host name and at least a one-level domain name, such as "server.example.com". If you add the domain "example.com" to the search path in the Network preference pane, you should be able to address the host as "server".

Reply

Answer 2

jwoelper Author

Level 1

0 points

Jan 7, 2015 2:23 AM in response to Linc Davis

While this is true generally, it does not answer why nslookup and dig both work and ping does not. Further, how could it be that all unix/linux/windows/android hosts on the same network resolve the not-FQDN "server" just fine, but OSX does not? (iOS devices with 8.1.2 also can not resolve the host)

Additionally, adding the domain in the search domains pane does not change anything. I am also not able to ping the FQDN like server.example.com. Strangely enough, some hosts resolve just fine, but some do not. I am just out of options to diagnose this, since the standard tools like dig, nslookup and ping offer contradicting results.

I have just tested this on mountain lion, and it works (i.e. ping server is consistent with dig server and nslookup server).

Reply

Answer 3

Linc Davis

Level 10

209,535 points

Jan 7, 2015 6:44 AM in response to jwoelper

I'm not sure what you want me to say. Your question would be better addressed to Apple Engineering. Good luck.

Reply

Answer 4

Dk03

Level 1

9 points

Jan 12, 2015 8:36 AM in response to jwoelper

In short, Its likely due to .local or improper tld domain being used in Apple OS services

You may try setup the network setting in the client for search domain to "yourdomain.local"

Setting it in dhcp router directly will be easier since it will propagate down

For pfsense, simply go to dhcp server setting and set your local domain name and it will issue to client in future.

To avoid any more issue restart the client system to test.

Reply

Answer 5

jwoelper Author

Level 1

0 points

Jan 14, 2015 3:16 AM in response to Dk03

Thank you a lot for your reply!

As stated above, I had entered my domain as search domain in pfSense, and they propagate to the client (/etc/resolv.conf at least shows search mydomain).

Aside from that, literally putting "local" there is discouraged by pfSense with the advice "Do not use 'local' as a domain name. It will cause local hosts running mDNS (avahi, bonjour, etc.) to be unable to resolve local hosts not running mDNS. e.g. mycorp.com, home, office, private, etc."

I drilled down a bit because self-registered hosts (dhcp clients that propagate their hostname) worked, but manually created hosts could not be pinged.

I discovered an option to specify a domain for those, too, so once those were specifically set to the value set in search domain, they resolved as well.

So by now, it works as it should, so thanks to everybody. Why OSX produces different outputs using ping and dig still remains a mystery to me.

Reply

Answer 6

Alex.hg

Level 1

4 points

Apr 4, 2017 1:09 AM in response to jwoelper

i have further found that while host.windowsdomain doesn't resolve, where dig host.windowsdomain. does resolve, that using host.local seems to work in the browsers...

Reply