DNS: Servers, Zones, Records, Security & Virtual Hosting

TAKEAWAYS:

• DNS translates human-readable domain names (e.g., esewa.com.np) into machine-readable IP addresses (e.g., 103.10.10.10) using a hierarchical, distributed database.
• DNS servers are classified into primary (authoritative), secondary (slave), and caching (resolver) types, each with distinct roles in resolving queries.
• Zone transfers (AXFR/IXFR) synchronize DNS data between primary and secondary servers, ensuring redundancy and load balancing.
• DNS record types (A, AAAA, MX, CNAME, NS, TXT, SOA) define how data is stored and resolved, with each serving a specific purpose (e.g., MX for email routing).
• DNS security relies on DNSSEC (Domain Name System Security Extensions) to prevent spoofing and cache poisoning via digital signatures.
• Virtual hosting (name-based or IP-based) allows a single server to host multiple websites, with name-based being more scalable but less secure than IP-based.

1. What is DNS? The Internet’s Phonebook

DNS stands for Domain Name System, the backbone of the internet’s naming system. Without DNS, you’d have to memorize IP addresses like 103.10.10.10 instead of typing esewa.com.np. It’s a distributed, hierarchical database that maps domain names to IP addresses and manages other records (e.g., email servers, load balancers).

How DNS Works: A Step-by-Step Trace

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

1. Local Cache Check: Your device checks its local DNS cache (stored in hosts file or browser).
2. Recursive Resolver Query: If not found, your request goes to a recursive DNS resolver (e.g., Ncell’s 10.10.10.10 or Google’s 8.8.8.8).
3. Root Server: The resolver queries the root DNS server (.) to find the Top-Level Domain (TLD) server for .com.
4. TLD Server: The .com server directs the resolver to the authoritative name server for khalti.com.
5. Authoritative Server: The name server returns the A record (IP address) for khalti.com.
6. Response: The resolver caches the result and sends it back to your device.

sequenceDiagram
    participant User
    participant LocalCache
    participant RecursiveResolver
    participant RootServer
    participant TLDServer
    participant AuthoritativeServer

    User->>LocalCache: khalti.com?
    LocalCache-->>User: Not found
    User->>RecursiveResolver: khalti.com?
    RecursiveResolver->>RootServer: .com?
    RootServer-->>RecursiveResolver: TLD: .com server IP
    RecursiveResolver->>TLDServer: khalti.com?
    TLDServer-->>RecursiveResolver: Authoritative: ns1.khalti.com
    RecursiveResolver->>AuthoritativeServer: khalti.com A record?
    AuthoritativeServer-->>RecursiveResolver: 103.10.10.20
    RecursiveResolver-->>User: 103.10.10.20 (cached)

2. DNS Server Types: Roles and Responsibilities

DNS servers are categorized based on their function:

Why Use Secondary Servers?

• Redundancy: If the primary server fails, secondaries take over.
• Load Balancing: Distributes query load.
• Geographic Distribution: Secondaries can be hosted in different regions (e.g., Kathmandu vs. Pokhara).

Worked Example: Ncell’s DNS Setup Ncell uses a primary-secondary DNS pair:

• Primary: ns1.ncell.com.np (hosts zone files for ncell.com.np).
• Secondary: ns2.ncell.com.np (replicates data via zone transfer every 2 hours).
• If ns1 crashes, ns2 answers queries until ns1 recovers.

3. DNS Zone Transfers: Keeping Servers in Sync

A zone transfer (AXFR: Asynchronous Xfer or IXFR: Incremental Xfer) copies DNS zone data from a primary to a secondary server.

How It Works

1. The secondary server sends a SOA query to the primary to check for updates.
2. If the serial number in the SOA record has changed, the primary initiates a transfer.
3. AXFR: Transfers the entire zone file (inefficient for large zones).
4. IXFR: Transfers only changed records (faster, used by modern DNS servers like BIND).

sequenceDiagram
    participant SecondaryServer
    participant PrimaryServer

    SecondaryServer->>PrimaryServer: SOA Query (Check serial)
    PrimaryServer-->>SecondaryServer: Serial=2024051501
    SecondaryServer->>PrimaryServer: Request IXFR
    PrimaryServer-->>SecondaryServer: Incremental updates (only changes)

When is Zone Transfer Used?

• After manual updates to DNS records (e.g., changing esewa.com.np to point to a new server).
• During DNS failover (e.g., if the primary server is down).

Security Risk: Zone Walking

• Attackers can exploit misconfigured servers to enumerate all domains in a zone.
• Fix: Restrict zone transfers to trusted IPs using allow-transfer in BIND.

4. DNS Record Types: The Building Blocks

DNS records store different types of data. Here are the most important ones:

