Early computer networks relied on numeric IP addresses for communication among a limited number of hosts. As the number of connected devices grew, memorizing these addresses became impractical. UNIX introduced a local hosts file mapping hostnames to IPs, later adopted by Linux and Windows. When central file distribution proved unscalable, the Domain Name System emerged to provide a hierarchical, distributed resolution mechanism.

Core Concept of DNS

DNS (Domain Name System) is a globally distributed database that maps domain names to IP addresses. It spares users from remembering raw IP strings. The translation process from hostname to IP is called name resolution. DNS operates over UDP, listening on port 53. Its namespace resembles an inverted tree up to 127 levels deep, each node labeled with up to 63 characters.

Resolution Workflow

When resolving a name:

1. The client checks its cache, then the local hosts file.
2. If unresolved, it sends a request to a DNS resolver.
3. The resolver checks its own cache; if found, it replies immediately.
4. Otherwise, it searches its zone data.
5. Failing that, it forwards the query to a root server, then iteratively follows referrals through TLD and authoritative servers until resolution completes.
6. Results are cached before returning to the client.
7. If no match exists, an error is returned.

Server Categories

• Primary server: Holds the authoritative source data for zones.
• Secondary server: Receives updates via zone transfers from the primary; serves client queries.
• Caching resolver: Performs recursive lookups on behalf of clients, caching results.
• Forwarder: Redirects queries outside its authority to designated servers with out caching responses.

Record Types Overview

Common resource records include A (address), AAAA (IPv6 address), CNAME (alias), MX (mail exchange), PTR (reverse lookup), and others.

Naming Rules

Allowed characters: letters a–z, digits 0–9, hyphen -. Labels may contain up to 63 bytes. Nonconforming names are technically accepted but discouraged; they can be permitted by disabling name checks in the configuration (check-name ignore).

Diagnostic Utilities

Install tools via package manager:

yum install bind-utils -y

Utilities: dig, nslookup, host for querying and troubleshooting DNS.

Evolving Approaches

Lightweight Resolver: DNSMASQ

DNSMASQ combines DNS and DHCP for small-scale environments. It resolves locally scoped domains not published globally and integrates DHCP-assigned addresses into DNS dynamically or statically. Some infrastructures deploy it on every host to improve resolution speed and reduce upstream load.

HTTPDNS

In regions with complex routing and inconsistent DNS caching, HTTPDNS bypasses traditional resolvers by returning IPs via HTTP requests, enabling precise client steering. This suits mobile apps where client behavior can be influenced.

Recursive vs Iterative Queries

• Recursive: Client asks resolver; resolver handles entire lookup chain and returns final answer.
• Iterative: Resolver returns the best referral it knows; client continues querying next server.

Example:

• Recursive: Client → DNS-A finds record → reply.
• Recursive fallback: Client → DNS-A → DNS-B → … → reply.
• Iterative: Client → DNS-A (no record) responds: "Ask DNS-B" → client queries DNS-B.

Primary–Secondary Deployment Example

Environment: CentOS 6.8, nodes 192.168.137.13 (primary), 192.168.137.14 (secondary).

Enable Aliyun EPEL:

rpm -ivh http://mirrors.aliyun.com/epel/epel-release-latest-6.noarch.rpm

Primary Configuration

Install packages:

yum install -y bind-utils bind bind-devel bind-chroot

Configure /etc/named.conf:

options {
  version "1.1.1";
  listen-on port 53 { any; };
  directory "/var/named/chroot/etc/";
  pid-file "/var/named/chroot/var/run/named/named.pid";
  allow-query { any; };
  dump-file "/var/named/chroot/var/log/binddump.db";
  statistics-file "/var/named/chroot/var/log/named_stats";
  zone-statistics yes;
  memstatistics-file "log/mem_stats";
  empty-zones-enable no;
  forwarders { 202.106.196.115; 8.8.8.8; };
};

key "rndc-key" {
  algorithm hmac-md5;
  secret "Eqw4hClGExUWeDkKBX/pBg==";
};

