BIND DNS nslookup NXDOMAIN

Question

I have BIND DNS server installed in my LAN on Linux CentOS on IP 192.168.0.30. I also have HTTPD Web server installed in my LAN on Linux Centos on IP 192.168.0.23. My /etc/named.conf file is configured to use the /etc/forward.example.com zone file.

zone "example.com" IN {
 type master;
 file "/etc/forward.example.com";
 allow-update { none; };
};

Following the instructions in chapter 16.3 of the CentOS deployment guide, I have the following in my BIND forward zone file to create an A record to the IP address of the HTTPD Web server, and also to map a CNAME to the HTTPD Web server.

$ORIGIN example.com.
$TTL 1D
@ IN SOA  ns1.example.com. hostmaster.example.com. (
                            2016032200 ; serial
                            1D         ; refresh
                            1H         ; retry
                            1W         ; expire
                            3H         ; minimum
)
@            IN      NS         ns1.example.com.
ns1          IN      A          192.168.0.30

server1      IN      A          192.168.0.23
www          IN      CNAME      server1

The named-checkzone command produces OK, which ensures the forward.example.com zone file is OK.

[root@DNS1 ~]# named-checkzone example.com /etc/forward.example.com
zone example.com/IN: loaded serial 2016032200
OK

Running the command nslookup ns1.example.com produces the following output. This is good.

Server:     192.168.0.30
Address:    192.168.0.30#53

Name:       ns1.example.com
Address:    192.168.0.30

Running the command nslookup www.example.com produces the following output.

Server:     192.168.0.30
Address:    192.168.0.30#53

** server can't find www.example.com: NXDOMAIN

Running the command nslookup server1.example.com produces the following output.

Server:     192.168.0.30
Address:    192.168.0.30#53

** server can't find www.example.com: NXDOMAIN

I am not seeing errors in the named.run file.

[root@DNS1 ~]# tail /var/named/data/named.run

zone 0.in-addr.arpa/IN:          loaded serial 0
zone localhost/IN:               loaded serial 0
zone 1.0.0.127.in-addr.arpa/IN:  loaded serial 0
zone 0.168.192.in-addr.arpa/IN:  loaded serial 0
zone 1.xxxxxxxxxxx.ip6.arpa/IN:  loaded serial 0
zone example.com/IN:             loaded serial 0
zone localhost.localdomain/IN:   loaded serial 0
all zones loaded
running

Searching serverfault.com and google.com, I was unable to determine why I am getting the NXDOMAIN error. If there are any tips or recommendations, I sure would appreciate it!

Solution

Your serial number is very suspicious.

0 ; serial

More than likely you have not bumped the serial number and your secondaries have not replicated the change which added the existence of a www record.

If that is not in fact your serial number, this question is far too redacted. :)

Comments

[JeremyCanfield]

Thank you very much Andrew B! I had not considered the serial configuration in the zone file. I have manually updated my forward zone file to list the serial number as 2016032200. I then restarted BIND. If I am not mistaken, it appears that serial is used to ensure a master and slave DNS server zone files remain synchronized. I do not think this applies to my scenario yet, as I am only configured a single instance of BIND as a master. I am still getting NXDOMAIN, and I am continuing to investigate the cause of this issue. Thank you very much for sharing the tip regarding the serial number.

[Andrew B]

@Jeremy You're correct, this would only apply if zone transfers were occurring. I'm at a loss as to what else would be doing this. Please update your question with the output of named-checkzone example.com /path/to/zone/file, and if there are no errors, make sure that this is in fact the file that is being loaded. Any warnings from your logs would also help.

[JeremyCanfield]

thank you thank you thank you! Your tip lead me to the solution. I observed that my forward zone file had serial 2016032200, yet the end of the /var/named/data/named.run file has serial 0. This led me to understand that changes made to the zone file were not being loaded. I discovered two forward zone files on my OS, one at /etc/forward.example.com and another at /var/named/forward.example.com. I deleted the rouge zone file, and then used the correct forward zone file, which resolved the issue. Thank you very much for the assistance!