bind server: Trailing Dot Required For localhost, but no clients

jlacroix · 07-24-2013, 08:08 PM

Hello everyone. This one is really boggling my mind. I have a Debian DNS/DHCP server. All client computers connect to it and use it for DNS, even for local computers.

If any of my computers ping another computer, it works:

Code:

jlacroix@Daphne:~ > ping pluto
PING pluto.localnet (172.16.254.10) 56(84) bytes of data.
64 bytes from 172.16.254.10: icmp_req=1 ttl=64 time=0.161 ms

BUT, if I ping a computer on my network from the DNS server itself:

Code:

jlacroix@Hermes:~$ ping pluto
ping: unknown host pluto

But if I use the FQDN:

Code:

jlacroix@Hermes:~$ ping pluto.localnet
PING pluto.localnet (172.16.254.10) 56(84) bytes of data.
64 bytes from 172.16.254.10: icmp_req=1 ttl=64 time=0.154 ms

So here is my question. Why do I have to append .localnet when pinging FROM my DNS server, but not on any of my client computers?

I'm sure I need to post some config files, but I seriously don't know where this problem originates. Could it be my bind configuration? Maybe my DHCP server? I would think it's not bind since other computers that connect ping just fine.

I'm sure this is a stupid easy problem but I've been working at this for a few days.

Ser Olmy · 07-24-2013, 08:27 PM

Quote:

Originally Posted by jlacroix

So here is my question. Why do I have to append .localnet when pinging FROM my DNS server, but not on any of my client computers?

Probably because your client computers get their domain suffix from the DHCP server, while the server has a different suffix or no suffix at all.

What's the output of the hostname --fqdn command? You may have to edit /etc/hosts and /etc/resolv.conf to correct the domain name. The search parameter in /etc/resolv.conf specifies domain names the client will try to append to hostnames as they are being resolved, and there can be multiple lines/entries.

jlacroix · 07-24-2013, 08:41 PM

Quote:

Originally Posted by Ser Olmy

Probably because your client computers get their domain suffix from the DHCP server, while the server has a different suffix or no suffix at all.

What's the output of the hostname --fqdn command? You may have to edit /etc/hosts and /etc/resolv.conf to correct the domain name. The search parameter in /etc/resolv.conf specifies domain names the client will try to append to hostnames as they are being resolved, and there can be multiple lines/entries.

The output is simply "Hermes" so it looks like your thought process is on the right track.

I haven't edited the /etc/resolv.conf file, because I read somewhere that nowadays it's preferred to use dns-search and dns-nameservers:

/etc/network/interfaces

Code:

auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet dhcp

# The primary network interface
allow-hotplug eth1
iface eth1 inet static
        address 172.16.254.1
        netmask 255.255.255.0
        broadcast 172.16.254.255
        dns-search localnet
        dns-nameservers 172.16.254.1
        pre-up iptables-restore < /etc/iptables.rules
        # post-down iptables-restore < /etc/iptables.downrules

And in case you need it:

/etc/hosts

Code:

127.0.0.1       localhost
127.0.1.1       Hermes

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Ser Olmy · 07-24-2013, 09:02 PM

The value of the dns-search parameter in /etc/network/interfaces should end up in /etc/resolv.conf.

Try adding this line to /etc/hosts:

Code:

172.16.254.1        hermes  hermes.localnet

Any particular reason why you're using a single label domain? "localnet" is only supposed to appear in /etc/networks as an alias for the local network. Not sure if it will cause any problems (probably not), but it's not considered a good practice to use a single label domain.

jlacroix · 07-24-2013, 09:06 PM

Quote:

Originally Posted by Ser Olmy

The value of the dns-search parameter in /etc/network/interfaces should end up in /etc/resolv.conf.

Try adding this line to /etc/hosts:

Code:

172.16.254.1        hermes  hermes.localnet

Any particular reason why you're using a single label domain? "localnet" is only supposed to appear in /etc/networks as an alias for the local network. Not sure if it will cause any problems (probably not), but it's not considered a good practice to use a single label domain.

Thanks for the reply. I added the line you mentioned, but to no avail.

/etc/resolv.conf looks like this:

Code:

domain hsd1.mi.comcast.net.
search hsd1.mi.comcast.net.
nameserver 75.75.76.76
nameserver 75.75.75.75

I'm not sure what you mean by single label domain. The primary purpose for bind on Hermes is just so each machine on my LAN can resolve each other by name without me having to customize the hosts file on each client. The second reason I use bind is so I can learn bind.

Ser Olmy · 07-24-2013, 09:33 PM

I'm not talking about BIND. Your DNS server configuration is probably perfectly OK; this is a problem with the resolver (the DNS client in the OS) on the server.

A single-label domain name is a name that looks like just a top-level domain, like "localnet". No proper domain name can ever look like this; it has to have at least two parts ("mydomain.local"). The Windows family of OSes do not like single-label domain names at all, and they can break certain Active Directory functionality. I don't believe an invalid domain name will cause any problems on the Linux platform, but I would recommend changing it anyway.

As you can see from the /etc/resolv.conf you posted, the server isn't actually using its own DNS service (BIND) to perform name resolution. It's using the Comcast DNS servers, and they obviously know nothing of your local DNS zone.

This happens because you're getting an IP address from Comcast via DHCP, and the DHCP client also receives and accepts a number of other parameters, like the domain name, a domain search suffix and DNS settings. It then goes on to replace whatever you had put in /etc/resolv.conf with these values, effectively breaking name resolution on the server.

There should be only one nameserver entry in /etc/resolv.conf on the server, and it should be either

Code:

nameserver 172.16.254.1

or

Code:

nameserver 127.0.0.1

The latter is preferred because you don't have to change it if you later choose to use a different IP address, and it will keep working even if the network link goes down.

You don't have to edit /etc/resolv.conf. To keep the dhcp client from overwriting your name server settings, add these lines to /etc/dhcp/dhclient.conf:

Code:

prepend domain-search localnet
supersede domain-name-servers 127.0.0.1

They tell dhclient to put the "localnet" domain name first in the search list, and to use 127.0.0.1 as a DNS server instead of whatever Comcast wants you to use. This, combined with the changes to /etc/hosts, should fix the problem once and for all.

jlacroix · 07-24-2013, 09:39 PM

Quote:

Originally Posted by Ser Olmy

I'm not talking about BIND. Your DNS server configuration is probably perfectly OK; this is a problem with the resolver (the DNS client in the OS) on the server.

A single-label domain name is a name that looks like just a top-level domain, like "localnet". No proper domain name can ever look like this; it has to have at least two parts ("mydomain.local"). The Windows family of OSes do not like single-label domain names at all, and they can break certain Active Directory functionality. I don't believe an invalid domain name will cause any problems on the Linux platform, but I would recommend changing it anyway.

As you can see from the /etc/resolv.conf you posted, the server isn't actually using its own DNS service (BIND) to perform name resolution. It's using the Comcast DNS servers, and they obviously know nothing of your local DNS zone.

This happens because you're getting an IP address from Comcast via DHCP, and the DHCP client also receives and accepts a number of other parameters, like the domain name, a domain search suffix and DNS settings. It then goes on to replace whatever you had put in /etc/resolv.conf with these values, effectively breaking name resolution on the server.

There should be only one nameserver entry in /etc/resolv.conf on the server, and it should be either

Code:

nameserver 172.16.254.1

or

Code:

nameserver 127.0.0.1

The latter is preferred because you don't have to change it if you later choose to use a different IP address, and it will keep working even if the network link goes down.

You don't have to edit /etc/resolv.conf. To keep the dhcp client from overwriting your name server settings, add these lines to /etc/dhcp/dhclient.conf:

Code:

prepend domain-search localnet
supersede domain-name-servers 127.0.0.1

They tell dhclient to put the "localnet" domain name first in the search list, and to use 127.0.0.1 as a DNS server instead of whatever Comcast wants you to use. This, combined with the changes to /etc/hosts, should fix the problem once and for all.

