DNS, Name Servers & Configuration: Domains, Zones, Records & Troubleshooting

TAKEAWAYS:

• DNS translates domain names (e.g., esewa.com.np) to IP addresses (e.g., 103.22.16.10) using a hierarchical, distributed database of name servers and resource records.
• A zone file defines a domain’s DNS data, including A records (IPv4), MX records (mail servers), and CNAME records (aliases), stored on a primary name server and replicated to secondary servers for redundancy.
• DNS resolution follows a recursive query process: resolver → root → TLD → authoritative servers, with caching at each step to improve speed.
• Troubleshooting involves checking nslookup, dig, or host commands, verifying zone files for syntax errors, and testing connectivity between name servers.
• Security risks include DNS spoofing (cache poisoning), DDoS attacks on DNS servers, and misconfigured records causing downtime.
• Real-world impact: Every app (e.g., WhatsApp, Daraz) and service (e.g., Ncell, NTC) relies on DNS to route users to the correct servers—misconfigurations can break services entirely.

1. Why DNS? The Problem It Solves

Imagine typing daraz.com.np instead of 103.22.16.10 every time you want to shop online. DNS makes this possible by acting as the "phonebook of the internet", translating human-readable domain names into machine-readable IP addresses.

sequenceDiagram
    participant User
    participant Browser
    participant LocalDNS
    participant RootDNS
    participant ComTLD
    participant EsewaDNS
    participant WebServer

    User->>Browser: Types "esewa.com.np"
    Browser->>LocalDNS: DNS Query (esewa.com.np)
    LocalDNS->>RootDNS: Query for .np TLD
    RootDNS-->>LocalDNS: Redirect to .np TLD
    LocalDNS->>ComTLD: Query for esewa.com.np
    ComTLD-->>LocalDNS: Redirect to Authoritative (ns1.esewa.com)
    LocalDNS->>EsewaDNS: Query for esewa.com.np
    EsewaDNS-->>LocalDNS: A Record (103.22.16.10)
    LocalDNS-->>Browser: IP Address (103.22.16.10)
    Browser->>WebServer: HTTP Request
    WebServer-->>Browser: HTML Response

DNS resolution flow for esewa.com.np (IPv4) with caching at each step

How DNS Works: A Step-by-Step Trace

When you type khalti.com in your browser, this happens:

1. Your local resolver (e.g., ISP’s DNS server) checks its cache for khalti.com.
2. If not found, it sends a recursive query to the root name server (.).
3. The root server replies with the TLD (Top-Level Domain) server for .com.
4. The TLD server points to Khalti’s authoritative name servers (e.g., ns1.khalti.com).
5. The authoritative server returns the A record (IPv4 address) or AAAA record (IPv6) for khalti.com.
6. Your browser connects to the IP address and loads the website.

2. DNS Architecture: The Hierarchy of Name Servers

DNS uses a distributed, hierarchical system to avoid a single point of failure. The structure is:

3. DNS Records: The Building Blocks of a Zone File

A zone file is a text file (e.g., esewa.com.np.zone) that defines how a domain should resolve. Key record types:

Worked Example: Configuring DNS for a Bank (e.g., Nabil Bank) Suppose Nabil Bank wants:

• nabilbank.com to point to 192.0.2.1.
• mail.nabilbank.com to handle emails (MX record).
• www.nabilbank.com to alias to nabilbank.com.

Their zone file (nabilbank.com.zone) would look like:

$TTL 86400
@ IN SOA ns1.nabilbank.com. admin.nabilbank.com. (
    2023101501 ; Serial
    3600       ; Refresh
    1800       ; Retry
    604800     ; Expire
    86400      ; Minimum TTL
)
@ IN NS ns1.nabilbank.com.
@ IN A 192.0.2.1
www IN CNAME @
mail IN A 192.0.2.2
@ IN MX 10 mail.nabilbank.com.

4. Primary vs. Secondary Name Servers

Why Use Secondaries?

• Redundancy: If the primary fails, secondaries take over.
• Load Balancing: Distributes query load.
• Geographic Distribution: Secondaries in different regions reduce latency.

5. DNS Resolution Process: A Deep Dive

When you type pathao.com, your computer performs a recursive resolution:

stateDiagram-v2
    [*] --> QueryStart
    QueryStart --> ClientQuery: User types `daraz.com.np`
    ClientQuery --> LocalCache: Check local resolver cache
    LocalCache --> CacheHit: Found?
    CacheHit --> ReturnIP: Yes → Return IP
    CacheHit --> RootQuery: No → Query Root (.)
    RootQuery --> TLDQuery: Root redirects to `.np` TLD
    TLDQuery --> AuthQuery: TLD redirects to `ns1.daraz.com.np`
    AuthQuery --> ReturnData: Authoritative server returns A/AAAA record
    ReturnData --> Client: Browser connects to IP
    Client --> [*]

1. Local Cache Check: Your OS/browser checks if it has cached pathao.com.
2. Resolver Query: If not cached, your recursive resolver (e.g., 8.8.8.8 or 1.1.1.1) queries:
   • Root Server → Returns TLD server for .com.
   • TLD Server → Returns Pathao’s authoritative servers (ns1.pathao.com).
   • Authoritative Server → Returns A or AAAA record.
3. Response: The resolver caches the result (TTL-based) and returns it to you.

Caching Example:

• If dig @8.8.8.8 pathao.com returns 192.0.2.3 with a TTL of 3600 seconds (1 hour), your resolver will use this IP for the next hour, even if Pathao’s IP changes.

6. Common DNS Misconfigurations and Fixes

Worked Example: Fixing a Broken MX Record for NEPSE Suppose NEPSE’s nepse.com.np has an MX record pointing to a non-existent server (mail.nepse.com), causing emails to fail. The fix:

1. Check current records:

   dig MX nepse.com.np
   

   Output:

   ;; ANSWER SECTION:
   nepse.com.np.    3600    IN    MX    10 mail.nepse.com.
   

2. Verify mail.nepse.com exists:

   dig A mail.nepse.com
   

   Output (error): mail.nepse.com: No answer
3. Solution: Update the zone file to point to the correct mail server (e.g., smtp.nepse.com):

   nepse.com.np.    IN    MX    10 smtp.nepse.com.
   smtp.nepse.com.  IN    A    192.0.2.4
   

4. Force a zone transfer to secondaries:

   rndc refresh nepse.com.np
   

7. DNS Tools: Commands Every Admin Should Know

Worked Example: Diagnosing a Slow Website (e.g., NTC’s ntc.net.np)

1. Check if DNS is resolving:

   dig A ntc.net.np
   

   Output:

   ;; ANSWER SECTION:
   ntc.net.np.    86400    IN    A    192.0.2.5
   

2. Test latency to the IP:

   ping 192.0.2.5
   

   Output (high latency):

   PING 192.0.2.5 (192.0.2.5) 56(84) bytes of data.
   64 bytes from 192.0.2.5: icmp_seq=1 ttl=55 time=450 ms
   

3. Conclusion: DNS resolution is fast (TTL=86400), but the network path to the IP is slow. Possible fixes:
   • Use a CDN (e.g., Cloudflare) to cache content closer to users.
   • Check for routing issues with traceroute 192.0.2.5.

8. Security in DNS: Protecting Against Attacks

Real-World Example: DNSSEC in Nepal

• Nepal’s .np domain uses DNSSEC to prevent spoofing.
• When you visit ntc.net.np, your resolver checks the digital signature of the DNS response to ensure it’s authentic.

9. DNS in the Real World

DNS is invisible but critical to every internet service. Here’s how Nepalese and global companies use it:

1. eSewa (esewa.com.np)

   • A Records: Maps esewa.com.np to its web server IPs (103.22.16.10).
   • MX Records: Routes emails to mail.esewa.com (priority 10).
   • CNAME: api.esewa.com aliases to esewa.com.np for backend services.
   • Why it matters: If eSewa’s DNS misconfigures its MX record, users can’t receive payment confirmations.

2. Ncell (ncell.com.np)

   • Uses load-balanced DNS: Multiple A records point to different web servers (e.g., 192.0.2.1, 192.0.2.2) for high availability.
   • Anycast DNS: Root servers for .np use Anycast to distribute queries globally, reducing latency for international users.