controls {
  inet 127.0.0.1 port 953
    allow { 127.0.0.1; } keys { "rndc-key"; };
};

logging {
  channel warning {
    file "/var/named/chroot/var/log/dns_warning" versions 10 size 10m;
    severity warning;
    print-category yes; print-severity yes; print-time yes;
  };
  channel general_dns {
    file "/var/named/chroot/var/log/dns_log" versions 10 size 100m;
    severity info;
    print-category yes; print-severity yes; print-time yes;
  };
  category default { warning; };
  category queries { general_dns; };
};

include "/var/named/chroot/etc/view.conf";

Define key in /etc/rndc.key and /etc/rndc.conf identically.

Zone config in /var/named/chroot/etc/view.conf:

view "MainView" {
  zone "example.net" {
    type master;
    file "example.net.zone";
    allow-transfer { 192.168.137.14; };
    notify yes;
    also-notify { 192.168.137.14; };
  };
};

Zone file /var/named/chroot/etc/example.net.zone:

$ORIGIN .
$TTL 3600
example.net IN SOA ns1.example.net. admin.example.net. (
  2024100101 ; serial yyyymmddnn
  900        ; refresh
  600        ; retry
  86400      ; expire
  3600       ; minimum
)
            NS  ns1.example.net.
$ORIGIN example.net.
host1     A   10.0.0.11
ns1       A   10.0.0.10

Set ownership and start service:

cd /var && chown -R named:named named/
service named start
chkconfig named on

Test locally:

dig @127.0.0.1 host1.example.net

Secondary Configuration

Install same packages. Reuse identical named.conf, rndc.key, rndc.conf.

Zone config in /var/named/chroot/etc/view.conf:

view "SecView" {
  zone "example.net" {
    type slave;
    masters { 192.168.137.13; };
    file "slave.example.net.zone";
  };
};

Start service similarly. Zone data will appear automatically under /var/named/chroot/etc/.

Adding Records

On primary, edit zone file, increment serial, run rndc reload.

• A record: web A 192.168.5.20
• CNAME: alias CNAME web.example.net.
• MX: mail MX 10 mailhost.example.net.
• PTR (reverse): Define reverse zone 5.168.192.in-addr.arpa with 20 IN PTR web.example.net.

Ensure proper permissions and reload.

Load Balancing via DNS

Add multiple A records for same name:

host1 A 192.168.5.21
host1 A 192.168.5.22

Clients receive round-robin responses.

Split-Horizon Views (Smart DNS)

Define ACLs in named.conf:

acl subnetA { 192.168.137.13; };
acl subnetB { 192.168.137.14; };

Create views in view.conf:

view "ViewForSubnetA" {
  match-clients { subnetA; };
  zone "svc.example.org" {
    type master;
    file "svcA.example.org.zone";
  };
};
view "ViewForSubnetB" {
  match-clients { subnetB; };
  zone "svc.example.org" {
    type master;
    file "svcB.example.org.zone";
  };
};

Separate zone files return different IPs per cleint group.

Enterprise-Grade Design

Hardware: ≥12 cores CPU, ≥16 GB RAM, gigabit networking.

System tuning: Disable firewall and SELinux, raise ulimit values.

High availability: Deploy DNS servers across racks/switches, use multi-IDC clusters, custom health-check scripts instead of basic port checks.

Client-side failover via periodic reachability tests.

Performance scaling: Horizontal scaling behind LVS based on benchmarks; optional front-end caching layer if DNS-based load balancing isn’t used elsewhere.

Benchmarking: Use BIND's queryperf:

cd /usr/local/src/bind-9.9.9-P1/contrib/queryperf
./configure && make
cp queryperf /usr/bin

Prepare input file listing queries, run:

queryperf -d queries.txt -s 192.168.137.13

Monitoring: Track system metrics, loopback binding status, zone serial consistency, response times, QPS, and availability via synthetic probes.