I was under the impression that dns-search and domain-nameservers in /etc/network/interfaces took care of the need to have anything added to /etc/resolv.conf, or is that not correct?

I will adopt your changes and report back soon. Thanks again!

Edit: Still doesn't work. I personally don't think there's anything wrong with the resolver on the server itself now that I think about it, because it DOES resolve local host names if I put ".localnet" at the end of the host name. This restriction isn't required on my clients.

Another question that I don't understand is when I put localhost in /etc/resolv.conf, why does my Internet still work? Perhaps the forwarders clause in my bind configuration then takes over?

Thanks again.

Ser Olmy · 07-24-2013, 10:16 PM

Quote:

Originally Posted by jlacroix

I was under the impression that dns-search and domain-nameservers in /etc/network/interfaces took care of the need to have anything added to /etc/resolv.conf, or is that not correct?

That's correct. /etc/network/interfaces is not read by the kernel at all. It's a Debian-specific configuration file, and the Debian network script feeds the parameters in that file to the relevant executables, like dhclient and ifconfig, or as you say, modifies /etc/resolv.conf.

"dns-search" and "domain-nameservers" end up in /etc/resolv.conf which is used by the kernel (or rather certain glibc libraries).

Quote:

Originally Posted by jlacroix

Edit: Still doesn't work. I personally don't think there's anything wrong with the resolver on the server itself now that I think about it, because it DOES resolve local host names if I put ".localnet" at the end of the host name.

You may be partially right. I overlooked the fact that manually appending ".localnet" works, which would indicate that the local DNS zone is being queried. But the behaviour of the resolver is 100% dictated by the contents of /etc/resolv.conf, and under no circumstances should any other nameservers than the ones listed in that file be queried.

Nevertheless, the fact that you have to append ".localnet" indicates that the server doesn't think it belongs in that domain, and furthermore that no "search" parameter exists in /etc/resolv.conf for "localnet".

The command hostname --fqdn should return "hermes.localnet" when run on the server. If it doesn't, a missing entry in /etc/hosts is to blame. (I've just tested this; the output of hostname --fqdn changes if I edit the relevant entry in /etc/resolv.conf). If adding the 172.16.254.1 address doesn't help, try the external IP address.

Quote:

Originally Posted by jlacroix

Another question that I don't understand is when I put localhost in /etc/resolv.conf, why does my Internet still work? Perhaps the forwarders clause in my bind configuration then takes over?

The reason you can still access the Internet with 127.0.0.1 as your resolver, is that BIND does recursive lookups. It comes bundled with a "hints" file containing the IP addresses of the 13 root DNS servers on the Internet, so even if you hadn't specified a forwarder it would have queried those servers if it couldn't resolve a name using a local zone.

Needlessly bothering the root servers is considered bad form, so adding one or more forwarders is the right thing to do.

jlacroix · 07-24-2013, 10:27 PM

Quote:

Originally Posted by Ser Olmy

That's correct. /etc/network/interfaces is not read by the kernel at all. It's a Debian-specific configuration file, and the Debian network script feeds the parameters in that file to the relevant executables, like dhclient and ifconfig, or as you say, modifies /etc/resolv.conf.

"dns-search" and "domain-nameservers" end up in /etc/resolv.conf which is used by the kernel (or rather certain glibc libraries).

You may be partially right. I overlooked the fact that manually appending ".localnet" works, which would indicate that the local DNS zone is being queried. But the behaviour of the resolver is 100% dictated by the contents of /etc/resolv.conf, and under no circumstances should any other nameservers than the ones listed in that file be queried.

Nevertheless, the fact that you have to append ".localnet" indicates that the server doesn't think it belongs in that domain, and furthermore that no "search" parameter exists in /etc/resolv.conf for "localnet".

The command hostname --fqdn should return "hermes.localnet" when run on the server. If it doesn't, a missing entry in /etc/hosts is to blame. (I've just tested this; the output of hostname --fqdn changes if I edit the relevant entry in /etc/resolv.conf). If adding the 172.16.254.1 address doesn't help, try the external IP address.

