How DNS works

Photo by Richy Great on Unsplash

How DNS works

The Domain Name System (DNS) is a hierarchical and decentralized naming system for computers, services, or other resources connected to the Internet or a private network. In essence, DNS serves as the phonebook for the Internet. Its primary purpose is to associate domain names (human-readable identifiers) like www.google.com, with the corresponding IP addresses needed for the purpose of locating and addressing these devices. Essentially, DNS translates more intuitive domain names to the numeric IP addresses, allowing users to access websites using understandable and memorable names instead of numerical IP addresses.

Why DNS Was Invented:

Before DNS, computers used a local file called 'hosts.txt' to map hostnames to IP addresses. However, as the number of computers on the network increased, maintaining and updating this file on every computer became impractical and unscalable. DNS was invented in 1983 by Paul Mockapetris, Jon Postel and Craig Partrige by publishing RFC882 to provide a scalable, distributed, and hierarchical naming system that could be used to resolve hostnames to IP addresses on a network-wide basis.

Main Components of DNS:

  1. Domain Name Space: Hierarchical structure of domains, divided into zones, representing the organization of the domain names.

  2. Root Servers: Servers at the top of the DNS hierarchy, which know where the TLD (Top-Level Domain) servers are located.

  3. Top-Level Domain (TLD) Servers: Responsible for top-level domains like .com, .org, .net, .gov, etc.

  4. Authoritative DNS Servers: Store DNS record information about specific domains and subdomains and provide authoritative answers to DNS queries.

  5. DNS Resolver (or Recursive Resolver): Acts as a middleman between a client and DNS nameservers, tasked with finding the IP address associated with a domain name.

  6. DNS Cache: Temporary storage that holds the IP addresses of recently queried domain names to reduce the load on DNS servers and speed up subsequent queries for the same domain name.

  7. Resource Records: Data structures in the DNS database that define the domain and its associated resources, such as A (Address Record), AAAA (IPv6 Address Record), MX (Mail Exchange), CNAME (Canonical Name Record), etc.

Here is a simplified flow of how DNS processing works, using google.com as an example:

  1. User Input: A user types 'www.google.com' into the web browser.

  2. Recursive Query: The browser asks the local DNS resolver (usually provided by the ISP) for the IP address of www.google.com.

  3. Root DNS Server Query: If the local DNS resolver does not have the IP cached, it queries a root DNS server. The root server responds with a referral to a Top Level Domain (TLD) DNS server, responsible for '.com' domains.

  4. TLD DNS Server Query: The local DNS resolver then queries the TLD DNS server, which responds with a referral to the authoritative DNS server for 'google.com'.

  5. Authoritative DNS Server Query: The local DNS resolver queries the authoritative DNS server for the specific IP address of 'www.google.com', and the server responds with the IP address.

  6. IP Address Returned to User: The local DNS resolver returns the IP address to the user's computer, which can now make a direct request to the server hosting google.com.

  7. Connection Establishment: The user’s browser connects to the IP address and retrieves the web page from Google’s servers.

DNS Hierarchy

DNS Hierarchy refers to the hierarchical and decentralized structure of the Domain Name System (DNS). It consists of different levels, starting from the Root level, progressing to Top-Level Domains (TLDs), Second-Level Domains (SLDs), and so on, down to individual hostnames. Each level in the hierarchy represents different scopes of authority and responsibility within the DNS infrastructure.

DNS Hierarchy Structure:

  1. Root Level (“.”): The highest level in the hierarchy, consisting of Root DNS Servers that know the IP addresses of the TLD servers.

  2. Top-Level Domains (TLDs) (e.g., .com, .org, .net): Represent different classes or types of domains, managed by various organizations.

  3. Second-Level Domains (SLDs) (e.g., example.com): Individual domain names registered under a TLD.

  4. Subdomains and Hostnames (e.g., www.example.com): Further subdivisions under an SLD, representing specific hosts or services.

Reason for DNS Hierarchy Architecture:

The hierarchical and decentralized architecture of DNS was chosen due to the following reasons:

  1. Scalability: A single, central DNS server for the entire internet would be overwhelmed by the number of requests from users worldwide. The hierarchical structure distributes the load across multiple servers at different levels.

  2. Fault Tolerance and Redundancy: Having multiple DNS servers at each level of the hierarchy ensures that if one server fails, others can still handle the requests, maintaining the robustness of the Internet.

  3. Efficiency and Performance: Distributing DNS information across multiple servers located geographically closer to the users allows faster response times for DNS queries.

  4. Administrative Control: The hierarchical structure allows delegation of authority, enabling organizations to have control over their own domain names and subdomains.

  5. Caching and Resource Optimization: Local DNS resolvers can cache the results of DNS queries to reduce the load on upstream DNS servers and provide quicker responses to subsequent queries for the same domain.

Why Not One Global DNS Server?

  1. Single Point of Failure: One global server would represent a single point of failure, making the entire internet vulnerable.

  2. Scalability Issues: A single server would struggle to handle the immense number of queries from around the globe, leading to performance issues and outages.

  3. Latency: Users located far from the central server would experience significant delays in DNS resolution.

  4. Lack of Customization and Control: A single global server would not allow organizations to manage their own DNS records or implement custom DNS solutions tailored to their needs.

The hierarchical and decentralized structure of the DNS system was chosen to ensure the scalability, reliability, efficiency, and administrative flexibility of the internet.

DNS Zone:

A DNS zone is a portion of the DNS namespace that is managed by a specific organization or individual. It represents a boundary of authority and is used to manage the domain names located under that particular zone. A DNS zone can consist of one or more contiguous domains and subdomains. For example, if an organization owns the domain example.com, the DNS zone for example.com can include any subdomains like mail.example.com and www.example.com.

Each DNS zone is served by an authoritative DNS server, which has the final authority over the domain names within that zone, meaning it holds the definitive set of information for that portion of the namespace.

Zone File:

A Zone file is a text file stored on the authoritative DNS server that contains mappings between domain names and IP addresses within a DNS zone. It consists of various Resource Records (RRs), each defining a specific type of information about the domain.

Here is a breakdown of some of the typical Resource Records found in a zone file:

  1. SOA (Start of Authority): Specifies authoritative information about the domain and the zone, including the primary DNS server, the email of the domain administrator, the domain serial number, and timers.

  2. NS (Name Server): Defines the authoritative DNS servers for the zone.

  3. A (Address Record): Maps a domain to an IPv4 address.

  4. AAAA (IPv6 Address Record): Maps a domain to an IPv6 address.

  5. MX (Mail Exchange): Defines the mail servers for the domain.

  6. CNAME (Canonical Name): Creates an alias of one domain to another.

  7. PTR (Pointer Record): Used for reverse DNS lookups to map an IP address to a domain name.

  8. TXT (Text Record): Provides the ability to associate some arbitrary and unformatted text with a host or other name.

Example of a Simple Zone File:

$ORIGIN example.com. ; Designates the start of this zone file
$TTL 3600       ; Default Time to Live for all records

@    IN SOA ns1.example.com. hostmaster.example.com. (
         2023092801 ; Serial
         3600       ; Refresh
         1800       ; Retry
         604800     ; Expire
         86400 )    ; Minimum TTL

; Define the authoritative name servers
      IN NS   ns1.example.com.
      IN NS   ns2.example.com.

; A records for the domain
@    IN A    192.0.2.1 ; example.com is associated with 192.0.2.1
www  IN A    192.0.2.2 ; www.example.com is associated with 192.0.2.2

; MX Record for mail servers
@    IN MX 10 mail.example.com.

This example represents a simplified zone file for the domain example.com, defining various parameters and mappings within that DNS zone.

Getting info about DNS zone records

You can obtain information about DNS zone records using a variety of terminal commands. Here are a couple of methods, utilizing dig and nslookup, which are typically available on Unix-like operating systems, including Linux and macOS. Windows users may have nslookup available or can use it within Windows Subsystem for Linux (WSL).

1. Using dig:

The dig command is a powerful DNS querying tool, more modern and flexible compared to nslookup. To retrieve information about the DNS zone records, you can perform a zone transfer using dig. However, please note that most DNS servers disable zone transfers to the public due to security reasons.

dig @ns1.example.com example.com AXFR
  • @ns1.example.com specifies the DNS server to query.

  • example.com is the domain for which you are requesting information.

  • AXFR requests a zone transfer.

2. Using nslookup:

nslookup is another command-line tool used for querying the Domain Name System (DNS) to obtain domain name or IP address mapping.

nslookup -type=any example.com

This will return any available records associated with example.com from your DNS resolver. However, this does not perform a zone transfer and will not show all the records in the zone file of the domain.

3. Query Specific Records with dig:

If you are interested in specific DNS records like A, MX, or TXT, you can use dig as follows:

dig example.com A +short  # For A records
dig example.com MX +short  # For MX records
dig example.com TXT +short  # For TXT records

Important Note:

Trying to retrieve all the DNS records via a Zone Transfer (AXFR) is often restricted and generally not available for domains you do not own or control, due to security and privacy concerns. For regular, public domain queries, you're typically limited to looking up individual record types using commands like dig or nslookup.

DNS Zone Transfer:

A DNS Zone Transfer is a mechanism by which DNS information is transferred from one DNS server to another. It is primarily used to synchronize the DNS data between the primary (master) DNS server and the secondary (slave) DNS servers in a DNS zone to ensure consistency and reliability in resolving domain names.

There are two types of DNS Zone Transfers:

  1. AXFR (Full Zone Transfer):

    • It transfers the entire DNS zone.

    • Every time a change is made to the DNS records in the primary server, the entire zone data is transferred to the secondary servers.

    • It is not very efficient when only a few records change, as it transfers the entire set of records every time.

dig @ns1.example.com example.com AXFR
  1. IXFR (Incremental Zone Transfer):

    • It transfers only the changed records since the last transfer.

    • It is more efficient and bandwidth-friendly, especially for larger zones with infrequent changes, as it only transfers the modifications.

    • The requesting server must support IXFR, and it needs to specify the serial number of its current version of the zone.

dig @ns1.example.com example.com IXFR=<serial-number>

Security Considerations:

  • Unauthorized Access: Zone transfers can expose sensitive information about domain names, subdomains, and related IP addresses to potential attackers.

  • Denial of Service (DoS): Frequent and unnecessary zone transfers can consume significant bandwidth and resources, leading to potential service disruptions.

To mitigate these risks, zone transfers are typically restricted to a predefined list of authorized DNS servers. Firewalls, ACLs (Access Control Lists), and TSIG (Transaction SIGnature) are usually employed to secure zone transfers and ensure that only legitimate secondary servers can request them.

A Zone Transfer is crucial for maintaining the accuracy and consistency of DNS information across multiple DNS servers but needs to be properly secured to prevent unauthorized access and potential abuse.

Reading the dig command output

The output of the dig command displays various sections providing information about the DNS query performed and its results. Below is a breakdown of the different parts of the output for dig google.com:

; <<>> DiG 9.16.1-Ubuntu <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26187
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;google.com.            IN    A

;; ANSWER SECTION:
google.com.        282    IN    A    142.250.74.142

;; Query time: 12 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Sep 28 18:51:20 +06 2023
;; MSG SIZE  rcvd: 55

Header Information:

; <<>> DiG 9.16.1-Ubuntu <<>> google.com
;; global options: +cmd
  • DiG Version: Indicates the version of dig used, here it is 9.16.1-Ubuntu.

  • Queried Domain: The domain that was queried, in this case, google.com.

  • Global Options: Displaying +cmd indicates that it's showing the command section.

Answer Header:

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7853
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
  • opcode: Specifies the kind of query; QUERY is a standard DNS query.

  • status: NOERROR means the query was successful.

  • id: A unique identifier for the DNS query.

  • flags: Shows various flags set in the response:

    • qr: Indicates this is a response.

    • rd: Recursion desired, the client desires the server to perform recursion.

    • ra: Recursion available, the server can perform recursion.

  • QUERY: Number of entries in the question section, usually 1.

  • ANSWER: Number of records in the answer section.

  • AUTHORITY: Number of authoritative records in the response.

  • ADDITIONAL: Number of additional records in the response.

Question Section:

;; QUESTION SECTION:
;google.com.            IN    A
  • Displays the domain name (google.com.) and the type of record being queried. IN A represents an Internet Address record (IPv4).

Answer Section:

;; ANSWER SECTION:
google.com.        124    IN    A    216.58.211.14
  • Provides the result of the DNS query. Here, it shows that the A (Address) record for google.com is 216.58.211.14.

  • 124: Represents the Time to Live (TTL) in seconds, specifying how long the DNS resolver should cache this record.

  • IN: Stands for Internet, indicating the class of the DNS record.

Additional Information:

;; Query time: 16 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Sep 28 15:16:59 +06 2023
;; MSG SIZE  rcvd: 55
  • Query time: Shows the time taken to complete the DNS query in milliseconds.

  • SERVER: Indicates the DNS server that answered the query, with its IP address and port number. Here, it is the local DNS resolver at 127.0.0.53.

  • WHEN: Displays the timestamp when the query was made.

  • MSG SIZE rcvd: Indicates the size of the received message in bytes.

References:

  1. How DNS works?

  2. Root Servers