BIND
Setup (install and start named)
- Install BIND (provides named):
Overview
- Purpose: Authoritative BIND pair for the homelab: a master (ns1) and a slave (ns2).
- Zones served: skynet.lan, skynet.monitor, skynethome.dev (master on ns1, slave on ns2).
- Zone files: stored under /var/named (slaves in /var/named/slaves).
Files & Where To Look
- Master configuration: /etc/named.conf on ns1 (master).
- Slave configuration: /etc/named.conf on ns2 (slave).
- Zone files: /var/named/<zone> and /var/named/slaves/<zone> on slaves.
How this setup works (short)
- Master hosts the canonical zone file and allows AXFR to the slave using allow-transfer and masters statements.
- When the master is updated it can notify slaves; slaves perform AXFR from the master.
Add or change DNS records (manual)
- Edit the zone file /var/named/<zone> on the master.
- Increment the serial in the SOA (important!). Use the epoch or YYYYMMDDnn format. Example SOA serial update:
rndc status for issues. Slaves will receive notify/perform AXFR automatically (or after their refresh interval).
Adding a new zone (manual)
- Add a zone statement to the master's /etc/named.conf:
zone "example.lan" IN {
type master;
file "/var/named/example.lan.db";
allow-transfer { 10.0.0.56; }; # slave IP
notify yes;
};
/var/named/example.lan.db using the same SOA/NS structure as your existing zones.
- Validate with named-checkzone, increment SOA serial, then reload named.
- Ensure the slave's /etc/named.conf has the master IP in its masters { ... } statement so it can AXFR the new zone.
Useful commands
- Validate zone: named-checkzone <zone> <zonefile>
- Test config: named-checkconf /etc/named.conf
- Reload named: rndc reload or systemctl reload named
--
Below are the current /etc/named.conf snippets from your masters and slaves (kept as-is):
[root@ns1 ~]# cat /etc/named.conf
//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//
options {
listen-on port 53 { 10.0.0.55; };
listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
secroots-file "/var/named/data/named.secroots";
recursing-file "/var/named/data/named.recursing";
allow-query { any; };
allow-transfer { 10.0.0.56; }; # NS2 IP
forwarders {
1.1.1.1;
8.8.8.8;
};
forward first;
/*
- If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.
- If you are building a RECURSIVE (caching) DNS server, you need to enable
recursion.
- If your recursive DNS server has a public IP address, you MUST enable access
control to limit queries to your legitimate users. Failing to do so will
cause your server to become part of large scale DNS amplification
attacks. Implementing BCP38 within your network would greatly
reduce such attack surface
*/
recursion yes;
dnssec-validation yes;
managed-keys-directory "/var/named/dynamic";
geoip-directory "/usr/share/GeoIP";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
/* https://fedoraproject.org/wiki/Changes/CryptoPolicy */
include "/etc/crypto-policies/back-ends/bind.config";
};
zone "skynet.lan" IN {
type master;
file "/var/named/skynet.lan.db";
allow-transfer { 10.0.0.56; }; # NS2 IP
notify yes;
};
zone "skynet.monitor" IN {
type master;
file "/var/named/skynet.monitor.db";
allow-transfer { 10.0.0.56; }; # NS2 IP
notify yes;
};
zone "skynethome.dev" IN {
type master;
file "/var/named/skynethome.dev.hosts";
allow-transfer { 10.0.0.56; }; # NS2 IP
notify yes;
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
zone "." IN {
type hint;
file "/etc/named.ca";
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
[root@ns2 etc]# cat named.conf
//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//
options {
listen-on port 53 { 10.0.0.56; };
listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
secroots-file "/var/named/data/named.secroots";
recursing-file "/var/named/data/named.recursing";
allow-query { any; };
// allow-transfer { 10.0.0.; }; # NS2 IP
forwarders {
1.1.1.1;
8.8.8.8;
};
forward first;
/*
- If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.
- If you are building a RECURSIVE (caching) DNS server, you need to enable
recursion.
- If your recursive DNS server has a public IP address, you MUST enable access
control to limit queries to your legitimate users. Failing to do so will
cause your server to become part of large scale DNS amplification
attacks. Implementing BCP38 within your network would greatly
reduce such attack surface
*/
recursion yes;
dnssec-validation yes;
managed-keys-directory "/var/named/dynamic";
geoip-directory "/usr/share/GeoIP";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
/* https://fedoraproject.org/wiki/Changes/CryptoPolicy */
include "/etc/crypto-policies/back-ends/bind.config";
};
zone "skynet.lan" IN {
type slave;
file "/var/named/slaves/skynet.lan.db";
masters { 10.0.0.55; }; // ns1 ip
# allow-transfer { 10.0.0.; }; # NS2 IP
};
zone "skynet.monitor" IN {
type slave;
masters { 10.0.0.55; }; // ns1 IP
file "/var/named/slaves/db.skynet.monitor";
};
zone "skynethome.dev" IN {
type slave;
file "/var/named/skynethome.dev.hosts";
masters { 10.0.0.55; }; # NS2 IP
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
zone "." IN {
type hint;
file "/etc/named.ca";
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";