The reason you can still access the Internet with 127.0.0.1 as your resolver, is that BIND does recursive lookups. It comes bundled with a "hints" file containing the IP addresses of the 13 root DNS servers on the Internet, so even if you hadn't specified a forwarder it would have queried those servers if it couldn't resolve a name using a local zone.

Needlessly bothering the root servers is considered bad form, so adding one or more forwarders is the right thing to do.

Wow, thank you, that is some VERY useful information.

Unfortunately, nothing I put in /etc/hosts has an effect on hostname --fqdn. Further, even with dns-search and domain-nameservers in /etc/network/interfaces, nothing ever changes in /etc/resolv.conf.

Ser Olmy · 07-25-2013, 07:40 AM

Quote:

Originally Posted by jlacroix

Unfortunately, nothing I put in /etc/hosts has an effect on hostname --fqdn. Further, even with dns-search and domain-nameservers in /etc/network/interfaces, nothing ever changes in /etc/resolv.conf.

Did you run the appropriate Debian command to "restart" the network?

It seems /etc/init.d/networking restart is deprecated and one now has to run /etc/init.d/networking stop followed by /etc/init.d/networking start.

jlacroix · 07-25-2013, 07:52 AM

Quote:

Originally Posted by Ser Olmy

Did you run the appropriate Debian command to "restart" the network?

It seems /etc/init.d/networking restart is deprecated and one now has to run /etc/init.d/networking stop followed by /etc/init.d/networking start.

No, I didn't try that. I will when I get home. The reason I didn't try that is because all other changes to /etc/hosts generally take effect right away. For example, if I manually put an entry for one of the clients in there, it recognizes it right away without restarting anything so I figured restarting networking wasn't necessary.

Ser Olmy · 07-25-2013, 08:12 AM

Quote:

Originally Posted by jlacroix

The reason I didn't try that is because all other changes to /etc/hosts generally take effect right away.

You're right, it does, but the stuff in /etc/network/interfaces is only read when the script is run.

jlacroix · 07-25-2013, 08:15 AM

Quote:

Originally Posted by Ser Olmy

You're right, it does, but the stuff in /etc/network/interfaces is only read when the script is run.

Awesome, I'll try it when I get home. I tried to ssh in and restart the networking, thinking that the "start" option would run before I got disconnected, but I inadvertently disabled my home networking in the process. I'll start networking when I get back home and respond back.

Thank you very much for your help, I've learned more from this topic than I have almost any other.

jlacroix · 07-25-2013, 05:20 PM

Unfortunately restarting networking with the changes applied didn't fix it, nor did restarting the entire server.

I decided to try your other suggestion and not use a single label domain, so I changed localnet to local.net. Now, it's worse. Not even hermes (the DNS server itself) can ping local hosts, it sends all attempts to ping local hosts to the WAN (the other hosts can ping it and each other, though). I did a filesystem search to make sure all instances of localnet were changed to local.net (text and file names) and hermes still can't ping anything.

Ser Olmy · 07-25-2013, 05:32 PM

Quote:

Originally Posted by jlacroix

I decided to try your other suggestion and not use a single label domain, so I changed localnet to local.net. Now, it's worse. Not even hermes (the DNS server itself) can ping local hosts, it sends all attempts to ping local hosts to the WAN (the other hosts can ping it and each other, though). I did a filesystem search to make sure all instances of localnet were changed to local.net (text and file names) and hermes still can't ping anything.

Changing the domain name should have absolutely no effect on routing. If you can't ping IP addresses on the local network, something is wrong with your IP setup.

If I misunderstood you and the problem is related to name resolution rather than IP connectivity, the DNS server is the likely culprit. Did you change the domain name in both /etc/named.conf and in the zone file?

If you're using dynamic DNS, the clients will need to be notified of the new domain name before they will start registering their names in the new DNS zone. A DHCP release/renew will do that, provided you changed the domain name in the DHCP server configuration file as well.