nslookup finds ip for a hostname in .local domain, but ping does not

I know this looks like all the other "can ping via ip but not dns" questions, but those didnt really help me at all.

Also, having hosts files in all machines is not doable as this server will eventually handle a lot of computers connecting to it.

I have a ldap+dns server set, and I want the computers on my network to authenticate on the ldap server.

The ldap part of it is working just fine and I can ssh into the ldap server with the ldap credentials just fine.

The problem comes with the client machines, the client is set to use the dns server (in this case 192.168.0.243) and if I get in the terminal and do a nslookup it finds the ldap server just fine.

fernando@desktest:~$ nslookup ldap.mynet.local
Server:     192.168.0.243
Address:    192.168.0.243#53

Name:   ldap.mynet.local
Address: 192.168.0.243

But when I ping it, it doesn't find the ip address. It just hangs there looking pretty till I CTRL-C it.

Of course pinging by ip address works just fine.

Here are the zone files for the dns server:

fernando@ldap:~$ cat /etc/bind/named.conf.local
zone "mynet.local" {
    type master;
    file "/etc/bind/db.mynet.local";
};

zone "0.168.192.in-addr.arpa" {
    type master;
    notify no;
    file "/etc/bind/db.192";
};
fernando@ldap:~$ cat /etc/bind/db.mynet.local 
;
; BIND data file for local loopback interface
;
$TTL    604800
@   IN  SOA ns.mynet.local. root.mynet.local. (
                  7     ; Serial
             604800     ; Refresh
              86400     ; Retry
            2419200     ; Expire
         604800 )   ; Negative Cache TTL
;
@   IN  NS  ns.mynet.local.
ns  IN  A   192.168.0.243
server  IN  A   192.168.0.250
desktest    IN  A   192.168.0.249
remote  IN  A   192.168.0.248
winserver   IN  A   192.168.0.247
web         IN  A   192.168.0.246
tempfs  IN  A   192.168.0.245
ldap    IN  A   192.168.0.243
antenarfb   IN  A   192.168.0.253
antenapan   IN  A   10.82.223.7
adslgvt IN  A   192.168.0.1
fernando@ldap:~$ cat /etc/bind/db.192 
;
; BIND reverse data file for local loopback interface
;
$TTL    604800
@   IN  SOA mynet.local. root.mynet.local. (
                  6     ; Serial
             604800     ; Refresh
              86400     ; Retry
            2419200     ; Expire
             604800 )   ; Negative Cache TTL
;
@   IN  NS  ns.
1   IN  PTR ns.mynet.local.
2   IN  PTR server.mynet.local.
3   IN  PTR desktest.mynet.local.
4   IN  PTR remote.mynet.local.
5   IN  PTR winserver.mynet.local.
6   IN  PTR web.mynet.local.
7   IN  PTR tempfs.mynet.local.
8   IN  PTR ldap.mynet.local.
9   IN  PTR antenarfb.mynet.local.
10  IN  PTR antenapan.mynet.local.
11  IN  PTR adslgvt.mynet.local.
fernando@ldap:~$ 

I am really at a loss about what to do and any help will be greatly appreciated.

---- edit ----

before anybody asks, yes the server is running :)

root@ldap:/etc/bind# rndc status
version: 9.7.0-P1
CPUs found: 1
worker threads: 1
number of zones: 16
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running

---- end edit ----


I believe this is caused by mdns - multicast dns, for autoconfiguration of the .local domain.

If you check in /etc/nsswitch.conf, you will probably see:

hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4

mdns4 is what is doing multicast dns. Try changing this to:

hosts: files dns

And see if it makes any difference. If it makes it work, you can remove mdns permanently with:

Try apt-get remove libnss-mdns

Which will do the nsswitch.conf change for you as well.

Alternatively, don't use .local - use .lan or something instead.


Just to complete things:

  1. nslookup just asks the given DNS server for the assigned A-record, it does NOT guarantee, that the device behind that record actually HAS that IP.

  2. Even when the device has the correct IP (ex.: fixed IP of the device matches the one provided by DNS) - it doesn't guarantee the device is configured to respond to pings. This is a common point of frustration. (Im talking about you, windows firewall)

  3. When you're crossing subnets, the router / gateway / firewall may restrict ICMP traffic (that's what a ping is) as well.

So you always need to check the full service chain from sender to recipient and vice versa. In case three, there may be settings like a) default gateway or b) (default) routes involved. So add them to your checklist.

Sorry for digging up this old one, but given from the header it seemed like a bit of information, someone could profit from.

Greetz.