DNS Fundamentals and FQDN Structure

The Domain Name System translates human-readable hostnames into machine-routable IP addresses. A Fully Qualifide Domain Name (FQDN) follows a strict hierarchical structure composed of a hostname and a domain suffix.

• Root Domain: Represented by a trailing dot (.) at the end of an FQDN (e.g., app.corp.net.). It sits at the apex of the DNS tree.
• Top-Level Domain (TLD): The rightmost label before the root dot (e.g., net, org, io). TLDs categorize domains by purpose, organization type, or geographic region.
• Second-Level Domain (SLD): The label immediately left of the TLD (e.g., corp in corp.net). This segment is registered and managed by the domain owner.

Query Resolution Models

DNS resolvers operate using two distinct query mechanisms:

• Recursive Resolution: The client delegates the entire lookup process to a local resolver. The resolver checks its cache, and if missing, traverses the DNS hierarchy on behalf of the client until it retrieves the final IP address, which it then returns and caches.
• Iterative Resolution: The resolver contacts the root or TLD servers directly. Instead of fetching the final answer, those servers respond with referrals (IP addresses of the next authoritative servers). The resolver continues querying downstream servers step-by-step until it reaches the authoritative source for the requested domain.

Mapping Directions

• Forward Lookup: Converts an FQDN into its corresponding IPv4 or IPv6 address.
• Reverse Lookup: Maps an IP address back to its associated hostname using the special in-addr.arpa (IPv4) or ip6.arpa (IPv6) namepsace.

Environment Preparation

This deployment uses Rocky Linux. Two nodes are required:

• DNS Host: ns1.infra.local (IP: 172.16.50.10)
• Client Node: workstation.infra.local (IP: 172.16.50.25)

1. Package Deployment

Install the BIND nameserver and diagnostic utilities on the DNS host:

sudo dnf install bind bind-utils -y

2. Core Service Configuration

Edit the primary daemon configuration at /etc/named.conf. Adjust network binding and access control directives:

options {
    listen-on port 53 { any; };
    // listen-on-v6 port 53 { ::1; };  // Disabled if IPv6 is unused
    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";
    recursing-file  "/var/named/data/named.recursing";
    secroots-file   "/var/named/data/named.secroots";
    allow-query     { any; };
    recursion yes;
    dnssec-validation auto;
};

Setting listen-on and allow-query to any permits the daemon to accept requests from all network interfaces and client subnets. Restrict these values to specific CIDR blocks in production environments.

3. Zone Declaration

Define authoritative zones in /etc/named.rfc1912.zones. This file maps domain namespaces to their respective data files and specifies server roles.

zone "infra.local" IN {
    type master;
    file "db.forward.infra";
    allow-update { none; };
};

zone "50.16.172.in-addr.arpa" IN {
    type master;
    file "db.reverse.172";
    allow-update { none; };
};

The reverse zone label must invert the network octets. For a 172.16.50.0/24 subnet, the arpa suffix becomes 50.16.172.in-addr.arpa.

4. Forward Zone Data

Navigate to the working directory and duplicate the default template while preserving ownership and permissions:

cd /var/named
sudo cp -p named.localhost db.forward.infra

Modify db.forward.infra to establish SOA, NS, and A records:

$TTL 1D
@   IN SOA  ns1.infra.local. admin.infra.local. (
                    2024102501  ; Serial
                    3H          ; Refresh
                    15M         ; Retry
                    1W          ; Expire
                    1D )        ; Minimum TTL
    IN  NS      ns1.infra.local.
ns1 IN  A       172.16.50.10
web IN  A       172.16.50.10
app IN  A       172.16.50.11

5. Reverse Zone Data

Clone the empty template for PTR mapping:

sudo cp -p named.empty db.reverse.172

Update db.reverse.172 with pointer records:

$TTL 1D
@   IN SOA  ns1.infra.local. admin.infra.local. (
                    2024102501  ; Serial
                    3H          ; Refresh
                    15M         ; Retry
                    1W          ; Expire
                    1D )        ; Minimum TTL
    IN  NS      ns1.infra.local.
10  IN  PTR     ns1.infra.local.
10  IN  PTR     web.infra.local.
11  IN  PTR     app.infra.local.

6. Static Web Content Preparation

Create document roots and placeholder pages to simulate hosted services:

sudo mkdir -p /var/www/{portal,api}
echo "<h1>Portal Service Active</h1>" | sudo tee /var/www/portal/index.html
echo "<h1>API Gateway Online</h1>" | sudo tee /var/www/api/index.html

7. Service Activation

Validate configuration syntax, adjust SELinux contexts if enforced, and start the daemon:

sudo named-checkconf
sudo named-checkzone infra.local /var/named/db.forward.infra
sudo named-checkzone 50.16.172.in-addr.arpa /var/named/db.reverse.172
sudo systemctl enable --now named
sudo firewall-cmd --permanent --add-service=dns
sudo firewall-cmd --reload

Client Network Adjustment and Validation

On the client node, route DNS queries to the newly deployed server by modifying the NetworkManager connection profile:

sudo vi /etc/NetworkManager/system-connections/eth0.nmconnection

Locate the [ipv4] section and apply the following parameters:

[ipv4]
method=auto
dns=172.16.50.10;
ignore-auto-dns=true

Reload the network configuration and flush the resolver cache:

sudo nmcli connection reload
sudo nmcli connection up eth0
sudo resolvectl flush-caches

Execute resolution tests and HTTP requests to confirm end-to-end functionality:

dig web.infra.local +short
nslookup 172.16.50.11
curl http://web.infra.local