Deep Dive into DNS: The Internet's Super Smart Address Book

The internet uses DNS as its fundamental directory system which people refer to as the "phonebook of the internet." Your browser uses DNS to locate the actual numerical IP address (172.217.160.142) of www.google.com so your computer can establish a connection. The description of a smartphone as a device for making calls fails to capture its full range of advanced technology.

The Rulebooks of DNS: RFC Standards

DNS operates based on pre-established rules and instructions which form the foundation of its infrastructure. The initial DNS rules appeared in 1983 through Request for Comments (RFCs). Internet technologies require official instruction manuals and RFCs serve as the standard documentation for these technologies.
The two OGs (Original Gangsters) of DNS are:

• RFC 1034 establishes the fundamental concepts for domain names and their organizational structure and operational methods. The document provides a complete understanding of domain names alongside their organizational structure (like a tree) and basic DNS functionality principles.

• RFC 1035 defines both DNS software implementation specifications and message format standards and server communication protocols. The document provides detailed specifications for DNS software development.

Multiple RFCs have been created since the internet's growth to address security concerns and other emerging issues. Some really important updates include:

• RFC 2535/4033-4035: DNS Security Extensions (DNSSEC) implemented authentication to protect DNS responses from tampering by hackers. (More on this later!)

• The RFC 1995 document defines Incremental Zone Transfer which functions similarly to a phonebook update. Servers can now transmit only modified data instead of entire updates through this method which results in faster transmission speeds. A server maintains responsibility for managing all records that fall under its specific DNS database section which is called a "zone" (for example google.com).

• The DNS NOTIFY mechanism defined in RFC 1996 enables the main server to alert other servers about new record updates which allows them to retrieve fresh information.

• The RFC 2136 standard enables authorized programs to perform automatic DNS record updates which benefits systems that need frequent IP address modifications.

• RFC 7766: DNS Transport over TCP: The document established protocols for TCP DNS usage including times when to implement this more reliable protocol.

• The DNS over TLS (DoT) and DNS over HTTPS (DoH) protocols were established through RFC 7858 and RFC 8484 to protect DNS queries from being monitored by snoops. Super important for privacy!

DNS Message Format: How Computers Talk DNS

The fundamental operation of DNS communication relies on exchanging messages between independent systems. The messages transmitted through DNS operate as structured binary data composed of 0s and 1s. The system functions through a highly structured format which requires exact completion. The five essential components of each message include:

1. The message header contains control information which functions as a cover sheet for the message.

2. The DNS server receives the question which asks for the IP address of www.example.com.

3. The server provides the answer to known questions through this section (e.g., "The IP address for www.example.com is 93.184.216.34.").

4. The server directs users to other DNS servers which possess the required information through the Authority section when it lacks direct knowledge.

5. The Additional section contains supplementary information which supports both queries and answers.

The DNS Header: 12 Bytes of Control

The first twelve bytes (96 bits) of every DNS message contain the header information. The message operates through this central control system:

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID | // Unique ID for this conversation
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA|Z |AD|CD| RCODE | // Flags and codes
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT | // How many questions?
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT | // How many answers?
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT | // How many authority records?
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT | // How many additional records?
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Let's decode those fields:

• ID (16 bits): The DNS query receives its unique tracking number from this field. Your computer provides an ID when it sends out a query. The DNS server uses the same ID to identify which question the answer belongs to.

• QR (1 bit): The message contains a Query (0) or a Response (1). Simple!

• OPCODE (4 bits): The query type gets specified through this field. Standard queries (like "find this IP address") use the 0 value in this field. The remaining codes serve two purposes: they support inverse queries (IP to name conversion) which are less common and server status verification.

