No, I am not using dynamic DNS. To make sure you understand the problem, all my computers can ping each other by name. However, the DNS server can only ping the computers if I append the domain name (formerly .localnet).

Forget I mentioned about the DNS server not being able to ping now, I figured that out. local.net is an actual top level domain on the Internet, so OF COURSE it is going to foward to the WAN *slaps self*. The only remaining issue is the issue I opened the topic for, I have to append the domain name to the end of the host name to ping from the DNS server but the local computers don't have that restriction.

Ok, this is partially solved. With all the other changes I made, I tried emptying /etc/resolv.conf and putting only:
You've mentioned that before and it didn't work the first time I did that, but with other changes I've made combined with that, it works normal. However, /etc/resolv.conf is wiped out when I reboot.

So recalling your suggestion to put the following in /etc/dhcp/dhclient.conf:
I tried that, and it has no effect whatsoever. The prepended and superseded information is not placed in /etc/resolv.conf even after that adjustment.

I'm very close now!

Right. What exactly does hostname --fqdn return when you run it on the server?

Edit: Didn't see your latest post until just now. According to the Debian docs, it should be possible to put the "prepend" stuff in the interfaces file instead of /etc/dhcp/dhclient.conf. I'll look into it and get back to you.

The output of hostname --fqdn has never changed despite any changes you've suggested. In fact, even the computers that work fine show the same output for that command.

See my above post, I'm almost there now.

To be clear, you're saying that now returns hermes.your-local-domain-name? You still can't ping anotherclient, while pinging anotherclient.your-local-domain-name does work?

As for getting the right settings into /etc/resolv.conf, this document claims that adding "prepend" or "supersede" settings to /etc/dhcp/dhclient.conf should work. The exact syntax is described in the first answer in this thread.

Then there's this thread in a Debian forum, where one poster claims that the correct file could be either /etc/dhclient.conf, /etc/dhcp/dhclient.conf or even /etc/dhcp3/dhclient.conf.

Yes, you're correct.

hostname --fqdn never shows anything other than the host name, such as "Hermes" or "Pluto". It never shows the .local.lan part on any of my computers, even the ones that are working and resolving properly. Perhaps this was deprecated in some way?

I've Googled like crazy regarding the "prepend" and "supersede" options. Debian is completely ignoring them. It does nothing. It may work on other distributions, but not Debian Wheezy, apparently.

If I manually change /etc/resolv.conf to ONLY contain the following, it works until I reboot:
But from my understanding, editing /etc/resolv.conf shouldn't even be necessary, because in /etc/network/interfaces I have:
Debian ignores that too. In all other distributions I've tried (that are Debian-based) adding the aforementioned two lines to /etc/network/interfaces has worked perfectly.

Sorry to be a pain, but something on my server seems to be ignoring my directives.

No, apparently I'm not, as the next paragraph demonstrates.

FQDN stands for "Fully Qualified Domain Name", and is by definition the host name with the domain name appended at the end.

If neither the server nor the clients have a domain name, something's not quite right with both your DHCP server configuration (which affects the clients) and the network configuration on the server.

If a host doesn't have a domain name, it stands to reason that it can't append that non-existent name to any DNS queries. But the clients are still able to resolve names. I think you'll find that the /etc/resolv.conf file on the clients contains a search parameter listing the domain name. If the local resolver can't resolve a name, it will append any search suffixes in turn and query the DNS server for the resulting FQDN(s).

The documentation I referred to is specific to Debian. According to that documentation, your /etc/dhcp/dhclient.conf file should contain this:If either /etc/dhclient.conf or /etc/dhcp3/dhclient.conf exist, they would need to be deleted.

Is that under eth0 or eth1? Because it's the eth0 setting that triggers dhclient, which in turn overwrites /etc/resolv.conf with information it gets via DHCP from Comcast.

But the clients are fine, even without it, that's why I was thinking it is either hidden despite the --fqdn option or deprecated. But I would think that this should just work too, because in /etc/dhcp/dhcpd.conf I have:That is correct.



Yes, I read that, but it still doesn't work.


eth0 = Comcast, eth1 = LAN.

the solution could be :

make the entries in /etc/hosts

like

[ip] [fqdn] [alias]

another thisng in your DNS Zone file conf:
add CNAME to your clients, make sure you have added an A record for your client.

Why would he need a CNAME record?

Assuming the above is the zone file for the "localnet" zone, this would add a CNAME pointer from "pluto.localnet" to "pluto.localnet.localnet". That doesn't make sense.

No need to assume its from zone file:
well I just gave a alternative. I forgot to mention OR another thing*.
That does make sense when you want to use an alias on the network permanently as I have seen OP was trying to so some stuff like that and end up with can't resolve error.., so after making that entry when a user tries accessing a resource on the network using "pluto"(say) it will look out for "pluto.localnet" and doesn't end up with "cant resolve pluto" or something like that.

Thanks for the responses, guys. The problem is still not solved but I think it makes sense now at least. eth0 is DHCP and connected directly to the cable modem. eth1 is connected to my LAN and uses a static address. Whenever eth0 gets an IP address from the cable modem, it wipes out /etc/resolv.conf. When /etc/resolv.conf gets wiped out, local DNS resolution on the server itself starts working incorrectly.

All prepend or supersede options are ignored, as are all directives I use to explicitly set eth1 to try to resolve using localhost. I'm not sure why Debian goes this far out of its way to block pretty much EVERY method of customizing how it resolves things.

Thanks for everything, and I hope there is a solution.

There is a solution i reproduced that issue and found; you can do this :

this will rectify the problem of changing of resolv.conf again and again.