DNS

What is DNS?

DNS stands for Domain Name System, and it is one of the core technologies that allow the internet to function. DNS acts like a phonebook for the internet. When you type a website's name (like www.example.com) into your browser, DNS translates that human readable domain name into an IP address, such as 142.251.191.79, which is what computers use to identify each other on the network.

Here is an analogy

Imagine the internet as a giant city and DNS as its directory assistance service. When you want to visit a business (a website), you might know its name (e.g., "Google"), but not its exact address. You call the directory assistance service, which quickly looks up the name and gives you the address. With that address, you can now travel directly to the business.

Similarly, DNS translates the website name you know into the IP address your computer needs to connect to the correct server.

History and Evolution of DNS

In the early days of the internet (ARPANET era), there were only a few computers connected, so it was easy to maintain a simple file called hosts.txt, which mapped host names to IP addresses. However, as the number of computers on the network grew, this centralized method became impractical.

In 1983, Paul Mockapetris proposed DNS as a decentralized and scalable solution. It allowed for a hierarchical naming system where different parts of the domain could be managed independently. Over time, DNS has evolved to support features like load balancing, redundancy, and security enhancements such as DNSSEC (Domain Name System Security Extensions).

Key Features of DNS

  1. Human Friendly: DNS makes the internet usable by allowing people to use easy-to-remember domain names instead of complicated IP addresses.
  2. Scalability: It supports the massive scale of the internet by distributing the management of domain names across multiple servers globally.
  3. Redundancy: DNS is designed to be highly available, with multiple redundant servers handling the same queries, ensuring that the system is resilient and can recover from failures.
  4. Security: While DNS was initially designed without security in mind, modern implementations include security features like DNSSEC to protect against certain types of attacks.

Key Components of DNS

  1. Domain Names: These are the human-readable names of websites. For example, www.google.com is a domain name. A domain name typically consists of multiple parts separated by dots (e.g., www.example.com). It is organized in a hierarchical structure, read from right to left, with each level representing different levels of authority within the Domain Name System (DNS). Components of a Domain Name include:
    1. Top-Level Domain (TLD): This is the rightmost part of the domain name, such as .com, .org, .net, .edu, .gov, or country code TLDs like .uk, .fr, .jp, etc.
    2. Second-Level Domain (SLD): This is the part of the domain immediately to the left of the TLD, such as example in example.com. The SLD is typically the name of the organization, company, or individual that owns the domain. The combination of the SLD and TLD (e.g., example.com) is often referred to as the root domain.
    3. Subdomain: Subdomains are the parts to the left of the second-level domain. For example, www in www.example.com is a subdomain. Subdomains allow domain owners to organize their website into sections or categories (e.g., blog.example.com or shop.example.com).
  2. IP Addresses: Computers use IP addresses to communicate with each other. An example of an IP address would be 216.58.211.110, which is one of Google's IP addresses.
  3. Domain Name Registratrars: Domain names are registered through domain registrars, which are accredited organizations that sell and manage domain name registrations. When you register a domain name, you lease it for a specific period (usually 1-10 years). You have the right to renew your registration indefinitely.
  4. DNS Resolver: This is the first stop in the DNS lookup process. It receives the request from the client (usually your web browser) and starts the process of translating the domain name into an IP address.
  5. Root Name Servers: The root name servers act like the top of the hierarchy in the DNS system. They handle queries about domains at the highest level (such as .com, .net, .org).
  6. Top-Level Domain (TLD) Servers: These are responsible for domains that end in common suffixes like .com, .org, or country codes like .uk or .jp.
  7. Authoritative Name Servers: These servers store the actual DNS records and provide the final answer to the resolver, telling it the IP address for the domain.
  8. DNS Records: These are mappings between domain names and IP addresses. The most common types of DNS records are:
    1. A Record: Maps a domain to an IPv4 address.
    2. AAAA Record: Maps a domain to an IPv6 address.
    3. CNAME Record: Alias of one domain name to another.
    4. MX Record: Mail exchange records used for email routing.