• AA (1 bit): Authoritative Answer: The answer originated from an official server that controls the domain name (it's an "authoritative" source) when this flag is enabled in a response.

• TC (1 bit): TrunCation: The TrunCation flag gets activated when DNS messages exceed UDP size restrictions which require message truncation. The client receives this flag to attempt TCP communication for handling larger messages.

• RD (1 bit): Recursion Desired: The local DNS server receives this bit when your computer initiates a query through your home router or your ISP's server. The server receives this message with the request to locate the answer through other servers when it lacks knowledge about the answer. Do the legwork!" This is called a recursive query.

• RA (1 bit): Recursion Available: In a response, the server sets this bit if it supports doing that recursive legwork. Most local DNS resolvers do.

• Z (1 bit): Reserved for future use. It's always set to 0. Just a spare bit for now!

• AD (1 bit): Authentic Data (used with DNSSEC): If set in a response, it means the server has cryptographically verified the data as genuine.

• CD (1 bit): Checking Disabled (used with DNSSEC): If set in a query, it tells servers not to bother with cryptographic checks for this lookup (maybe the client wants to do its own checks).

• RCODE (4 bits): Response Code: Tells you if everything went okay or if there was an error. 0 means "No error!" Other codes can mean things like "Format error" (the query was garbled), "Server failure" (the server had a problem), or "Name Error" (the domain name doesn't exist).

• QDCOUNT (16 bits): Question Count: How many questions are in the "Question" section (usually just 1).

• ANCOUNT (16 bits): Answer Count: How many resource records are in the "Answer" section.

• NSCOUNT (16 bits): Authority Record Count: How many records are in the "Authority" section.

• ARCOUNT (16 bits): Additional Record Count: How many records are in the "Additional" section.

The DNS Question: What Are You Asking?

This section specifies what the client wants to know.

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ QNAME / // The domain name being queried
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QTYPE | // What type of info (IP, mail server, etc.)?
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QCLASS | // Usually "IN" for Internet
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

• QNAME: The domain name you're looking up, like www.google.com. Each part of the name (www, google, com) is preceded by a byte that tells you how long that part is. So, www.google.com might look like 3www6google3com0 (the 0 at the end marks the end of the name).

• QTYPE: What kind of information do you want for this name? An A record for an IPv4 address? An AAAA record for an IPv6 address? An MX record for a mail server? There are many types!

• QCLASS: The "class" of the query. For internet stuff, this is almost always IN (for Internet).

Resource Records (RRs): The Actual Data

The Answer, Authority, and Additional sections are all made up of Resource Records. Each RR contains a specific piece of information.

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ NAME / // The domain name this record is about
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE | // Type of this record (A, MX, etc.)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS | // Usually "IN"
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL | // How long to cache this (in seconds)
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH | // How long is the RDATA field?
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA / // The actual data (IP address, name, etc.)
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

• NAME: The domain name this record is about.

• TYPE: The type of this resource record (e.g., A, AAAA, MX, CNAME).

• CLASS: Again, usually IN for Internet.

• TTL (Time To Live): This is super important! It's a number (in seconds) that tells computers how long they should "cache" (remember) this information. If the TTL is 3600, it means "remember this for one hour." After the TTL expires, the computer should ask for fresh information. This helps reduce DNS traffic and ensures information eventually gets updated.

• RDLENGTH: How long (in bytes) the RDATA field is.

• RDATA (Resource Data): This is the actual meat of the record!

• For an A record, RDATA is the IPv4 address.

  • For an MX record, RDATA contains the priority and name of a mail server.

  • The format of RDATA depends entirely on the TYPE and CLASS of the record.

Domain Name Compression: Saving Space

Domain names tend to become lengthy and duplicate segments such as.com or.org. DNS achieves faster message transmission through name compression which reduces DNS message size.

DNS uses pointers to shorten DNS messages by referencing previously mentioned domain names or their parts within the same message. A pointer consists of two bytes. The first two bits of this sequence always represent the number 11. The computer recognizes this sequence as a pointer because the first two bits are always 11. The following 14 bits represent an offset which functions similarly to a location marker pointing to a specific spot in the entire DNS message starting from its beginning.

The system can replace repeated domain name segments with pointers that direct the system to the initial occurrence of example.com within the message. Smart, huh?

Common Resource Record Types: What Info Can DNS Hold?

DNS isn't just for IP addresses. It can store various types of info. Here are some of the most common record types you'll see:

• A (Address) Record (Type 1): Maps a domain name (like www.google.com) to an IPv4 address (e.g., 172.217.160.142). This is the most basic and common lookup.

• AAAA (Quad A) Record (Type 28): Similar to an A record, but maps a domain name to an IPv6 address (the newer, longer IP addresses, like 2a00:1450:4009:820::200e).

• MX (Mail Exchange) Record (Type 15): Tells email systems where to send email for a domain. For example, the MX record for example.com might point to mail.example.com. It includes a priority number, so if there are multiple mail servers, it knows which one to try first.

• CNAME (Canonical Name) Record (Type 5): Creates an alias or nickname. For instance, ftp.example.com might be a CNAME pointing to server7.example.com. If you look up ftp.example.com, DNS will tell you, "Actually, look up server7.example.com instead." Important note: A CNAME can't usually exist for a domain name if other record types (like MX) also exist for that exact same name.

• NS (Name Server) Record (Type 2): Delegates a DNS zone to an authoritative nameserver. For example, the .com name servers will have NS records for google.com that point to Google's own DNS servers (like ns1.google.com). This is how DNS is hierarchical – it tells you who to ask next.

• SOA (Start of Authority) Record (Type 6): Every DNS zone (like example.com) must have exactly one SOA record. It's like the main administrative record for the zone. It contains:

• The primary nameserver for the zone.

  • Contact email for the domain administrator (with @ replaced by a .).

  • Serial number (a version number for the zone file; increases with each change).

  • Timers for refresh, retry, expire, and negative caching TTL.

• PTR (Pointer) Record (Type 12): Does the reverse of an A or AAAA record. It maps an IP address back to a domain name. This is used for things like checking if an email server is legitimate or for some logging purposes. These live in a special domain called in-addr.arpa (for IPv4) or ip6.arpa (for IPv6).

• TXT (Text) Record (Type 16): Allows domain admins to put almost any kind of text-based information into DNS. Often used for:

• SPF (Sender Policy Framework) records to help prevent email spoofing.

  • DKIM (DomainKeys Identified Mail) signatures for email authentication.

  • Domain ownership verification (e.g., Google Search Console might ask you to put a specific TXT record to prove you own a domain).

• The SRV (Service) Record (Type 33) provides more advanced functionality than MX records because it enables services (such as VoIP or instant messaging) to specify both a hostname and port number and service priority and weight. The system becomes more efficient at finding particular services within a domain through this feature.

• DNSKEY (Type 48), RRSIG (Type 46): Used by DNSSEC (DNS Security Extensions). The DNSKEY record contains public cryptographic keys while RRSIG records store digital signatures for other DNS records. These security features enable DNS data authentication and protection against unauthorized modifications.

• CAA (Certification Authority Authorization) Record (Type 257) enables domain owners to define which Certificate Authorities (CAs) can issue SSL/TLS certificates for their domain. The security feature functions as a protective measure to stop unauthorized certificate issuance.

DNS Transport Protocols: How DNS Messages Travel

DNS messages require a method to reach DNS servers from your computer. The two primary internet transport protocols which DNS uses are UDP (User Datagram Protocol) on port 53 and TCP (Transmission Control Protocol) on port 53.

• UDP (User Datagram Protocol) on port 53:

• The process of sending a postcard through UDP functions as an analogy. The transmission method operates at high speed while maintaining minimal overhead requirements.

  • The majority of DNS queries contain data that can be transmitted within one UDP packet without needing the guaranteed connection features of TCP. It's "fire and forget."

  • The traditional DNS message size limit for UDP transmissions was 512 bytes.

• TCP (Transmission Control Protocol) on port 53:

• TCP functions like a tracked package delivery system that needs signature verification. The system creates connections to ensure message delivery while maintaining message sequence order. It has more overhead than UDP.

  • DNS uses TCP when:

  • When DNS answers exceed the maximum UDP packet size (originally 512 bytes but now typically larger due to EDNS0), servers may send truncated responses over UDP with the TC flag set to instruct clients to perform a TCP retry.

    • Zone Transfers (AXFR/IXFR): The process of transferring entire DNS database sections between DNS servers occurs through TCP because large amounts of data need reliable transfer.

    • Some newer DNS security protocols (like DoT) specifically use TCP.

More recently, with privacy in mind:

• DNS over TLS (DoT) typically uses TCP port 853.

• DNS over HTTPS (DoH) typically uses TCP port 443 (the standard HTTPS port).

EDNS0 (Extension Mechanisms for DNS): Bigger and Better Messages

The DNS message size restriction of 512 bytes through UDP transmission became problematic because DNSSEC introduced additional response data. The constant TCP fallback for messages that exceeded the 512-byte limit proved inefficient.

EDNS0 (RFC 6891) came to the rescue! The system extends DNS functionality through optional features rather than representing a new DNS version. The EDNS0 protocol enables both clients and servers to indicate their ability to process larger UDP packets.

The DNS message includes an OPT record as a pseudo-resource record which functions as an extension in the "Additional" section. The OPT record contains information that allows the receiving end to understand the following message:

• "Hey, I can handle UDP packets up to 4096 bytes!" (or some other size).

• The OPT record includes additional flags and response codes which were not present in the original DNS header.

EDNS0 is crucial for modern DNS, especially for DNSSEC, which often has larger responses due to the cryptographic signatures.

DNSSEC: Making DNS Trustworthy

The DNS system faced its biggest historical weakness because it lacked proper security measures. The original DNS responses lacked digital signatures which made them vulnerable to attacks through:

• A DNS query interception allowed attackers to send back false responses known as "spoofed" responses.

• A DNS cache poisoning attack occurs when an attacker tricks a DNS resolver into storing incorrect records. A poisoned DNS cache at an ISP resolver would redirect numerous users to fraudulent websites instead of their intended destinations such as banks or email services. The process resembles someone altering a phonebook entry to direct users to a fraudulent number.

DNSSEC (DNS Security Extensions) implements digital signatures to protect DNS data from tampering. Here's the basic idea:

• Domain owners create cryptographic key pairs which include a public key and a private key for their domain. The public key becomes available to the public through DNS via a DNSKEY record.

• A DNS server includes digital signatures for its data (such as A records) when it provides information through its private key. The signature exists within an RRSIG record.

• A DNSSEC-aware DNS resolver verifies DNS response data by obtaining the DNSKEY record to validate the RRSIG signature using the public key. The data remains authentic because the signature verification process shows no evidence of tampering when the signature proves valid.

Key DNSSEC record types:

• DNSKEY: Holds the public keys used to verify signatures.

• RRSIG (Resource Record Signature): Contains the actual digital signature for a set of records (e.g., all A records for www.example.com).

• DS (Delegation Signer): This is how trust is chained. When example.com publishes its DNSKEY, the.com zone (its parent) will have a DS record for example.com. This DS record is a hash (a fingerprint) of example.com's DNSKEY, and the DS record itself is signed by the.com zone's key. This creates a chain of trust all the way up to the internet's root zone, which is the ultimate source of trust.

• NSEC (Next Secure) / NSEC3: These records provide "authenticated denial of existence." They cryptographically prove that a domain name doesn't exist, preventing attackers from tricking you into thinking a non-existent malicious domain is real. NSEC3 is an improvement that helps prevent "zone walking" (trying to list all names in a zone).

The DNSSEC system establishes a "chain of trust" which starts at the root zone of the DNS hierarchy and extends down to individual domain names. The trust in the root zone enables trust in ".com" and ".com" enables trust in example.com when all signature checks pass.

The DNS Query Journey: How Your Computer Finds an IP Address

The process behind your website address typing begins an extensive operation. A normal query process functions as follows when the browser does not hold the answer in its cache.

1. You type, computer asks: your web browser initiates the IP address retrieval of www.somecoolsite.com, that you want to visit, to your computer operating system.
   A stub resolver operates under the OS as the lightweight DNS client to perform this function.

2. Your stub asks local resolver. It begins a recursive query to find the configured DNS resolver. The DNS resolution process starts at your Internet Service Provider's server or your home router's server or through public DNS services like Google Public DNS (8.8.8.8) or Cloudflare (1.1.1.1). The "recursive" function directs this resolver to obtain the full answer.

3. The resolver checks its memory cache before proceeding with the query. When the resolver possesses the requested answer it returns it directly to you and the process ends.

4. The system starts performing iterative queries when cache lookup fails. Each DNS server in this process receives the request to move the answer closer to its final form.

5. Step 1: The resolver initiates contact with a root server to begin the process. (There are 13 main root server "addresses," but hundreds of actual servers worldwide using a technology called anycast). The root server maintains knowledge about the ".com" TLD management but lacks information regarding the IP address of www.somecoolsite.com. The server responds with a referral directs you to ask the.com TLD nameservers since it does not have the answer. You will find the IP addresses of the ".com" TLD nameservers in the reply.

   • Step 2: The resolver selects a.com TLD nameserver to request the IP address for www.somecoolsite.com. The TLD server lacks the specific IP information but holds knowledge about the somecoolsite.com domain's authoritative nameservers which manage its DNS records through the domain registrar or hosting provider. The nameserver IP addresses for somecoolsite.com (ns1.somecoolsitehosting.com and ns2.somecoolsitehosting.com) are provided by this referral message because the server does not possess the requested information.

   • Step 3: The resolver will now contact one of the authoritative nameservers for somecoolsite.com to obtain the IP address for www.somecoolsite.com. The server maintains complete knowledge about the requested domain since it functions as the domain's authority.

6. The server retrieves the A record (or AAAA record) and delivers it to the resolver.
   The resolver transfers the IP address to you after adding it to its cache. The resolver shares this information with your operating system and stub resolver. After obtaining the answer the resolver stores it locally for the TTL duration so it can respond immediately to repeated requests for the same address.

7. Your computer receives the IP address to proceed with browser connections to www.somecoolsite.com's web server.

Phew! That's quite a journey, but it usually happens in milliseconds!

Modern DNS Upgrades: More Security & Privacy!

DNS keeps evolving. The original designers probably didn't imagine a world where online privacy and security would be such huge concerns. Here are some newer ways DNS is getting better:

DNS over TLS (DoT)

• What it is: Traditional DNS queries are sent in plain text. Your network traffic becomes visible to anyone who monitors your public Wi-Fi connection because they can see your website requests.

• Your DNS queries become protected through TLS encryption when you use DoT because this protocol uses the same encryption methods that HTTPS websites employ (you can see the padlock khóa in your browser).

• The encryption system protects your DNS queries from eavesdropping and man-in-the-middle attacks which attempt to modify your DNS queries or responses.

• Port: DoT usually runs on TCP port 853.

DNS over HTTPS (DoH)

• The encryption method of DoH functions similarly to DoT because it protects DNS queries through standard HTTPS transmission.

• How it helps:

• Same security as DoT: Prevents snooping and tampering.

  • The encryption of DoH traffic through TCP port 443 makes it difficult for network administrators or restrictive firewalls to detect and block encrypted DNS traffic.

  • The HTTP/2 multiplexing feature enables better efficiency through sending multiple requests over one connection.

  • Some browsers are starting to support DoH directly.

DNS over QUIC (DoQ)

• What it is: DoQ (RFC 9250) uses a newer transport protocol called QUIC for DNS. QUIC is designed to be faster and more efficient than TCP, especially on unreliable networks, and it has encryption built-in (like TLS).

• How it helps: Aims to give you the security of DoT/DoH but with potentially better performance and connection setup times. It's still quite new but gaining traction.

DNS Query Minimization (QMIN)

What it is: Remember how the resolver initiates the process by requesting www.somecoolsite.com from the root server? The resolver follows traditional DNS procedures by sending the complete domain name to the root server before it moves to the TLD server and then to the authoritative server. Query Minimization (RFC 7816) modifies this process to improve privacy protection.

How it helps: The resolver sends only the required domain name segment to each server during the query process.

• The resolver makes a simple request to the root server for.com server information.

• The resolver sends a query to the.com TLD server asking for server information about somecoolsite.com.

• The resolver asks the full question "What's the IP for www.somecoolsite.com?" to the authoritative server that handles somecoolsite.com.

The process minimizes information disclosure to intermediate servers which makes it more challenging for them to determine your complete domain name queries.

Conclusion: DNS is Awesome (and Still Evolving!)

DNS operates as an advanced directory system beyond basic phonebook functionality. The system operates as a powerful flexible 'organism' which continues to evolve. The hierarchical and distributed structure of DNS enables it to expand with the internet from its small network origins into the global giant it has become without compromising reliability.

The security and privacy challenges of the 80s receive attention through DNSSEC and DoT and DoH and DoQ upgrades. DNS maintains its fitness for internet safety and privacy protection through these updates.

The DNS technology provides valuable knowledge to anyone interested in internet operations particularly those who study networking and cybersecurity and web development. The internet's evolution will continue to drive DNS adaptation yet its fundamental role as the internet's intelligent address directory remains vital.

Remember: The explanation provided a detailed overview of DNS operations. Before establishing your DNS server or configuring specific settings always consult official RFC documents together with software manual instructions.