Worked Example: NEPSE’s DNS Records NEPSE (nepse.com.np) uses:

• A Record: nepse.com.np → 192.168.1.100
• MX Record: nepse.com.np → mail.nepse.com.np (for emails)
• CNAME: www.nepse.com.np → nepse.com.np (redirects www to root)
• TXT Record: SPF record to prevent email spoofing.

5. DNS Security: Preventing Attacks

DNS is a prime target for attacks like:

• DNS Spoofing (Cache Poisoning): Fake records redirect users to malicious sites.
• DNS Amplification Attacks: Attackers exploit open resolvers to flood targets.
• Domain Hijacking: Attackers change DNS records to steal traffic.

DNSSEC: Securing DNS with Digital Signatures

DNSSEC adds cryptographic signatures to DNS records to verify authenticity.

How DNSSEC Works:

1. Each zone has a Zone Signing Key (ZSK) and Key Signing Key (KSK).
2. Records are signed with the ZSK, and the ZSK is signed by the KSK.
3. Resolvers verify signatures using the public key stored in DNSKEY records.

stateDiagram-v2
    [*] --> Resolver: Queries DNS
    Resolver --> Authoritative: Requests Record
    Authoritative --> Resolver: Signed Record + DNSKEY
    Resolver --> TrustAnchor: Validates with Root KSK
    TrustAnchor --> Resolver: Verifies Signature
    Resolver --> User: Returns Secure Response

Real-World Example: Google’s DNSSEC Google Public DNS (8.8.8.8) supports DNSSEC, preventing attacks like:

• Redirecting esewa.com.np to a fake login page.
• Spoofing khalti.com to steal payment details.

6. Virtual Hosting: Serving Multiple Websites on One Server

Virtual hosting allows a single server to host multiple websites. Two methods:

Worked Example: Daraz’s Virtual Hosting

Daraz (daraz.com.np) uses name-based virtual hosting:

• A single server (103.10.10.50) hosts:
  • daraz.com.np (main site)
  • www.daraz.com.np (CNAME alias)
  • blog.daraz.com.np (separate subdomain)
• The web server (Apache/Nginx) uses the Host header to serve the correct site.

Proxy ACL (Access Control List)

• Restricts which IPs can access certain virtual hosts.
• Example: Only allow 192.168.1.0/24 to access admin.daraz.com.np.

classDiagram
    class Server {
        +IP: 103.10.10.50
        +Hosts: daraz.com.np, blog.daraz.com.np
    }
    class Apache {
        +Uses Host header
        +VirtualHost directive
    }
    class User {
        +Requests daraz.com.np
    }
    User --> Apache : HTTP Request (Host: daraz.com.np)
    Apache --> Server : Serves correct site

7. Real-World Applications of DNS

Example 1: eSewa’s DNS Setup

• Primary DNS: ns1.esewa.com.np (hosts all records).
• Secondary DNS: ns2.esewa.com.np (replicates via IXFR every hour).
• Records Used:
  • A for esewa.com.np → 103.10.10.10
  • MX for email routing to mail.esewa.com.np
  • TXT for SPF/DKIM to prevent email fraud.
• Why? Ensures high availability (if one server fails, the other takes over).

Example 2: Ncell’s Load Balancing with DNS

• Ncell uses round-robin DNS to distribute traffic:
  • ncell.com.np resolves to:
    • 103.10.10.1 (Server 1)
    • 103.10.10.2 (Server 2)
  • Each request alternates between servers, balancing load.

Example 3: Google’s Global DNS (Anycast)

• Google uses Anycast DNS to route queries to the nearest server:
  • A request to 8.8.8.8 is answered by the closest Google DNS server (e.g., Kathmandu vs. Singapore).
• Benefit: Faster response times and redundancy.

Exam Tip: How to Score Full Marks

1. Define Clearly: Always start with a precise definition (e.g., "DNS is a distributed hierarchical database that translates domain names to IP addresses").
2. Use Diagrams: Draw sequence diagrams for DNS lookups and state diagrams for DNSSEC validation.
3. Compare Tables: For virtual hosting, use a pros/cons table (name-based vs. IP-based).
4. Real-World Links: Relate answers to Nepali examples (eSewa, Ncell, Daraz) or global examples (Google DNS, Anycast).
5. Security Focus: Always mention DNSSEC when discussing security.
6. Worked Examples: Solve zone transfer scenarios (e.g., "If the SOA serial changes from 2024051501 to 2024051502, what happens?").

Common Pitfalls to Avoid:

• Confusing AXFR (full transfer) and IXFR (incremental).
• Forgetting TTL (Time to Live) in record explanations.
• Not mentioning SOA records in zone transfer questions.