How DNS Works

How DNS Works

When you type www.example.com into your browser:

  1. The Browser checks DNS Cache: The browser will first check the its own cache, OS cache, router cache etc. to see if it can find IP address for the domain name.
  2. The Browser Contacts the DNS Resolver: Your browser sends a request to a DNS resolver (which could be provided by your ISP or a public resolver like Google DNS or Cloudflare DNS).
  3. The DNS Resolver Queries the Root Server: If the resolver doesn’t already know the IP address, it sends a query to one of the root name servers. The root server doesn't have the answer but directs the resolver to the appropriate TLD server for .com.
  4. The Resolver Queries the TLD Server: The resolver now asks the .com TLD server. The TLD server responds with the authoritative name server for example.com.
  5. The Resolver Queries the Authoritative Name Server: Finally, the resolver asks the authoritative name server for example.com and receives the IP address.
  6. The Resolver Returns the IP to the Browser: Once the DNS resolver has the IP address, it sends it back to the browser, which can then establish a connection to the server and load the website.

Example

Let’s say you want to visit www.example.com. Here’s what happens:

  1. You type www.example.com in your browser.
  2. The browser checks cache for IP address of domain name. (let's assume this is not cached).
  3. The browser sends a request to a DNS resolver (let's assume Google Public DNS at 8.8.8.8).
  4. The DNS resolver doesn't have the IP address cached, so it contacts a root name server.
  5. The root name server tells the resolver to contact the .com TLD server.
  6. The .com TLD server responds by pointing to the authoritative name server for example.com.
  7. The authoritative name server for example.com provides the IP address (93.185.219.35).
  8. Your browser connects to 93.185.219.35, and the webpage is loaded.

DNS Servers

DNS architecture involves four different types of servers:

  • Recursive DNS Resolver
  • Root Name Server
  • TLD Server
  • Authoritative Name Server

Recursive DNS Resolver

The recursive resolver is the first point of contact when a browser makes a DNS query. Its role is to take the domain name request from the client and recursively query the necessary DNS servers until it finds the IP address associated with the domain name. There are two types of Recursive DNS Resolvers:

  • ISP-Provided DNS Resolver When you connect to the internet through your Internet Service Provider (ISP), your device is typically configured to use the DNS resolver provided by your ISP. This resolver is a recursive resolver that handles DNS queries on your behalf, caching responses to improve efficiency and speed for subsequent queries.
  • Manually Configured DNS Resolver You can manually configure your device to use a different DNS resolver instead of the one provided by your ISP. These resolvers are often faster, more reliable, and sometimes more secure or private compared to ISP-provided resolvers. They may also offer additional features like DNS filtering or enhanced privacy through DNS over HTTPS (DoH) or DNS over TLS (DoT). Popular alternatives include:
    • Google Public DNS: 8.8.8.8 and 8.8.4.4
    • Cloudflare DNS: 1.1.1.1 and 1.0.0.1

Root Name Server

Root name servers are the top-most level of the DNS hierarchy. They do not contain IP address mappings for domain names but instead, direct the recursive resolver to the appropriate Top-Level Domain (TLD) DNS server. There are 13 logical root servers, labeled A through M, operated by different organizations worldwide.

Example of Root Servers:

  • A Root Server: Managed by Verisign, one of the 13 root servers, accessible via the address a.root-servers.net.
  • M Root Server: Managed by the WIDE Project in Japan, accessible via m.root-servers.net.

TLD Server

TLD (Top Level Domains) name servers are responsible for managing specific top-level domains (like .com, .org, .net, or country-specific TLDs like .uk, .jp). These servers store information that points the resolver to the authoritative DNS servers for domain names under their TLD.

Example of TLD Name Servers:

  • Verisign TLD Servers: Verisign manages TLD name servers for .com and .net domains.
  • Public Interest Registry Servers: These handle TLD servers for .org domains.

Authoritative Name Server

The authoritative name server holds the actual DNS records for a specific domain (e.g., example.com). This server is the final stop in the DNS lookup process and provides the recursive resolver with the IP address for the domain.

Example of Authoritative Name Servers:

  • Amazon Route 53: A cloud-based authoritative DNS service provided by AWS.
  • GoDaddy Authoritative Servers: Domains registered with GoDaddy are hosted on its authoritative DNS servers.
  • Cloudflare Authoritative DNS: Cloudflare provides authoritative DNS services that handle traffic for millions of websites globally.

DNS Queries

DNS queries are requests made to DNS servers in order to resolve domain names into IP addresses or retrieve other types of DNS records.

There are different types of DNS queries:

  • Recursive Query: A recursive query is a request made by a client (typically your browser or operating system) to a DNS resolver. In this type of query, the client expects the resolver to either return the final answer (the IP address of the domain) or an error message if it cannot be resolved. The client does not participate in the lookup process after it sends the query; the DNS resolver does all the work.

    • Example:
      • You type www.example.com into your browser.
      • The browser sends a recursive DNS query to your configured DNS resolver (such as Google Public DNS at 8.8.8.8).
      • The DNS resolver will perform all the necessary queries (to the root servers, TLD servers, and authoritative name servers) on behalf of your browser.
      • It will return the IP address 93.185.217.35 (for example) or an error if the domain does not exist.

  • Iterative Query: An iterative query is a request in which the DNS resolver responds with the best answer it has based on its cache or the next step in the lookup process. The client may have to send multiple queries to different servers to resolve the domain name fully.

    • Example:
      • If the DNS resolver doesn't have the IP address for www.example.com cached, it will respond with the address of a root server (instead of the final IP).
      • The client then queries the root server, which provides the address of the .com TLD server.
      • The client queries the .com TLD server, which provides the address of the authoritative name server for example.com.
      • Finally, the client queries the authoritative name server to get the IP address 93.185.217.35.

  • Non-recursive query:: Typically this will occur when a DNS resolver client queries a DNS server for a record that it has access to either because it's authoritative for the record or the record exists inside of its cache. Typically, a DNS server will cache DNS records to prevent additional bandwidth consumption and load on upstream servers.

  • Inverse Query: An inverse query (sometimes called a reverse DNS query) is used to perform a reverse lookup. Instead of resolving a domain name into an IP address, it resolves an IP address into a domain name.

    • Example:
      • You want to know the domain name associated with the IP address 93.195.217.35.
      • The client sends an inverse DNS query to the DNS resolver.
      • The DNS resolver queries the reverse DNS system, where reverse DNS records are stored.
      • The server responds with the domain name www.example.com.

DNS Records

DNS records are entries in a DNS database that map human-friendly domain names to IP addresses and other information. There are several types of DNS records, each serving a specific purpose in the domain name resolution process. Here are the most common types:

  • A Record (Address Record) An A Record maps a domain name to an IPv4 address, which is a numerical label assigned to a device connected to a network (e.g., a website server).

    • Example: example.com → 93.195.217.35 (When a user types example.com into their browser, the DNS lookup retrieves the A Record, which points the domain to the IP address 93.195.217.35)

  • AAAA Record (IPv6 Address Record) The AAAA Record is similar to the A Record but maps a domain name to an IPv6 address (the newer version of IP addresses).

    • Example: example.com → 2606:2800:220:1:249:1993:26c8:1847 (When a user types example.com, the DNS lookup retrieves the AAAA Record, which points to the IPv6 address.)

  • CNAME Record (Canonical Name Record) A CNAME Record is used to alias one domain name to another. It essentially redirects one domain to another domain's A or AAAA record.

    • Example: www.example.com → example.com (Instead of pointing directly to an IP address, www.example.com points to example.com, which has the actual IP address.)

  • MX Record (Mail Exchange Record) The MX Record specifies the mail servers responsible for receiving emails on behalf of a domain. It includes a priority field that determines the order in which the servers should be used.

    • Example: example.com →
      • 10 mail1.example.com
      • 20 mail2.example.com
    • Emails sent to user@example.com will first attempt to be delivered to mail1.example.com (priority 10). If it is unavailable, they will try mail2.example.com (priority 20).

  • TXT Record (Text Record) A TXT Record allows domain owners to insert arbitrary text into their DNS records. These are often used for various purposes like email validation, security, and ownership verification.

    • Example:
      • example.com → v=spf1 include:_spf.example.com ~all
    • This TXT record is an SPF (Sender Policy Framework) entry that helps verify which mail servers are allowed to send emails on behalf of the domain example.com.

  • NS Record (Name Server Record) An NS Record specifies the authoritative name servers for a domain, which are the servers responsible for answering DNS queries for that domain.

    • Example:
      • example.com → ns1.example.com, ns2.example.com
      • These name servers are responsible for providing authoritative answers to queries about example.com.

  • SOA Record (Start of Authority Record) The SOA Record provides essential information about the domain, such as the primary name server, the email address of the domain administrator, and domain serial number, which is used for zone transfers.

    • Example:
      • example.com →
        • Primary Name Server: ns1.example.com
        • Responsible Party: admin@example.com
        • Serial Number: 2023081501
        • Refresh, Retry, Expire, TTL values.

  • SRV Record (Service Record) An SRV Record is used to define the location (hostname and port) of servers for specified services. It is commonly used for specifying the location of services like SIP (Session Initiation Protocol) or LDAP (Lightweight Directory Access Protocol).

    • Example:
      • _sip._tcp.example.com → 5 5060 sipserver.example.com
    • This SRV record specifies that the SIP service is available on sipserver.example.com at port 5060.

  • PTR Record (Pointer Record) A PTR Record is the reverse of an A or AAAA record. It maps an IP address back to a domain name, commonly used for reverse DNS lookups.

    • Example:
      • 93.184.216.34 → example.com (This PTR record indicates that the IP address 93.184.216.34 is associated with example.com.)

  • CAA Record (Certification Authority Authorization Record) A CAA Record is used to specify which certificate authorities (CAs) are allowed to issue SSL/TLS certificates for a domain. It helps prevent unauthorized issuance of certificates.

    • Example:
      • example.com → 0 issue "letsencrypt.org" (This CAA record specifies that only Let's Encrypt is authorized to issue certificates for example.com.)

  • DNSKEY Record A DNSKEY Record contains the public signing key that is used to verify DNSSEC signatures. DNSSEC (Domain Name System Security Extensions) is a security feature that protects DNS from attacks by digitally signing DNS data.

    • Example:
      • example.com → 256 3 8 AwEAAc... (This DNSKEY record helps validate that DNS data is authentic.)

  • NAPTR Record (Naming Authority Pointer Record) A NAPTR Record is used for regular expression-based rewriting of domain names, often used in applications such as Voice over IP (VoIP) and the Dynamic Delegation Discovery System (DDDS).

    • Example:
      • e164.arpa → A regular expression that can rewrite the domain name into something else, such as a SIP address.

Summary Table of Common DNS Records

Record Type Purpose Example
A Maps domain to IPv4 address example.com → 93.195.217.35
AAAA Maps domain to IPv6 address example.com → 2606:2800:220:...
CNAME Alias one domain to another www.example.com → example.com
MX Defines mail servers for a domain example.com → mail1.example.com
TXT Stores arbitrary text, often for validation v=spf1 include:_spf.example.com ~all
NS Defines authoritative name servers example.com → ns1.example.com
SOA Provides domain-related metadata Primary NS: ns1.example.com
SRV Specifies service locations (hostname, port) _sip._tcp.example.com → sipserver.example.com
PTR Maps IP address to domain name (reverse DNS) 93.195.217.35 → example.com
CAA Specifies which CAs can issue certificates example.com → issue "letsencrypt.org"
DNSKEY Stores DNSSEC public key example.com → 256 3 8 AwEAAc...
NAPTR Used for advanced domain rewriting e164.arpa → SIP rewrite rule

 

DNS Cache

DNS caching refers to the process of temporarily storing DNS query results to reduce the time it takes to resolve a domain name to an IP address in subsequent requests. Instead of performing a full DNS lookup each time a domain is requested, cached information can be reused, speeding up the resolution process and reducing the load on DNS servers.

When you visit a website for the first time, your DNS resolver performs a series of queries to resolve the domain name to an IP address. The results of these queries are cached (stored in memory) for a specified amount of time, known as the TTL (Time To Live), which is set by the authoritative DNS server. During this TTL period, subsequent queries for the same domain can be answered more quickly because the DNS resolver can use the cached information instead of querying the DNS hierarchy again.

Different Places Where DNS Information is Cached

DNS Cache

DNS caching occurs at multiple levels in the DNS resolution process. Here are the key places where DNS information can be cached:

  1. Browser Cache Web browsers like Chrome, Firefox, and Safari maintain their own DNS caches. When you enter a domain name, the browser first checks its local cache to see if it has recently resolved the domain and still has the IP address stored.
    • Example: If you visit example.com, your browser caches the DNS resolution for the TTL specified by the DNS server (e.g., 600 seconds). If you revisit example.com within that time, the browser retrieves the IP address from its cache instead of querying the DNS resolver.
  2. Operating System Cache (Local DNS Cache) The operating system (OS) maintains its own DNS cache as well. This cache stores DNS query results across all applications, not just the browser. When an application requests the resolution of a domain name, the OS checks its cache before querying external DNS resolvers.
    • Example: In Windows, the OS stores DNS entries in the local DNS cache, which can be viewed and flushed using the ipconfig /displaydns and ipconfig /flushdns commands. On macOS, you can flush the DNS cache using sudo killall -HUP mDNSResponder.
  3. Router Cache Your home or office router may also cache DNS responses to speed up domain name resolution for all devices on the network. Instead of sending every DNS query to an external DNS resolver, the router can respond with cached information for frequently accessed domains.
    • Example: If multiple devices on your network (laptops, smartphones) access the same domain (e.g., example.com), the router can respond with cached IP addresses to reduce latency and avoid redundant queries to the upstream DNS resolver.
  4. ISP DNS Resolver Cache Your Internet Service Provider (ISP) typically provides a DNS resolver that caches DNS query results for all its customers. The resolver caches information from authoritative DNS servers, allowing faster resolution for subsequent queries for the same domain by any user connected to the ISP.
    • Example: If your ISP’s DNS resolver caches the IP address of example.com, and another user on the same ISP requests example.com, the resolver can respond with the cached information instead of performing a full DNS lookup.
  5. Recursive DNS Resolver Cache A recursive DNS resolver (such as Google Public DNS or Cloudflare DNS) also caches DNS query results. When a query is sent to a recursive resolver, it may not need to query authoritative name servers if it has the information cached.
    • Example: If a user sends a query for example.com to Google Public DNS (8.8.8.8), and the IP address is already cached from previous queries, the resolver responds immediately with the cached information, avoiding the need to query the root and authoritative servers.
  6. Authoritative DNS Server Cache While authoritative DNS servers do not cache queries in the traditional sense, they may cache negative responses. For example, if a domain does not exist (a negative response), authoritative DNS servers can cache this information for a certain TTL to prevent repeated queries for nonexistent domains.
    • Example: If a query for nonexistent.example.com returns a negative response, the authoritative DNS server may cache this result for a specified TTL (e.g., 600 seconds), avoiding repeated queries for the same non-existent domain.

DNS Security

DNS security is crucial for the integrity, confidentiality, and availability of the Domain Name System (DNS), which is one of the most foundational protocols of the internet. As DNS plays a critical role in translating human-readable domain names into IP addresses, its compromise can lead to severe consequences such as traffic redirection, data theft, service unavailability, and more. Over the years, several security mechanisms and protocols have been introduced to address vulnerabilities in DNS.

Types of threats that target DNS:

  • DNS Spoofing (Cache Poisoning): Attackers insert forged DNS data into a recursive resolver's cache, causing it to return incorrect IP addresses. This can lead users to malicious websites, where attackers can steal sensitive information.
  • DNS Amplification (DDoS): Attackers exploit the open nature of DNS servers by sending small DNS queries with forged source IP addresses (spoofing the victim's IP) to publicly accessible DNS servers. The DNS server responds with a much larger response, overwhelming the victim’s server with traffic.
  • DNS Hijacking: Attackers intercept and alter DNS queries and responses to redirect traffic to malicious websites. This can be done by compromising the DNS resolver or by manipulating the authoritative name server.
  • Man-in-the-Middle Attacks (MitM): Attackers intercept the DNS queries and responses, allowing them to alter the DNS response, potentially directing users to malicious servers.
  • DNS Tunneling: Attackers use DNS queries and responses to encode and transfer data between a client and a remote server. This technique can be used to exfiltrate data, bypass firewalls, or establish covert communication channels.
  • Domain Hijacking: Attackers take control of a domain by altering the registration details, often through social engineering attacks on domain registrars or exploiting weaknesses in the registrar's systems.

DNS Security Mechanisms and Protocols

To counter these threats, various DNS security mechanisms and protocols have been developed:

  • DNSSEC (Domain Name System Security Extensions) DNSSEC was introduced to provide integrity and authenticity to DNS responses, ensuring that DNS data has not been tampered with during transit. DNSSEC uses digital signatures to verify that DNS responses come from an authoritative source and have not been altered.
  • DNS over HTTPS (DoH) DoH encrypts DNS queries and responses using HTTPS, preventing attackers from intercepting and modifying DNS traffic.
  • DNS over TLS (DoT) Similar to DoH, DNS over TLS (DoT) encrypts DNS queries to prevent eavesdropping and man-in-the-middle attacks. DNS queries are transmitted over an encrypted TLS connection (using port 853), protecting them from snooping and tampering.
  • DNSCrypt DNSCrypt is a protocol that authenticates communication between a DNS client and a DNS resolver, protecting DNS queries from being tampered with. DNSCrypt uses encryption to authenticate that the response returned by the DNS resolver is genuine and hasn’t been modified.
  • Authenticated Resolvers (DoH/DoT) Authenticated resolvers add an additional layer of security by verifying that the recursive resolver itself is trusted and authorized to handle DNS queries.

Securing DNS Infrastructure

Aside from protocols like DNSSEC and DoH, securing the overall DNS infrastructure is critical:

  • Anycast Routing Anycast routing is used to improve the resilience of DNS servers, particularly for root and TLD name servers. In anycast, multiple DNS servers share the same IP address, and queries are routed to the nearest available server. This reduces latency and ensures redundancy in case one server fails or is targeted by an attack.
  • Redundant DNS Infrastructure By maintaining multiple DNS servers distributed across different geographical locations and networks, organizations can ensure that their DNS services remain available even if one server or data center goes down.
  • Access Control and Monitoring Limiting access to DNS servers and monitoring for suspicious activities helps reduce the likelihood of attacks, such as DNS hijacking and unauthorized changes to DNS records.

Reverse DNS

Reverse DNS is the opposite of the normal DNS lookup. Instead of resolving a domain to an IP address, reverse DNS resolves an IP address to a domain name. This is often used in email validation to ensure the sending server is correctly identifying itself.



Try few questions
<-- Back
Take quiz -->