How to manage Bind DNS zones at scale
Ever wondered how to manage thousands of slave zones in Bind? Here's the answer Managing a few slave zones manually isn't that hard however when you regularly need to add domains to your slave servers managing it properly quickly becomes a logistical nightmare.
Thankfully, the ISC Bind software contains a feature called "Catalog Zones" which dramatically simplifies the process of managing slave zones.
This feature will allow you to automatically set up and configure new zones on slave servers.
We will walk through the entire process to get this puppy running and make the management of your slave servers and zones a lot easier.
Let’s dive in and see how to get this up and running!
Step 1: Configure the Master Server
To begin with, configure the master server by adjusting a few settings. Start by modifying the options section in the Bind configuration to enable the automatic acceptance of new zones by the slave servers.
Add the following boolean option to your configuration:
options {
directory "/etc/namedb";
...
server-id "authoritative";
allow-new-zones yes;
};
This enables the "allow-new-zones" directive, which tells Bind that new zones can be created dynamically.
The next step is to create the catalog zone file, which outlines the structure of the catalog:
$TTL 3600
@ IN SOA . . 1 86400 3600 86400 3600
@ IN NS ns1.
version IN TXT "2"
The version TXT record with value "2" specifies the catalog zone format version.
Step 2: Configure the Slave Server
On the slave server, similar settings need to be added to enable the automatic creation of new zones. Add the following to your Bind configuration:
options {
directory "/etc/namedb";
...
masterfile-format text;
zone-statistics yes;
server-id "slave";
allow-new-zones yes;
catalog-zones {
zone "catalog.example.com"
zone-directory "cat-zones"
in-memory no
default-masters { 10.71.0.176; };
};
};
This configuration ensures that the slave server recognizes and accepts new zones specified in the catalog, storing them in the cat-zones directory.
Additionally, configure the catalog zone to function as a slave:
zone "catalog.example.com" {
type slave;
file "catalog.example.com.db";
masters { 10.71.0.176; };
};
This setup allows the slave server to locate and synchronize the catalog zone effectively.
Step 3: Add a New Member Zone
To add a new member zone, use rndc to add the new zone to the master server:
rndc addzone example.org '{type master; file "example.org";}';
dig +short @127.0.0.1 example.org soa
The above command adds the new member zone, and then we check if it has been properly added by querying the SOA record.
To add the zone to the catalog, you need to generate a hash for the member zone name. Here’s a Python script to create this hash:
#!/usr/bin/env python
import dns.name # pip install dnspython
import hashlib
import sys
print(hashlib.sha1(dns.name.from_text(sys.argv[1]).to_wire()).hexdigest())
To generate the hash for example.org, run:
./nzf.py example.org
9f8e7a6b5c4d3e2f1b0a8c7d6e5f4b3a9c0d1e2f
Alternatively, you could use openssl to generate the hash:
printf '\7example\3org\0' | openssl sha1
9f8e7a6b5c4d3e2f1b0a8c7d6e5f4b3a9c0d1e2f
Step 4: Update the Catalog Zone
Now that you have the hash, use it to add a record to the catalog zone for the new member zone:
@ 3600 SOA . . 2 86400 3600 86400 3600
@ 3600 IN NS nop.
9f8e7a6b5c4d3e2f1b0a8c7d6e5f4b3a9c0d1e2f.zones PTR example.org.
Once this record is added, reload the named service on the primary server:
rndc reload
You should see the transfer logs confirming that the new zone has been successfully propagated:
xfer-out: info: client 10.71.0.177#33213 (catalog.example.com): transfer of 'catalog.example.com/IN': AXFR-style IXFR started (serial 2)
xfer-out: info: client 10.71.0.177#33213 (catalog.example.com): transfer of 'catalog.example.com/IN': AXFR-style IXFR ended
xfer-out: info: client 10.71.0.177#45095 (example.org): transfer of 'example.org/IN': AXFR started (serial 22)
xfer-out: info: client 10.71.0.177#45095 (example.org): transfer of 'example.org/IN': AXFR ended
Verifying the Setup on the Secondary
The new zone should now exist on the secondary server. Check the cat-zones directory for the slaved zone:
ls -l /etc/namedb/cat-zones
-rw-r--r-- 1 root root 316 Jun 2 13:33 __catz__catalog.example.com_example.org.db
The __catz__* file contains a copy of the slaved zone.
To remove a member zone from the catalog, delete the corresponding record from the catalog zone, and named will automatically remove it from the secondary servers:
catz: updating catalog zone 'catalog.example.com' with serial 3
catz: deleting zone 'example.org' from catalog 'catalog.example.com' - success
catz: catz_delzone_taskaction: zone 'example.org' deleted
Using Metadata in Catalog Zones
Catalog zones have the capability to include metadata, enabling you to set specific parameters for member zones. For instance, you can assign different master servers to a particular member zone by adding an entry to the catalog as follows:
9f8e7a6b5c4d3e2f1b0a8c7d6e5f4b3a9c0d1e2f IN PTR yo.momma.isfat.
masters.9f8e7a6b5c4d3e2f1b0a8c7d6e5f4b3a9c0d1e2f.zones IN A 10.71.0.144
You can also set Address Prefix Lists (APLs) to control zone transfers on a per-zone basis:
allow-transfer.9f8e7a6b5c4d3e2f1b0a8c7d6e5f4b3a9c0d1e2f.zones IN APL 1:10.71.0.177/32 1:10.71.0.247/32
This example allows zone transfers from two specific IP addresses.
A notable feature of catalog zones is their ability to support TSIG signatures, which add an extra layer of security for transferring member zones.
Conclusion
Catalog zones significantly streamline DNS zone management with Bind, particularly when managing a large number of zones. By supporting dynamic updates, catalog zones simplify provisioning, reducing the process of adding new member zones to just a few simple commands.