suddenly, 1 host fails to resolve only on 1 server

Red Squirrel

No Lifer
May 24, 2003
70,169
13,573
126
www.anyf.ca
I have a CentOS server where only 1 host fails to resolve (it's own host name) but everything else works. I can resolve that hostname on any other server. Any other host resolves fine, so I know it's not a DNS setting issue, because it is set to my DNS server and it's working for all host's but one.

Why is this? This worked about 10 minutes ago, and it suddenly stopped working. I noticed when I was testing something in apache and restarting it, I suddenly started getting this error:

Starting httpd: httpd: Could not reliably determine the server's fully qualified domain name, using aovdb.loc for ServerName

What gives? Why is it suddenly failing to resolve it's own host name? Is there some kind of log somewhere I can check to see why it's failing? This is an active database server so I can't reboot it.

Here's output showing what I mean: Even reverse zone works. It's just aovdb.loc that fails, everything else works.

[root@aovdb ~]# nslookup aovdb.loc
Server: 10.7.7.1
Address: 10.7.7.1#53

** server can't find aovdb.loc: NXDOMAIN

[root@aovdb ~]# nslookup borg.loc
Server: 10.7.7.1
Address: 10.7.7.1#53

Non-authoritative answer:
Name: borg.loc
Address: 10.1.1.10

[root@aovdb ~]# nslookup 10.7.7.11
Server: 10.7.7.1
Address: 10.7.7.1#53

Non-authoritative answer:
11.7.7.10.in-addr.arpa name = aovdb.loc.

Authoritative answers can be found from:

[root@aovdb ~]#

On another server it works:

[root@appdev ~]# nslookup aovdb.loc
Server: 10.1.1.5
Address: 10.1.1.5#53

Name: aovdb.loc
Address: 10.7.7.11

[root@appdev ~]# nslookup borg.loc
Server: 10.1.1.5
Address: 10.1.1.5#53

Name: borg.loc
Address: 10.1.1.10

[root@appdev ~]# nslookup 10.7.7.11
Server: 10.1.1.5
Address: 10.1.1.5#53

11.7.7.10.in-addr.arpa name = aovdb.loc.

Note 10.7.7.1 is the gateway for that vlan and has a DNS forwarder to 10.1.1.5.

Actually it looks like everything on that vlan can't resolve that host, but why, it can resolve everything else, so the forwarding is working. If it matters this is what the record for aovdb.loc looks like:

Code:
$TTL 600
@ IN SOA aovdb.loc. root.borg.loc. (
                                        1000000000       ; serial
                                        1D      ; refresh
                                        1H      ; retry
                                        1W      ; expire
                                        3H     ; minimum
                                        )



@       IN      NS      ns1.rohan.loc.
;       IN      MX      10 mail.aovdb.loc.

@ IN A 10.7.7.11

If I open up the port so that vlan can access the DNS server directly and do nslookup through that server, then it works, but I rather not open up that port up to that vlan. It's a vlan for internet facing stuff so I consider it untrusted and don't want to open up any ports that go to my main network. I guess if it's just DNS which is chrooted it's not THAT huge a risk...
 
Last edited:
Feb 25, 2011
16,991
1,620
126
What's routing between the vlan where the server is and the vlan where the dns server is?

Quick fix would be hosts file, obvs. But if you have a vlan that can't talk to the dns server, that seems like a problem worth fixing.
 

Red Squirrel

No Lifer
May 24, 2003
70,169
13,573
126
www.anyf.ca
Its pfsense, basically that vlan allows only the gateway to talk to the DNS server but the machines can't. Oddly, restarting the DNS redirection service on pfsense fixed the issue. Still no clue why only 1 host was not working though, that's really messed.

If it gives me more issues I might have to just open up the DNS port and use the server directly. Not really that huge of a risk I guess.
 
Feb 25, 2011
16,991
1,620
126
Its pfsense, basically that vlan allows only the gateway to talk to the DNS server but the machines can't. Oddly, restarting the DNS redirection service on pfsense fixed the issue. Still no clue why only 1 host was not working though, that's really messed.
I have had enough "only effects that one host" issues crop up that were fixed by router reboots that I don't question anymore. :whiste: