DNS - Domain Name System

The Domain Name System is a hierarchical and decentralized naming system used to translate human-friendly domain names (e.g.,www.example.com) into IP addresses (e.g., 192.0.2.1) that computers use to identify each other on a given network.

Needless to say, DNS is essential for the functioning of the internet as it allows users to access websites and services using easy-to-remember domain names instead of numerical IP addresses.

The Key Components of the DNS protocol:

  • Domain Names: Human-readable addresses (e.g., example.com).
  • IP Addresses: Numerical addresses used by computers (e.g., 192.0.2.1).
  • DNS Resolver: A server that receives DNS queries from client machines and resolves them into IP addresses.
  • Root Name Servers: The top-level DNS servers that direct queries to the appropriate top-level domain (TLD) name servers.
  • Top-Level Domain (TLD) Servers: Servers that manage domains within a specific TLD (e.g., .com, .org).
  • Authoritative Name Servers: Servers that contain the actual DNS records for a domain and provide the final answer to DNS queries.

Anatomy

The following represents a simplified view of a DNS message header structure

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Response Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Questions | Total Answer RRs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Authority RRs | Total Additional RRs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where Flags breakdown to

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|QR|   Opcode    |AA|TC|RD|RA|Z|   RCODE   |
+-+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Explanation of the DNS Header Fields

Identification (16 bits):

  • A unique identifier assigned by the client. It is used to match responses to requests.

Flags (16 bits):

  • Various flags to control the behavior of the request and response.
    • QR (1 bit): Query (0) or Response (1).
    • Opcode (4 bits): Type of query (standard query, inverse query, server status request).
    • AA (1 bit): Authoritative Answer.
    • TC (1 bit): Truncation.
    • RD (1 bit): Recursion Desired.
    • RA (1 bit): Recursion Available.
    • Z (3 bits): Reserved for future use (must be zero).
    • AD (1 bit): Authenticated Data.
    • CD (1 bit): Checking Disabled.
    • RCODE (4 bits): Response code indicating the status of the response (no error, format error, server failure, etc.).

Total Questions (16 bits):

  • The number of questions in the Question section of the message.

Total Answer RRs (16 bits):

  • The number of resource records in the Answer section of the message.

Total Authority RRs (16 bits):

  • The number of resource records in the Authority section of the message.

Total Additional RRs (16 bits):

  • The number of resource records in the Additional section of the message.

Protocol Sequential

Note that the procedural runtime execution timeframe of a DNS query typically varies based on several factors, including network latency, the location of DNS servers, and the efficiency of the DNS resolver's caching mechanisms. In general, with Cache Hit > as low as ~2-11 milliseconds, and without Cache Hit > Approximately ~60-480 milliseconds

First, the DNS Query Process

  1. DNS Query Initiation (~1-10 milliseconds (ms))
    TL;DR : The client sends a DNS query to resolve a domain name into an IP address.
    Explanation : When a user types a URL into their web browser or when an application needs to resolve a domain name, the client initiates a DNS query. This query is typically sent to a DNS resolver, often provided by the user's ISP or a third-party DNS provider.
DNS Query
    Transaction ID: <unique identifier>
    Flags: <query flags>
    Questions:
        - Name: <domain name>
        - Type: <record type, e.g., A, AAAA, MX>
    Additional Info: <optional additional records>
  1. DNS Resolver Server Check (~1 millisecond (if record is cached))
    TL;DR : The DNS resolver checks its cache for a matching DNS record.
    Explanation : Upon receiving the query, the DNS resolver first checks its cache to see if it has a recent answer for the queried domain name. If a cached record is found, it is returned to the client immediately, reducing latency and network traffic.
DNS Resolver
    Cache Check:
        - Domain: <domain name>
        - Record Type: <record type>
        - Result: <cached record or not found>
  1. Root Server Query (~20-120 milliseconds)
    TL;DR : If no cached record is found, the resolver queries a root DNS server.
    Explanation : If the resolver's cache does not contain the answer, the resolver sends a query to one of the root DNS servers. The root servers do not have the IP addresses of domain names but know which top-level domain (TLD) servers (e.g., .com, .org) can provide the answer.
Root Server Query
    Transaction ID: <unique identifier>
    Flags: <query flags>
    Questions:
        - Name: <domain name>
        - Type: <record type>
    Response:
        - TLD Server: <address of TLD server>
  1. TLD Server Query (~20-120 milliseconds)
    TL;DR : The resolver queries the appropriate TLD server identified by the root server.
    Explanation : The resolver now sends a query to the TLD server specified by the root server. The TLD server responds with the address of the authoritative name server for the domain
TLD Server Query
    Transaction ID: <unique identifier>
    Flags: <query flags>
    Questions:
        - Name: <domain name>
        - Type: <record type>
    Response:
        - Authoritative Server: <address of authoritative server>
  1. Authoritative Server Query (~20-120 milliseconds)
    TL;DR : The resolver queries the authoritative name server for the final DNS record.
    Explanation : The resolver sends a query to the authoritative name server, which holds the actual DNS records for the domain. The authoritative server responds with the requested DNS record, such as an A record for an IPv4 address.
Authoritative Server Query
    Transaction ID: <unique identifier>
    Flags: <query flags>
    Questions:
        - Name: <domain name>
        - Type: <record type>
    Response:
        - Record: <resolved DNS record>
  1. DNS Response to Client (~1-10 milliseconds)
    TL;DR : The resolver sends the resolved DNS record back to the client.
    Explanation : After obtaining the DNS record from the authoritative server, the resolver caches the record for future queries and sends the response back to the client's device. The client's device can now use the IP address to establish a connection to the web server.
DNS Response
    Transaction ID: <unique identifier>
    Flags: <response flags>
    Answers:
        - Name: <domain name>
        - Type: <record type>
        - Data: <resolved IP address>
    Additional Info: <optional additional records>

Additional Metadata: DNS Caching and TTL

A typicall DNS record found on DNS resolvers and client may look as follow:

DNS Record
    Name: <domain name>
    Type: <record type, e.g., A, AAAA, MX, CNAME, etc. (eg. NS (Name Server), MX (Mail Exchange))>
    Class: <class of the DNS record, typically IN for Internet>
    TTL: <time to live in seconds>
    Data: <resolved data, e.g., IP address for A/AAAA records, mail server for MX records, etc.>
    Additional Data: <any additional data related to the record>
    Flags: <optional flags providing additional information>
    Timestamp: <time when the record was cached or last updated>
    Source: <source of the record, e.g., authoritative server>
    Serial Number: <serial number for versioning in zone transfers>
    Refresh Interval: <interval before the record should be refreshed>
    Retry Interval: <interval before retrying a failed refresh>
    Expire Time: <time after which the record should be considered expired>

A concrete example:

DNS Record
    Name: example.com
    Type: A
    Class: IN
    TTL: 3600
    Data: 93.184.216.34
    Additional Data: None
    Flags: None
    Timestamp: 2024-05-24T12:00:00Z
    Source: ns1.example.com
    Serial Number: 2024052401
    Refresh Interval: 7200
    Retry Interval: 1800
    Expire Time: 1209600

The TTL (Time to Live)

TL;DR: DNS records have a TTL that specifies how long they should be cached. Explanation: It indicating how long the record can be cached by DNS resolver servers and clients. When the TTL expires, the record must be refreshed from the authoritative server.

DNS Record
    Name: <domain name>
    Type: <record type>
    Data: <resolved IP address>
    TTL: <time to live in seconds>

The DNS Security Extensions (DNSSEC)
TL;DR : DNSSEC adds security to DNS by enabling the verification of DNS data integrity and authenticity. Explanation : DNSSEC provides cryptographic signatures for DNS data, allowing resolvers to verify that the data has not been tampered with and is authentic. This helps protect against DNS spoofing and other attacks. A simplified anatomy:

DNSSEC
    RRSIG (Resource Record Signature): <signature data>
    DNSKEY (DNS Public Key): <public key>
    DS (Delegation Signer): <delegation signer record>

Technical Specifications

You can read further the official DNS technical specifications over the following sources:

  • RFC 1034: Domain Names - Concepts and Facilities - This document defines the concepts and facilities related to DNS, including the overall structure and operation of the DNS.

  • RFC 1035: Domain Names - Implementation and Specification - This document specifies the implementation and specification details of DNS, including message formats, resource records, and query/response interactions.

  • RFC 2181: Clarifications to the DNS Specification - This document provides clarifications and corrections to the original DNS specifications to resolve ambiguities and improve understanding.

  • RFC 4033: DNS Security Introduction and Requirements - This document introduces DNS Security Extensions (DNSSEC) and outlines the requirements for secure DNS operations.

  • RFC 4034: Resource Records for the DNS Security Extensions - This document specifies the DNS resource records used in DNSSEC, including DNSKEY, RRSIG, NSEC, and DS records.

  • RFC 4035: Protocol Modifications for the DNS Security Extensions - This document describes the protocol modifications necessary to support DNSSEC, including the processing of DNSSEC-related resource records.

  • IETF DNSOP Working Group - This page provides information about the DNS Operations (DNSOP) working group, which develops and maintains DNS operational guidelines and related technical documents. It includes links to relevant RFCs and other technical documents.

Privacy, Anonymity, and Hacking Concerns Regarding the DNS Protocol

A protocol is a structured set of rules and procedures designed to facilitate standardized interactions and operations within technological systems. When implemented in the technological landscape, protocols inherently display an attack surface, mostly due to the underlying technology used, the predictable and repeatable nature of protocols — characteristics upon which some level of vulnerabilities can be exploited to whatever endeavours. The below lists some of the DNS protocol exploitations witnessed over the years.

Privacy & Anonymity Concerns

Data Leakage:

DNS queries are typically sent in plain text, meaning that anyone who can intercepting the traffic (such as ISPs, network administrators, or malicious actors) can see which websites or services a computer is attempting to access. Thanks to DNS queries often tied up to user IP addresses, it may exposes user activity and can lead to profiling or tracking. Here comes the DNS over HTTPS (DoH) and DNS over TLS (DoT).

To mitigate privacy concerns, protocols like DoH and DoT encrypt DNS queries. This is to make it harder for third parties to snoop on client activity. It is important to note that even with encrypted DNS (flux or records), the resolver server itself can still log and track user queries. While this adds a layer of security against external actors, it does not ensure anonymity from the DNS resolver service. This can shift trust from ISPs to DNS providers, ie. shift legal jurisdiction, as these providers will see the unencrypted queries.

DNS Query Logging:

DNS servers often log queries, storing information about which domains were looked up and when. These logs can be accessed by third parties, such as law enforcement or marketers, which can lead to privacy invasions.

Hacking Concerns

DNS Spoofing (Cache Poisoning):

DNS spoofing or cache poisoning involves corrupting the DNS cache of a resolver to return incorrect IP addresses. This can redirect users to malicious websites without their knowledge. Attackers can achieve this by injecting false DNS responses into the resolver's cache. Scenario here

Man-in-the-Middle Attacks (MitM):

In a MitM attack, an attacker intercepts and possibly alters DNS queries and responses between a user and the DNS resolver. This can lead to the redirection of users to unintended servers, to whatever endeavour (eg. generally used to harvest sensitive information or malware injection). Scenario here

DNS Amplification Attacks:

DNS amplification is a type of Distributed Denial of Service (DDoS) attack. Attackers exploit DNS servers to flood a target with amplified DNS traffic, overwhelming the target system. Scenario here

Building a DNS Protocol in Rust

... upcoming


Done!

Thanks and Congratulations for reading this to the end. We hope this article brings a little clarity over the protocol anatomy and its various use cases.