RHEL DNS and BIND Operations

Anil Jalela · Published Sep 3, 2026 · 7 min read

DNS is a distributed decision path, not one server or one command. A client may use search suffixes, a local stub and a recursive resolver before reaching delegated authoritative servers. Cached positive and negative answers have TTLs. Before changing a zone, identify whether the server is authoritative, recursive or both, which view answered, who owns the parent delegation and how rollback will respect cache behavior.

Separate authority, recursion and client policy

An authoritative server answers from zones it serves. A recursive resolver follows delegations and caches answers for clients. Mixing open recursion with public authority creates abuse risk and a larger failure boundary. Restrict recursion to approved clients or separate roles.

Zone serials coordinate transfers. A syntactically valid record can still point to the wrong service, violate application intent or conflict with the parent delegation. DNSSEC validates signed data chains; it does not encrypt queries or prove an application endpoint is safe.

Build an evidence map

Operating sequence

1. Define server role, clients, zones, views, transfer and DNSSEC ownership.
2. Back up exact named configuration and zone files with permissions.
3. Edit one zone through its owned source and increment serial deliberately.
4. Run named-checkconf and named-checkzone.
5. Compare candidate records with parent delegation and application intent.
6. Reload the exact zone/service using a supported command.
7. Query authoritative and recursive paths, including negative and DNSSEC behavior.

Commands and expected evidence

named-checkconf
named-checkconf -z
named-checkzone example.com /var/named/example.com.zone
rndc status
rndc zonestatus example.com
dig example.com SOA +norecurse @192.0.2.53
dig www.example.com A +dnssec @192.0.2.53
dig example.com NS +trace
dig example.com DS +trace
journalctl -u named --since '-30 minutes' --no-pager
ss -lntup | grep ':53'

• Documentation addresses and domains are examples; use approved lab data.
• +trace performs iterative queries from the client and can differ from the configured recursive resolver path.
• Validate every view or generated zone path, not only one file.
• A reload success does not prove clients receive the intended answer through caches and delegation.

Evidence and acceptance criteria

Worked operating scenario

A DNSSEC-signed zone changes keys, but the parent DS still references the retired key. Authoritative data looks correct when queried without validation, while validating resolvers return SERVFAIL. Flushing random client caches cannot repair the chain.

The operator traces DS and DNSKEY evidence, follows the documented rollover/recovery plan with the registrar and monitors validating and nonvalidating results. Application teams receive an explicit impact window and no one disables validation globally.

Practical how-to cases

sudo named-checkconf
sudo named-checkzone example.test /var/named/example.test.zone
sudo rndc reload example.test
dig @127.0.0.1 example.test SOA +norecurse
dig @127.0.0.1 www.example.test A +norecurse

sudo named-checkzone 2.0.192.in-addr.arpa /var/named/192.0.2.rev
sudo rndc reload
dig @127.0.0.1 -x 192.0.2.10 +norecurse
dig @127.0.0.1 mail.example.test A +short

dig @192.0.2.53 example.com A +recurse
dig @192.0.2.53 example.com A +norecurse
sudo rndc status
sudo ss -lnup | grep ':53'
sudo firewall-cmd --list-services

dig +trace www.example.test
dig @AUTHORITATIVE_IP www.example.test A +norecurse
dig @127.0.0.1 www.example.test A
resolvectl query www.example.test 2>/dev/null || getent ahosts www.example.test
journalctl -u named -n 50

Independent practice tasks

1. Create forward and reverse lab zones with correct serial changes.
2. Configure a caching-only resolver limited to one subnet.
3. Break a zone syntax element and recover using validators.
4. Explain NXDOMAIN, NODATA, SERVFAIL, REFUSED and timeout with one test each.

For this lesson on RHEL DNS and BIND, complete each task without copying the worked command sequence. Record the initial state, exact change, verification, negative test and recovery command. A task is unfinished if it works now but does not survive a reboot where persistence is required.

Troubleshooting by symptom

Unsafe operations and recovery boundaries

• Unsafe: exposing unrestricted recursion enables reflection abuse and unauthorized use.
• Unsafe: deleting DS records or disabling validation without a controlled DNSSEC recovery plan weakens integrity and may prolong outage.
• Unsafe: broad cache flushing changes many tenants and destroys useful TTL evidence.

Rewritten knowledge checks

Guided lab and acceptance test

1. Install BIND on an isolated network and restrict recursion to the lab subnet.
2. Create an example authoritative zone with SOA, NS and host records.
3. Introduce a syntax error and prove validators block activation.
4. Correct, increment serial, reload and query authoritative/recursive paths.
5. Change a record with a short TTL and observe cache aging.
6. Remove the lab zone/service and verify port 53 exposure is gone.

Primary references

• RHEL 10 configuring and managing networking
• RHEL 10 documentation
• RHEL 9 documentation