DNSSEC: Digital Signatures, Trust Chains, and DNS Authentication

1. Introduction to DNS Vulnerabilities

The Domain Name System (DNS) is the phone book of the internet, translating human-readable domain names (e.g., www.nepalbank.com) into IP addresses. However, standard DNS was designed for efficiency, not security. It lacks built-in mechanisms to verify that the data received is genuine.

The Threat: DNS Spoofing and Cache Poisoning

In a standard DNS query, a resolver asks an authoritative server for an IP address. An attacker can intercept this communication or inject fake responses into the DNS cache. This is known as DNS Spoofing or Cache Poisoning.

Scenario:

1. A user types www.esewa.com.
2. The local DNS resolver asks the authoritative server for the IP.
3. An attacker on the same network sends a fake response claiming www.esewa.com resolves to 192.168.1.100 (the attacker's IP).
4. If the resolver accepts this fake response and caches it, the user is redirected to the attacker's site, where they might be asked to enter their eSewa password.

DNSSEC (Domain Name System Security Extensions) solves this by allowing DNS data to be cryptographically signed.

2. Core Concepts of DNSSEC

DNSSEC is not a single protocol but a set of extensions to the DNS protocol. It provides three main services:

1. Data Origin Authentication: Verifying that the data came from the claimed source.
2. Data Integrity: Ensuring the data has not been altered in transit.
3. Authenticity: Confirming the identity of the signer.

It does not provide:

• Confidentiality: DNS queries and responses are still sent in clear text (unless combined with DNS-over-TLS or DNS-over-HTTPS).
• Availability: It does not prevent Denial of Service (DoS) attacks.

Key Components

• Resource Record (RR): The standard DNS data entry (e.g., A record, AAAA record).
• RRSIG (Resource Record Signature): A new record type that contains the digital signature of the original record.
• DNSKEY: A record type that holds the public keys used for signing and verification.
• DS (Delegation Signer): A record in the parent zone that contains the hash of the child zone's public key. This links the child zone to the parent zone.
• NSEC/NSEC3: Records used to prove the non-existence of a domain name (preventing "NXDOMAIN" spoofing).

3. The Chain of Trust

DNSSEC relies on a hierarchical trust model. The trust starts at the root of the DNS hierarchy and flows down to the specific domain.

graph TD
    A["Root Zone (.)"] -->|"DS Record"| B["TLD Zone (.com)"]
    B -->|"DS Record"| C["Domain Zone (esewa.com)"]
    C -->|"RRSIG"| D["Host Record (www.esewa.com)"]

1. Root Trust Anchor: The root zone is signed with a key that is hardcoded into the DNS resolvers (the "Trust Anchor").
2. TLD Signature: The root zone signs the TLD (e.g., .com). The .com zone contains a DS record that points to the public key of the esewa.com zone.
3. Domain Signature: The esewa.com zone signs its own records (like www) and provides a DS record to its parent (.com).
4. Validation: When a resolver receives a response for www.esewa.com, it checks the signature using the public key from esewa.com. It then verifies that the esewa.com key is trusted by checking the DS record in .com, and so on, up to the root.

4. How DNSSEC Works: The Validation Process

When a DNS resolver receives a DNS response with DNSSEC data, it performs the following steps:

sequenceDiagram
    participant User
    participant Resolver
    participant AuthoritativeServer
    participant Root
    participant TLD

    User->>Resolver: Query for www.nepalbank.com
    Resolver->>AuthoritativeServer: DNSSEC-enabled query
    AuthoritativeServer-->>Resolver: A record + RRSIG + DNSKEY
    Resolver->>Resolver: Verify RRSIG using DNSKEY
    Resolver->>TLD: Query for DS record of nepalbank.com
    TLD-->>Resolver: DS record
    Resolver->>Resolver: Verify DS matches DNSKEY hash
    Resolver->>Root: Query for DS record of .com
    Root-->>Resolver: DS record
    Resolver->>Resolver: Verify Root Trust Anchor
    Resolver-->>User: Secure response (103.21.244.10)

1. Check for RRSIG: Does the response contain an RRSIG record for the requested data?
2. Retrieve Public Key: The resolver fetches the DNSKEY record for the zone that signed the data.
3. Verify Signature: The resolver uses the public key to verify the digital signature in the RRSIG record against the original data.
4. Verify Chain of Trust:
   • The resolver checks if the DNSKEY used is valid.
   • It looks for a DS record in the parent zone.
   • It verifies that the hash of the DNSKEY matches the DS record.
   • This process repeats up the hierarchy until the Root Trust Anchor is reached.
5. Result:
   • Bogus: If any signature fails or the chain is broken, the resolver discards the data and returns an error (SERVFAIL).
   • Secure: If all signatures are valid, the data is considered authentic.
   • Insecure: If the zone is not signed, the data is treated as insecure (standard DNS behavior).

Visualizing the Packet Structure

A standard DNS response with DNSSEC includes additional records.

5. Cryptographic Algorithms

DNSSEC uses asymmetric cryptography (Public Key Infrastructure). The most common algorithms are:

• RSA/SHA-256: Uses RSA for signing and SHA-256 for hashing. Widely supported.
• ECDSA P-256: Uses Elliptic Curve Digital Signature Algorithm. Smaller keys and faster verification than RSA, increasingly preferred for mobile devices and IoT.

The signature process involves:

1. Hashing the DNS record data.
2. Encrypting the hash with the zone's Private Key.
3. Storing the result in the RRSIG record.

Verification involves:

1. Decrypting the RRSIG using the zone's Public Key.
2. Comparing the result with the hash of the received data.

6. Worked Example: Validating www.nepalbank.com

Let's trace the validation process for a user in Nepal accessing www.nepalbank.com.

1. Query: User's device asks local resolver: "What is the IP for www.nepalbank.com?"
2. Response: The authoritative server for nepalbank.com sends back:
   • A record: 103.21.244.10
   • RRSIG record: Signature of the A record.
   • DNSKEY record: Public key for nepalbank.com.
3. Local Verification:
   • Resolver calculates the hash of the A record.
   • Resolver uses the DNSKEY to verify the RRSIG.
   • Check 1: Is the signature valid? Yes.
4. Chain Verification:
   • Resolver needs to trust the DNSKEY for nepalbank.com.
   • It queries the .com TLD server for the DS record for nepalbank.com.
   • The .com server returns the DS record (a hash of the nepalbank.com public key).
   • Resolver compares the hash of the received DNSKEY with the DS record.
   • Check 2: Do they match? Yes.
5. TLD Verification:
   • Resolver needs to trust the .com server.
   • It queries the Root server for the DS record for .com.
   • Root server returns the DS record for .com.
   • Resolver verifies the .com DNSKEY against the Root DS record.
   • Check 3: Is the Root signature valid? Yes (using the hardcoded Root Trust Anchor).
6. Final Result: The resolver marks the response as Secure and returns 103.21.244.10 to the user.

If an attacker had tried to inject a fake IP, the signature would not match the public key, and the resolver would return a SERVFAIL error, blocking the attack.

7. DNS-Based Authentication of Named Entities (DANE)

DNSSEC is often used in conjunction with DANE (DNS-Based Authentication of Named Entities). DANE allows DNS to specify which certificates are valid for a domain.

• Use Case: HTTPS (TLS) connections.
• How it works: A domain owner publishes a TLSA record in their DNS zone. This record contains a hash of the server's TLS certificate.
• Benefit: When a browser connects to https://www.nepalbank.com, it can check the TLSA record to ensure the certificate presented by the server is the one authorized by the domain owner. This prevents Man-in-the-Middle attacks using rogue certificates.

sequenceDiagram
    participant Browser
    participant Resolver
    participant AuthServer
    participant BankServer

    Browser->>Resolver: DNS Query for www.nepalbank.com (TLSA)
    Resolver->>AuthServer: Query for TLSA record
    AuthServer-->>Resolver: TLSA Record (Hash of Cert) + RRSIG
    Resolver-->>Browser: TLSA Record (Verified)
    
    Browser->>BankServer: TLS Handshake (Connect)
    BankServer-->>Browser: Server Certificate
    Browser->>Browser: Compare Cert Hash with TLSA Record
    alt Match
        Browser->>BankServer: Secure Connection Established
    else Mismatch
        Browser->>Browser: Connection Refused (Security Alert)
    end

8. Advantages and Disadvantages

Advantages:

• Prevents DNS spoofing and cache poisoning.
• Provides a foundation for other security protocols like DANE.
• Global standard, widely supported by major ISPs and root servers.

Disadvantages:

• Key Management: Managing private keys is complex. If a private key is compromised, the entire zone is compromised.
• Key Rollover: Keys must be rotated periodically. If done incorrectly, it can cause outages.
• Packet Size: DNSSEC records increase the size of DNS responses, which can cause fragmentation issues with older resolvers.
• No DoS Protection: Attackers can still flood the DNS server with queries.

9. In the real world

1. Nepal Telecom (NTC) and Ncell: Major ISPs in Nepal are gradually deploying DNSSEC validation on their recursive resolvers. When you browse the web using NTC's Wi-Fi, their DNS servers verify that the IP addresses for sites like www.nepalbank.com or www.esewa.com are authentic. This protects customers from being redirected to phishing sites that mimic local banks.
2. Global Root Servers: The 13 root name servers (operated by ICANN) are all signed with DNSSEC. This means that every DNS query that starts from a trusted root is protected against tampering at the highest level of the internet hierarchy.
3. Email Security (SPF/DKIM/DMARC): While not directly DNSSEC, many email authentication systems rely on DNS records. DNSSEC ensures that these records (like SPF records) cannot be forged, strengthening the overall security of email communication for companies like Daraz or local banks.

10. Exam tip

• Focus on the Chain of Trust: Exams often ask you to explain how a resolver validates a record. Be ready to draw the hierarchy (Root -> TLD -> Domain) and explain the role of DS and DNSKEY records in linking them.
• Know the Record Types: Memorize the purpose of RRSIG, DNSKEY, DS, and NSEC. A common question is "What record proves the non-existence of a domain?" (Answer: NSEC/NSEC3).
• Limitations: Always mention that DNSSEC does not provide confidentiality or prevent DoS attacks. This is a common trap in multiple-choice questions.
• DANE: Be prepared to explain how DNSSEC can be used to validate TLS certificates (DANE), as this connects DNS security to web security.

In the real world

• eSewa and Khalti: Use DNSSEC to prevent phishing attacks where attackers spoof eSewa’s or Khalti’s domain (e.g., eSewa.com → eSewa.fake.com). Their DNS records are signed to ensure users reach the legitimate payment gateway.
• Nepal Rastra Bank (NRB) and NEPSE: Critical financial and stock exchange domains (e.g., nepalbank.com, nepse.org.np) deploy DNSSEC to authenticate transactions and prevent DNS-based fraud during online banking or trading.
• NTC and Ncell: Telecom providers use DNSSEC to secure their DNS infrastructure, ensuring customers connect to legitimate portals (e.g., ntc.net.np, ncell.com.np) instead of attacker-controlled mirrors during login or service access.