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:
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.
On another server it works:
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:
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...
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: