Loading...

Lab 75: DNS Service Bring-Up

Install and bring up a minimal BIND name server, then publish a forward zone for example.com with internal A records. Validate authoritative answers by querying localhost directly with dig.

dns networking services core

Scenario

You are deploying a basic internal DNS service so hosts can resolve names without relying on external resolvers. You will install BIND, define a forward zone for example.com, start the daemon, and confirm the server answers queries locally.

Operator context

DNS issues present as “everything is down.” The first step is proving the daemon answers, the second is proving the zone loads, and the third is proving clients can reach it. This lab focuses on the server-side baseline and local validation.

Objective

  • Install BIND for your distro family.
  • Create a minimal named.conf and define a master forward zone.
  • Publish a forward zone for example.com with ns1 and www A records.
  • Start the DNS service and validate answers with dig against localhost.

Concepts

  • Authoritative versus recursive resolution, and why you validate server bring-up with direct queries.
  • BIND configuration layout: global options and per-zone stanzas.
  • Forward zone file structure: SOA, NS, and A records.
  • Serial numbers and reload behavior: why a zone can “exist” but not serve updated data.
  • Service verification flow: service state, logs, then query results.

Walkthrough

Step 1 : Install the DNS server package.
Commands
# RHEL-family
sudo yum install bind

# Debian/Ubuntu
sudo apt install bind9

# Arch
sudo pacman -S bind

Install the DNS server package for your platform. Package names vary, but the goal is the same: get BIND installed so you can define a zone and start the daemon.

Step 2 : Define a minimal named.conf and a forward zone.
Commands
# RHEL/Arch common path
sudo vim /etc/named.conf

# Debian common path
sudo vim /etc/bind/named.conf

Create an options block with a safe baseline and define a master zone for example.com. The zone stanza must point to the zone file you will create next.

options {
    directory "/var/named";
    listen-on port 53 { any; };
    allow-query { any; };
};

zone "example.com" IN {
    type master;
    file "example.com.zone";
};
Step 3 : Create the forward zone file.
Commands
# RHEL-style zone location
sudo vim /var/named/example.com.zone

# Debian-style zone location
sudo vim /etc/bind/db.example.com

Publish the minimum required records to prove the server can answer authoritatively for the zone. Keep record names consistent with the domain you defined in named.conf.

$TTL 86400
@   IN  SOA ns1.example.com. admin.example.com. (
            2026021101 ; Serial
            3600       ; Refresh
            1800       ; Retry
            604800     ; Expire
            86400 )    ; Minimum TTL

    IN  NS  ns1.example.com.

ns1 IN  A   192.168.1.10
www IN  A   192.168.1.20
Field note

If you edit the zone later, increment the serial. A common failure mode is “the file is correct” but the daemon is still serving the old serial.

Step 4 : Start the daemon and confirm it loads configuration.
Commands
# RHEL/Arch (named)
sudo systemctl start named

# Debian (bind9)
sudo systemctl start bind9

Starting the service forces BIND to parse configuration and load zones. If the service fails, treat it as a configuration or permissions problem until proven otherwise.

DNS service started successfully.
Step 5 : Validate authoritative answers using dig.
Command
dig @localhost www.example.com

Query localhost directly to remove client-side resolver variables. A correct answer section confirms the daemon is responding and the zone is available.

;; QUESTION SECTION:
;www.example.com.        IN      A

;; ANSWER SECTION:
www.example.com.  86400  IN      A   192.168.1.20

Common breakpoints

Service fails to start

Treat this as a config, zone-path, or permissions issue. Confirm the zone file path matches the stanza in named.conf and validate the daemon status and logs before touching clients.

dig returns SERVFAIL or no answer

The daemon is reachable, but the zone did not load correctly. Re-check syntax in the zone file, confirm the serial is valid, and verify the zone file is readable by the service user.

dig works for localhost but clients cannot resolve

The server is healthy, but clients are not using it. Confirm the client resolver points to this host and that the network path to port 53 is open. Do not rewrite the zone until you confirm the traffic is reaching the daemon.

Zone changes do not appear after edits

Increment the zone serial and reload the service. A common failure mode is making correct edits without updating the serial, which results in stale answers.

Cleanup checklist

This lab is safe to leave in place if you want an internal resolver for future exercises. If you are resetting the system, stop the service and remove the zone artifacts you created.

Commands
# Stop the daemon
sudo systemctl stop named
# OR
sudo systemctl stop bind9

# Remove the zone file you created (choose the path you used)
sudo rm -f /var/named/example.com.zone
# OR
sudo rm -f /etc/bind/db.example.com
Success signal

The service is stopped cleanly and the zone file is removed from the path referenced by your configuration.

Reference

  • yum install bind : Installs BIND on RHEL-family systems.
  • apt install bind9 : Installs BIND on Debian/Ubuntu systems.
  • pacman -S bind : Installs BIND on Arch systems.
  • vim <file> : Edits configuration and zone files.
    • /etc/named.conf : Common BIND configuration path on RHEL/Arch.
    • /etc/bind/named.conf : Common BIND configuration path on Debian/Ubuntu.
    • /var/named/example.com.zone : Common forward zone path on RHEL-family systems.
    • /etc/bind/db.example.com : Common forward zone path on Debian/Ubuntu systems.
  • systemctl start <unit> : Starts the DNS service.
    • named : Common service name on RHEL/Arch.
    • bind9 : Common service name on Debian/Ubuntu.
  • dig @<server> <name> : Queries a specific DNS server directly.
    • @localhost : Forces the query to the local daemon.
  • systemctl stop <unit> : Stops the DNS service.
  • rm -f <path> : Removes the zone file created for the lab.
    • -f : Removes without prompting (and ignores missing files).