3. Daraz (daraz.com.np)

   • Geographic DNS: Returns different IPs based on user location (e.g., 192.0.2.10 for Kathmandu, 192.0.2.20 for Pokhara) via GeoDNS.
   • CDN Integration: Uses Cloudflare’s DNS to cache static content (e.g., product images) at edge locations.

4. NTC (ntc.net.np)

   • Critical Infrastructure: NTC’s DNS must be highly available—if ntc.net.np resolves incorrectly, internet access for millions fails.
   • BGP + DNS: NTC’s routers use BGP to announce routes, but DNS translates ntc.net.np to the correct gateway IP.

5. NEPSE (nepse.com.np)

   • Financial Security: NEPSE’s MX records must be accurate to prevent email fraud (e.g., phishing for stock trade confirmations).
   • SPF/DKIM Records: Uses TXT records to verify legitimate emails:

     nepse.com.np. IN TXT "v=spf1 ip4:192.0.2.4 ~all"
     

10. Hands-On: Configuring a Primary DNS Server (BIND)

Let’s set up a primary DNS server for example.edu.np on Ubuntu using BIND.

Step 1: Install BIND

sudo apt update
sudo apt install bind9

Step 2: Configure the Zone File

Edit /etc/bind/db.example.edu.np:

$TTL 86400
@   IN  SOA ns1.example.edu.np. admin.example.edu.np. (
                2023101501 ; Serial
                3600       ; Refresh
                1800       ; Retry
                604800     ; Expire
                86400      ; Minimum TTL
)
@   IN  NS  ns1.example.edu.np.
@   IN  A   192.168.1.10
www IN  CNAME   @
mail    IN  A   192.168.1.20
@   IN  MX  10 mail.example.edu.np.

Step 3: Update BIND Configuration

Edit /etc/bind/named.conf.local:

zone "example.edu.np" {
    type master;
    file "/etc/bind/db.example.edu.np";
    allow-transfer { 192.168.1.20; }; // Secondary server IP
};

Step 4: Restart BIND

sudo systemctl restart bind9

Step 5: Test DNS

dig @localhost example.edu.np

Expected output:

;; ANSWER SECTION:
example.edu.np.    86400    IN    A    192.168.1.10

Exam Tip

1. Understand the Hierarchy: Always draw the root → TLD → authoritative flow. Examiners love questions like: "Trace how dig google.com resolves from a recursive resolver." Answer: Root → .com TLD → Google’s authoritative servers.

2. Zone File Syntax: Memorize the SOA record format and common records (A, MX, CNAME). A typical exam question: *"Write the zone file for college.edu.np with:

   • Web server at 192.168.1.10
   • Mail server mail.college.edu.np at 192.168.1.20
   • Alias www to @"* Answer: Use the template from Section 3 above.

3. Troubleshooting Scenarios: Be ready to diagnose issues like:

   • "A website loads but emails fail. What record is missing?" → MX record.
   • "DNS resolution takes 5 seconds. Why?" → High TTL or slow authoritative server.

4. Security Questions: Expect:

   • "How does DNSSEC prevent cache poisoning?" → Digital signatures validate responses.
   • "Why use secondary DNS servers?" → Redundancy and load balancing.

5. Real-World Applications: Relate concepts to Nepalese services:

   • "How does Ncell use DNS for load balancing?" → Multiple A records for web servers.
   • "Why might eSewa’s DNS fail during a power outage?" → Primary server downtime (no secondaries).

Key Formulas and Shortcuts

Common Pitfalls

1. Circular CNAMEs: Never do A CNAME B and B CNAME A—it creates a loop.
2. Missing SOA Record: Without an SOA, the zone file is invalid.
3. Incorrect TTL: Too high = slow updates; too low = excessive queries.
4. Firewall Blocking Port 53: DNS won’t work if TCP/UDP 53 is blocked.
5. Forgetting Trailing Dot: In zone files, example.com must be example.com. (FQDN).

Summary Checklist

Before the exam, ensure you can:

• Explain the DNS hierarchy (root → TLD → authoritative).
• Write a zone file for a given domain (e.g., university.edu.np).
• Trace a DNS query step-by-step (use the sequence diagram).
• Fix common misconfigurations (missing MX, circular CNAME).
• Describe DNS security risks (spoofing, DDoS) and mitigations.
• Configure BIND for a primary/secondary setup.