14 Replies Latest reply: Aug 8, 2006 3:09 PM by mebs2
mebs2 Level 1 Level 1 (15 points)
Here's the deal, I can resolve the hostname/IP both forward and reverse for a server on a local network. I can also ping the IP address. I can't ping the hostname.

This is true for any machine on the LAN, including the server in question. Super weird.

This leads me to believe DNS is OK. So where's the problem???

The only change has been replacing a dead router that is the DHCP server. All the clients look OK to me and the server has a hard coded IP so this shouldn't matter.

Any suggestions welcome!



Many Macs - So Much Fun!   Mac OS X (10.4.7)  
  • R.Cerny Level 4 Level 4 (1,170 points)
    To test DNS use dig command.

    man dig
  • mebs2 Level 1 Level 1 (15 points)
    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
  • R.Cerny Level 4 Level 4 (1,170 points)
    you cannot resolve the server's name from client, right? Is DNS field in Network pane correctly set? Is firewall port 53 open on server?
  • mebs2 Level 1 Level 1 (15 points)
    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.
  • R.Cerny Level 4 Level 4 (1,170 points)
    why did you mask out the real hostname? I still think it is a resolver problem but you can try to clean arp cache.
    man arp
  • mebs2 Level 1 Level 1 (15 points)
    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
  • Camelot Level 8 Level 8 (46,265 points)
    This sounds like something to do with your search domain settings.

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

    If not, whatever hostname you enter will be appended with the search domains, which may affect the result.
  • mebs2 Level 1 Level 1 (15 points)
    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.
  • mebs2 Level 1 Level 1 (15 points)
    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...
  • Camelot Level 8 Level 8 (46,265 points)
    I still lean towards a DNS problem.

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

    ping hostname
    and
    ping hostname.companyname.local

    Also, can you post the output of dig hostname and dig hostname.companyname.com, and maybe the contents of /etc/resolv.conf.
  • mebs2 Level 1 Level 1 (15 points)
    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.
  • Camelot Level 8 Level 8 (46,265 points)
    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:

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

    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.
  • mebs2 Level 1 Level 1 (15 points)
    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.
  • mebs2 Level 1 Level 1 (15 points)
    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.