Skip to main content

You are here

BIND

BIND - Slave zone transfer stopped working

I was surprised to see that a typo fucked up caused all slave transfers to shit themselves. I came across a situation where a new slave zone was specified to a non-existing location in the file system and that caused the rest of the slave zones to get permission denied errors when trying to update.

Logs

Jul 12 03:23:27 ns2 named[1184]: dumping master file: etc/zones/tmp-Zbk9acg9uv: open: permission denied
Jul 12 03:27:50 ns2 named[1184]: dumping master file: etc/zenos/tmp-4yxBXaUMTq: open: file not found
Jul 12 03:29:46 ns2 named[1184]: dumping master file: etc/zones/tmp-KPqzHa9ev9: open: permission denied
Jul 12 03:38:02 ns2 named[1184]: dumping master file: etc/zones/tmp-kuhtUPjcAi: open: permission denied

Awesome Applications: 

Reverse DNS Slave Setup

So a few months back, I enabled reverse DNS on my home BIND server (https://www.rubysecurity.org/bind_rerverse-dns). One thing that I forgot to implement was the additional slave DNS reverse setup. Like many things in BIND, the slave revserse DNS setup was dead simple.

It's simply just a matter of adding the following entry to the slave's named.conf with the updated master's DNS IP specified in the masters directive and reload BIND.

zone "1.168.192.in-addr.arpa" IN {
        type slave;
        file "etc/zones/db.192.168.1.255.bak";
        allow-query { any; };
        masters { MasterDNSIP; };
};

Awesome Applications: 

Reverse DNS in BIND 9.8

I use BIND on my home network, and giving the bast amount of virtual machines I have online, I've always find myself wanting to easily look up which machine is using which IP address without having to ssh into the actual vm or check the zone file. Configuring reverse DNS in BIND 9.8 is actually a dead simple process.
First, a separate zone file for PTR records needs to be created, I named mine db.192.168.1.255.
Note: since my network address space is 192.168.1, the actual PTR record will be the network address backgrounds followed by in-addr.arpa..

$TTL 3h
@       IN SOA  ns1.rubyninja.org. dnsadmin.rubysecurity.org. (
                                        2013090701      ; serial
                                        3h              ; refresh after 3 hours
                                        1h              ; retry after 1 hour
                                        1w              ; expire after 1 week
                                        1H )            ; negative caching TTL of 1 hour

              IN      NS      ns1.rubyninja.org.
              IN      NS      ns2.rubyninja.org.

14.1.168.192.in-addr.arpa.      IN      PTR     email.rubyninja.org.

Lastly, the zone entry needs to be added to the master named.conf file. Mine looks like this

zone "1.168.192.in-addr.arpa" IN {
        type master;
        file "etc/zones/db.192.168.1.255";
        allow-query { any; };
};

After reloading Bind, you verify reverse DNS works by using the utility of your choice; ie dig, host, nslookup, etc..

alpha03:~ tony$ nslookup 192.168.1.14
Server:		192.168.1.10
Address:	192.168.1.10#53

14.1.168.192.in-addr.arpa	name = email.rubyninja.org.

Linux: 

Awesome Applications: 

BIND 9.7.3

On my new CentOS 6 powered BIND DNS server, it took a while to figure out why my custom jailed BIND configuration was not able to load any zone data files, even though the zone data files did not had any sort of syntax errors. Of which I verified using the named-checkzone utility.

Syslog errors:

Dec 29 21:29:04 centos6 named[17311]: etc/db.rubysecurity.org:2: ignoring out-of-zone data (rubysecurity.org)
Dec 29 21:29:04 centos6 named[17311]: etc/db.rubysecurity.org:9: ignoring out-of-zone data (rubysecurity.org)
Dec 29 21:29:04 centos6 named[17311]: etc/db.rubysecurity.org:10: ignoring out-of-zone data (rubysecurity.org)
Dec 29 21:29:04 centos6 named[17311]: etc/db.rubysecurity.org:11: ignoring out-of-zone data (rubysecurity.org)
Dec 29 21:29:04 centos6 named[17311]: etc/db.rubysecurity.org:12: ignoring out-of-zone data (www.rubysecurity.org)
Dec 29 21:29:04 centos6 named[17311]: zone db.rubysecurity.org/IN: has 0 SOA records
Dec 29 21:29:04 centos6 named[17311]: zone db.rubysecurity.org/IN: has no NS records
Dec 29 21:29:04 centos6 named[17311]: zone db.rubysecurity.org/IN: not loaded due to errors.
Dec 29 21:29:04 centos6 named[17311]: etc/db.ubuntu:2: ignoring out-of-zone data (ubuntu)
Dec 29 21:29:04 centos6 named[17311]: zone db.ubuntu/IN: has 0 SOA records
Dec 29 21:29:04 centos6 named[17311]: zone db.ubuntu/IN: not loaded due to errors.

I came to realize the issue was within my named.conf master config file. Since I'm using BIND 9.7.3 (and newer versions), it turns out that the zone name needs to have a dot (.) at the end of the domain name. This was really annoying since it appears that earlier versions didn't tagged this an error and were able to load up zone files perfectly fine without the addition of the dot character at the end of the zone file name. Luckily, I was able to fix the issue, which by the way, the named-checkconf utility was not able to detect this problem.

Broken:

zone "rubysecurity.org" IN {
        type master;
        file "etc/db.rubysecurity.org";
        allow-update { key rndc-key; };
        allow-query { any; };

};

Fix:

zone "rubysecurity.org." IN {
        type master;
        file "etc/db.rubysecurity.org";
        allow-update { key rndc-key; };
        allow-query { any; };

};

Awesome Applications: 

Premium Drupal Themes by Adaptivethemes