Can't ping hostname. Can ping IP address. DNS looks OK... What gives?

DNS resolves just fine, both forwards and backwards. Using either dig or Network Utility.

I can ping the IP, but if I ping the hostname i get the message:
ping: cannot resolve hostname: Unknown host

you cannot resolve the server's name from client,
right?

nope - it resolves just fine. I just can't ping.

Is DNS field in Network pane correctly set? Is
firewall port 53 open on server?

Yes the port is open, and DNS seems to be clipping along happily.

To sum up, I CAN resolve, I just can't ping the hostname. That's the weird part. As a result, some other issues have arisen. This server holds user directories that use mcx, and they won't sync, even though I can browse the folders from any given client.

Here's some examples of what's going on:

Example 1: (good)
dig hostname
result:
;; ANSWER SECTION:
hostname. 3600 IN A 192.168.100.99

Example 2: (good)
dig -x 192.168.100.99
;; ANSWER SECTION:
99.100.168.192.in-addr.arpa. 3600 IN PTR hostname.

Example 3:(good)
ping -c 5 192.168.100.99
result:
PING 192.168.100.99 (192.168.100.99): 56 data bytes
64 bytes from 192.168.100.99: icmp_seq=0 ttl=64 time=0.310 ms
64 bytes from 192.168.100.99: icmp_seq=1 ttl=64 time=0.307 ms
64 bytes from 192.168.100.99: icmp_seq=2 ttl=64 time=0.303 ms
64 bytes from 192.168.100.99: icmp_seq=3 ttl=64 time=0.257 ms
64 bytes from 192.168.100.99: icmp_seq=4 ttl=64 time=0.280 ms

--- 192.168.100.99 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.257/0.291/0.310/0.020 ms


Example 4: (BAD!!!)
ping -c 5 hostname
ping: cannot resolve hostname: Unknown host

I tried lookupd -flushcache, to no resolution, but to be honest I'm not convinced it's a DNS issue due to the fact that both forward/reverse lookups resolve correctly.

I left the actual hostname out because it's not relevant to the discussion. I feel that it's better to discuss issues in generalities rather than specifics so that others can then apply the solutions to their own situation later. I prefer it when I read posts/how-tos written that way at least. It's a matter of preference, nothing more.

Back to the issue at hand:

After clearing out the arp cache I issue the following:
arp 192.168.100.99
and it resolves correctly, with the correct ethernet id

however,
arp hostname
results in arp: hostname: Unknown host

(using arp for any other machine works fine - both forwards and backwards)

also,
arp -a
results in a correct listing of a bunch of the machines on the local network. But at the end there is the entry:
? (192.168.100.255) at ff:ff:ff:ff:ff:ff on en0 [ethernet]

is this normal? i haven't had need to use arp in the past.

Thanks for the suggestions thus far. Hopefully we can get this resolved!

update: that entry at the end no longer appears

further to the discussion, if I use finder to browse the network the server appears without an issue. I can also connect to the shared Users folder no problem and browse my network home directory. Home Sync doesn't work, and I can't ping the server.

Message was edited by: mebs2

Are you using a fully qualified domain name in your
ping?

yes the format is (and always has been) in the form hostname.companyname.local for the local network. THis format has worked for a number of months without any issues.

I think you might be on to somthing though - as I can't ping any machines in the local domain using their FQDN. I CAN ping any machine using its IP address... and I can resolveany machine both forwards and backwards.

Would this be an issue with the Open Directory settings?

THe server is an open directory master. Search base is: dc=hostname,dc=companyname,dc=local
Database: /var/db/openldap/openldap-data

I don't think this has ever been modified since the initial setup.

I just ran the changeip tool to make sure nothing was messed up with my naming and it looks OK:

------------------------------------------------
sudo changeip -checkhostname
Password:

Primary address = 192.168.100.99

Current HostName = hostname.companyname.local
DNS HostName = hostname.companyname.local

The names match. There is nothing to change.

------------------------------------------------

soooo... i think DNS isn't the culprit. I'm leaning towards Open Directory problems...

I still lean towards a DNS problem.

To validate that theory, do you get a difference
between:

ping hostname
and

ping: cannot resolve hostname: Unknown host

ping
hostname.companyname.local

ping: cannot resolve hostname.companyname.local: Unknown host

Also, can you post the output of dig hostname

no result

and dig hostname.companyname.local,

this one works:
;; QUESTION SECTION:
; hostname.companyname.local. IN A

;; ANSWER SECTION:
hostname.companyname.local. 3600 IN A 192.168.100.99

;; AUTHORITY SECTION:
hostname.companyname. 3600 IN NS hostname.companyname.local.

and maybe the contents of /etc/resolv.conf.

nameserver 192.168.100.99


Hopefully this gives some insight into the problem.

OK, that does help

Whether or not it's the root of the problem remains
to be seen, but there are at least two things wrong
with your DNS.

First you should add 'companyname.local' to your
search domains. That way if a search for 'hostname'
fails the resolver will automatically try
'hostname.companyname.local'.
You can do this either through Network preferences ->
TCP/IP -> Search domains, or by appending the line:

THIS IS THE SOLUTION! Thanks! I have it all solved now.

search
companyname.local

to /etc/resolv.conf.

The other issue is likely to be the real culprit,
which is an error in your zone file.

The dig output states:

;; AUTHORITY SECTION:
hostname.companyname. 3600 IN NS
hostname.companyname.local.

Which essentially says the server is authoritative
for hostname.companyname., not
hostname.companyname.local.

This indicates an extraneous trailing period in your
zone file (unless that was just an editing error
during obfuscation which is why using real output is
sometimes better).

Touche - it was just a typo during obfuscation. Point taken. The zone file was OK (which was what had me pulling my hair out - I was positive this was the issue).

So the next step is to check your zone file,
specifically the authority and NS sections to verify
it's correct. If you need help with that and don't
want to post your zone file online you can email it
to me at camelot@mac.com .

Here's the full story and the reason why everything fell apart on us.

Our old router died. This router did not act as (much of) a firewall or provide DHCP services. We used our local file server, running OS X Tiger Server software, to provide these services.

When the newer, fancier router was purchased I decided to use its built in DHCP server and firewall.

The unexpected result is what resulted in this post. Long story short, the OS X server supplied the necessary info that the hardware router did not - specifically the search domains for OS X clients. Additionally, this also messed up the lone Windows XP machine that could not find the WINS server any more.

Thanks to everyone who pitched in to help find the solution! Your time is greatly appreciated.