Domain Name System (DNS)

The Domain Name System (DNS) is a hierarchical, decentralized naming system that translates human-friendly names like example.com into IP addresses like 122.250.192.232. Without it we'd have to memorize numbers instead of names.

1. Learning Objectives

By the end of this lesson, you will be able to:

• Deconstruct the hierarchical architecture of the Domain Name System, explaining the distinct roles of Resolver, Root, TLD, and Authoritative servers.
• Differentiate between recursive and iterative DNS resolution flows with packet-level and protocol characteristics.
• Identify and configure critical DNS record types, including A, AAAA, CNAME, MX, NS, TXT, SOA, SRV, and CAA, matching them to their primary architectural use cases.
• Analyze DNS caching mechanics, TTL behaviors, propagation latency, and mitigation strategies for stale records.
• Evaluate advanced global traffic routing strategies, including Geolocation, Geoproximity, Latency-based, Failover, and Weighted routing.
• Deconstruct key security paradigms such as DNSSEC, DoH, and DoT, detailing how they mitigate modern threat vectors.

2. Prerequisites

To get the most out of this deep dive, you should be familiar with:

• Networking Fundamentals: Basic understanding of IPv4/IPv6, CIDR blocks, TCP, UDP, and the client-server request-response pattern.
• Layer 4 vs. Layer 7 Protocols: Knowing the difference between transport layer routing (ports, connection establishment) and application layer payloads.
• Web Browsing Lifecycle: General familiarity with what happens when you type a URL into a web browser.

3. Why This Topic Matters

The Domain Name System (DNS) is not merely a naming index; it is the fundamental routing plane of the global internet. If DNS breaks, your entire infrastructure becomes unreachable to users, regardless of how redundant your application servers, databases, or load balancers are. For example, in 2016, a major DDoS attack on the DNS provider Dyn brought down major services like GitHub, Twitter, and Netflix for millions of users worldwide.

In system design interviews and real-world engineering, DNS is critical because it:

• Minimizes Latency: Serves as the initial round trip before any connection can be established. An unoptimized DNS setup can add hundreds of milliseconds of latency to your initial page load.
• Acts as a Global Load Balancer: Directly dictates how client requests are distributed across data centers using techniques like Anycast, Latency routing, and GeoDNS.
• Provides Disaster Recovery: Serves as the ultimate failover mechanism, allowing traffic to be redirected away from unhealthy regions or cloud providers at the edge of the network.

4. Real-world Analogy

Imagine attempting to locate a specific employee, Jane Doe, at a multinational corporation named Acme Corp, starting from a physical street directory but not knowing the company's location or phone number.

1. The Stub Resolver (Your Assistant): You ask your personal assistant (the client resolver) to find Jane Doe's phone number.
2. The Root Server (The Corporate Lobbyist): Your assistant runs to the main national business registry (Root Server). The registry doesn't know Jane's direct extension, but it knows where all corporation records are kept. It points your assistant to the Corporate Registry for companies ending in ".corp" (the Top-Level Domain server).
3. The TLD Server (The Company Directory): The assistant visits the ".corp" registry (TLD Server). This directory doesn't have Jane's phone number either, but it knows the address of Acme Corp's headquarters directory (Authoritative Nameserver).
4. The Authoritative Server (Acme's Receptionist): The assistant travels to Acme Corp's headquarters and talks to the receptionist (Authoritative Nameserver), who maintains the official internal phone book. The receptionist looks up Jane Doe and provides the direct extension: +1 (555) 019-9232 (the IP address).
5. Caching: Your assistant writes Jane's extension in a personal notebook (Local Cache). The next time you ask for Jane, the assistant skips the trip to the registry and dials the number directly.

5. Core Concepts

To master DNS, you must understand its core architectural layers:

• The Domain Name Space Hierarchy: A tree structure consisting of:
  • Root Zone: Represented by a dot (.) at the end of a domain name (typically hidden in browsers, e.g., example.com.).
  • Top-Level Domains (TLDs): Separated into generic TLDs (gTLDs like .com, .net, .org) and country-code TLDs (ccTLDs like .uk, .de, .jp).
  • Second-Level Domains (SLDs): The custom names registered by organizations (e.g., google in google.com).
  • Subdomains: Additional layers created under the SLD (e.g., api.google.com).
• Recursive vs. Iterative Resolvers:
  • Recursive Resolver (Recursor): The system (usually run by your ISP, Google, or Cloudflare) that accepts a query from a client and does all the legwork of querying root, TLD, and authoritative servers to return the final answer.
  • Iterative Query: A query where the server returns the best answer it has (usually a reference to another nameserver) instead of going out to fetch it. Resolvers query root and TLD servers iteratively.
• Time To Live (TTL): An integer value attached to every DNS record representing the duration (in seconds) the record is allowed to be cached by resolvers and client stub resolvers before a fresh lookup is required.

6. Visualization

Below is a visual representation of the DNS Resolution Flow. The diagram shows the path a lookup takes from the client's web browser down to the recursive resolver, and the subsequent iterative lookups to the root, TLD, and authoritative nameservers.

The diagram below demonstrates the step-by-step query routing:

7. How It Works

When you type a domain name like www.example.com into your browser, a multi-stage search takes place behind the scenes:

1. Browser Cache Check: The browser checks its internal cache to see if the domain's IP is already stored (e.g., chrome://net-internals/#dns).
2. OS Cache & Hosts File Check: If not found, the browser calls the OS getaddrinfo() function. The OS checks its own cache, then consults the local hosts file (/etc/hosts on Unix or C:\Windows\System32\drivers\etc\hosts on Windows).
3. Recursive Resolver (ISP or Public DNS): If still unresolved, the OS stub resolver sends a recursive query (using UDP port 53) to the configured Recursive Resolver (e.g., 8.8.8.8 or 1.1.1.1).
4. Root Name Server Query: The resolver, finding no cached entry, queries one of the 13 logical Root Name Servers (represented by a.root-servers.net through m.root-servers.net). The root server does not know the IP of the domain but reads the suffix (.com) and returns the IP address of the Top-Level Domain (TLD) server for .com.
5. TLD Name Server Query: The resolver queries the TLD nameserver. The TLD server reads the domain (example.com) and responds with the IP addresses of the domain's Name Server (NS) records—the Authoritative Nameservers.
6. Authoritative Name Server Query: The resolver queries the Authoritative Nameserver. This server is the final source of truth managed by the domain owner. It looks up its zone records and returns the IP address associated with www.example.com (typically an A or AAAA record).
7. Caching and Response: The recursive resolver stores the IP address and its associated Time To Live (TTL) in its local cache and forwards the IP address back to the OS stub resolver. The OS and browser cache the result, and the browser can finally open a TCP connection to the destination IP address.

8. Internal Architecture

The DNS ecosystem is a highly distributed, decentralized system consisting of several distinct actors and physical machines. The table below outlines their primary roles, placement, and architectural failure modes.

9. Request Lifecycle

Under the hood, a standard DNS request relies primarily on the UDP protocol. Let's trace the lifecycle of a packet and how it handles constraints:

1. UDP Transmission (Port 53)

DNS requests default to UDP port 53. Because UDP is connectionless, it has very low overhead, requiring only a single request packet and a single response packet. A standard DNS query packet size must fit within 512 bytes to avoid IP fragmentation, as dictated by early RFC specifications.

2. TCP Fallback (Port 53)

If a resolver receives a response that exceeds 512 bytes (common with DNSSEC keys or large TXT records), the server sets the Truncation (TC) flag in the header. Upon seeing the TC flag, the resolver initiates a TCP connection on port 53 to retrieve the complete packet safely. Modern DNS servers also utilize EDNS0 (Extension Mechanisms for DNS) to negotiate larger UDP packet sizes (often up to 4096 bytes) to prevent the latency penalty of falling back to a TCP handshake.

3. Byte Structure of a DNS Message

A DNS packet consists of five main sections, aligned on byte boundaries:

• Header (12 bytes): Contains ID (to match requests and responses), flags (Query/Response, Opcode, Authoritative Answer, Truncation, Recursion Desired, Recursion Available, Response Code), and counters for the next four sections.
• Question Section: The query domain name (encoded as labels, e.g., [3]www[7]example[3]com[0]) and the record type (e.g., A record, type 1).
• Answer Section: The actual resource records answering the query.
• Authority Section: Pointers to authoritative name servers for the domain.
• Additional Section: Helpful helper records, such as Glue records providing the IP addresses of the authoritative servers mentioned in the Authority section.

10. Deep Dive

To design enterprise-grade networks, you must understand several advanced DNS mechanisms:

1. Anycast Routing

Traditionally, in Unicast routing, one IP address belongs to exactly one physical computer. In Anycast routing, multiple physical servers around the world share the exact same IP address. Routers use Border Gateway Protocol (BGP) to advertise these paths, directing the client's packet to the topographically closest instance. If a physical node fails, BGP automatically updates, routing packets to the next closest healthy instance without changing the IP. This is how 13 root IPs and systems like Cloudflare's 1.1.1.1 serve hundreds of millions of requests per second.

2. DNSSEC (Domain Name System Security Extensions)

The original DNS protocol had no mechanism to verify the authenticity of records, leaving it highly vulnerable to cache poisoning. DNSSEC introduces public-key cryptography to authenticate DNS data. The authoritative zone signs each record (e.g., A, CNAME) with a private key, producing a RRSIG (Resource Record Signature) record. The public key is stored in a DNSKEY record. Resolvers verify this signature up the chain of trust to the root key, ensuring that the response has not been tampered with or forged.

3. EDNS Client Subnet (ECS)

When recursive resolvers query authoritative servers, they act as proxies, masking the client's real IP address. An authoritative server routing traffic based on location (GeoDNS) would route based on the resolver's IP rather than the client's. If a user in New York uses a resolver in London, they might be directed to a European server. ECS solves this by passing a truncated version of the client's IP subnet (e.g., 73.140.0.0/16) inside the DNS request packet, allowing the authoritative server to route traffic accurately based on client location.

4. DoH (DNS over HTTPS) and DoT (DNS over TLS)

Standard DNS is unencrypted, making it easy for ISPs, public Wi-Fi networks, and eavesdroppers to track websites users visit. DoH and DoT encrypt these queries:

• DNS over TLS (DoT): Wraps raw DNS queries in TLS on a dedicated port (TCP 853). It is easy to block at the network level because of its unique port.
• DNS over HTTPS (DoH): Wraps queries in standard HTTPS requests over port 443. This makes DNS traffic indistinguishable from normal web traffic, preventing network-level censorship or inspection.

11. Production Example

Let's examine how a global platform like Netflix or AWS Route 53 implements production-grade DNS traffic routing to achieve 100% uptime and minimal latency:

1. Routing Policies

Modern authoritative DNS engines do not merely return a static IP. They execute dynamic rules in real-time:

• Weighted Round Robin: Distributes traffic based on static weights (e.g., routing 80% of traffic to version 1 and 20% to version 2 for canary deployments).
• Latency-based Routing: Routes clients to the AWS region that provides the lowest network latency. The DNS provider continuously measures round-trip times between various client IP ranges and AWS data centers to build dynamic mapping tables.
• Geoproximity / Geolocation: Geoproximity routes traffic based on physical distance, whereas Geolocation routes based on matching the client's country/state to designated endpoints (useful for localization and content compliance).
• Failover (Active-Passive): Combined with active health check agents. The DNS nameserver checks the health of the primary IP address (e.g., via HTTP pings). If the health check fails, the DNS engine immediately stops resolving to the failed IP and responds with the backup IP.

12. Advantages

• Abstraction Layer: Decouples human-readable application names from physical IP addresses, enabling servers to change IPs without disrupting users.
• Load Balancing at the Edge: Enables distributing client connections globally before they ever hit load balancers or application endpoints.
• Massive Scalability: The hierarchical caching architecture reduces the query load on root servers to a tiny fraction of global traffic.
• High Availability: Through Anycast and multi-provider DNS setups, nameservers can achieve high resilience and resist severe network outages.

13. Limitations

• Propagation Delay: Changes to DNS records do not take effect immediately worldwide due to downstream caching. Changes can take minutes to hours (or days if TTL is high).
• Cache Inconsistency: Some recursive DNS servers or client-side operating system libraries ignore TTL settings and cache records longer than requested.
• Privacy Concerns: By default, DNS queries are sent in plaintext, allowing third parties to track the domains a client visits.
• Vulnerability to DDoS: Since it is the front door of the internet, authoritative DNS systems are constant targets for high-volume DDoS attacks.

14. Trade-offs

When configuring your DNS architecture, you must balance several competing forces:

1. Low TTL vs. High TTL

A low TTL (e.g., 60 seconds) allows you to update your DNS records rapidly, facilitating swift failover or migrations. However, it forces client resolvers to query your authoritative servers far more frequently, adding network latency to client requests and increasing your DNS query hosting costs. Conversely, a high TTL (e.g., 86400 seconds / 24 hours) speeds up lookups through caching, but locks you out of fast recovery in the event of an outage.

2. EDNS Client Subnet (ECS) Enabled vs. Disabled

Enabling ECS allows precise, localized routing for users, minimizing latency. However, passing user IP subnets across networks presents a potential user privacy risk. It also decreases caching efficiency on DNS recursive resolvers because cache records must be split by client subnet rather than shared globally for the domain.

15. Performance Considerations

Optimizing DNS performance is critical to minimizing the Time to First Byte (TTFB). Key performance optimizations include:

• DNS Prefetching: Informing modern browsers to resolve hostnames before a user clicks a link (e.g., using <link rel="dns-prefetch" href="//api.example.com">).
• Keep-Alives for TCP Fallback: Ensuring that resolvers support persistent connections to authoritative servers when using TCP to avoid connection handshake overhead.
• Leveraging Public DNS Anycast Resolvers: Migrating users to use public recursive resolvers like Cloudflare (1.1.1.1) or Google Public DNS (8.8.8.8) which feature huge global cache pools and near-zero latency.

16. Failure Scenarios

Understanding DNS failures helps engineers design resilient failover configurations:

• Cache Poisoning (Spoofing): An attacker floods a recursive resolver with forged responses containing incorrect IP addresses. If the resolver accepts the response (e.g., because it guessed the matching 16-bit transaction ID), it will cache the attacker's IP, redirecting all subsequent users to a malicious site.
• DDoS on Authoritative Nameservers: If a DDoS attack overwhelms your authoritative nameservers, recursive resolvers cannot refresh expired records. Once TTLs expire, your website becomes unreachable globally.
• Glue Record Outages: If nameservers for example.com are set to ns1.example.com, a circular dependency occurs. The resolver needs to resolve ns1.example.com to contact the nameserver, but it cannot contact the nameserver to do so. Failing to register a "Glue Record" (IP mapping for the nameserver at the TLD registrar level) results in a total resolution failure.

17. Best Practices

• Implement Multi-Provider (Dual) DNS: Use two independent DNS providers (e.g., Route 53 and Cloudflare) in an active-active setup. If one provider suffers an outage or DDoS, the client's resolver automatically retries using the second provider's nameservers.
• Align TTLs with Change Windows: Set short TTLs (e.g., 60-300s) for dynamic records, and long TTLs (e.g., 86400s / 1 day) for highly stable records (like NS, MX, or root domain aliases) to reduce load and latency.
• Pre-Migration TTL Reduction: When migrating servers, lower the TTL of the target record to 60 seconds several days before the migration. Once the migration is complete and stable, restore the TTL to its original higher value.
• Monitor DNS Health: Put alerts on DNS performance metrics, checking latency, packet drop rates, and authoritative response correctness from locations around the globe.

18. Common Mistakes

• CNAME at the Zone Apex: According to RFC 1034, a CNAME record cannot coexist with any other record of the same name. Because a zone apex (e.g., example.com) must have SOA and NS records, configuring a CNAME at the apex (e.g., pointing example.com to a load balancer) breaks resolution. Mitigation: Use ALIAS or ANAME records offered by DNS providers, which dynamically resolve the target to A records at query time.
• Circular Nameserver References: Directing NS records to subdomains of the zone without registering Glue Records at the TLD registry.
• Over-Reliance on a Single DNS Provider: Believing that cloud DNS providers are immune to outages, leading to single points of failure.
• Aggressive TTL Zero (0): Configuring TTL to 0 to prevent caching entirely. Some resolvers interpret TTL 0 as a command to cache for default values, while others overwhelm your server with queries.

19. Implementation

To truly understand DNS, let's look at a complete, working Python script that constructs a raw, binary DNS query for an A record, sends it over a UDP socket to a public resolver (Google's 8.8.8.8), and parses the response packet at the byte level.

20. Interview Questions

Easy: What are the main DNS record types and their functions?

Answer: The critical DNS record types include:

• A Record: Maps a domain name (e.g., example.com) to an IPv4 address.
• AAAA Record: Maps a domain name to an IPv6 address.
• CNAME (Canonical Name): Points a domain alias to another domain name (e.g., www.example.com pointing to example.com).
• MX (Mail Exchanger): Directs emails to the correct mail servers for the domain, featuring a priority value.
• TXT (Text): Stores arbitrary text, commonly used for domain ownership verification (e.g., Google Search Console) and email security (SPF, DKIM).
• NS (Name Server): Identifies the authoritative nameservers responsible for the zone.

Medium: Explain the exact differences between a recursive DNS query and an iterative DNS query.

Answer:

• Recursive Query: The client delegating the search demands a complete, final resolution. If the resolver does not have the answer cached, it must query other servers until it finds the IP address or gets a definitive error. The client does one request and gets one final response.
• Iterative Query: The querying server (typically the recursive resolver contacting Root/TLD servers) asks a nameserver for an answer. If the nameserver does not possess the record, it returns a reference to another nameserver lower in the hierarchy (e.g., "I don't know, but ask the .com server at this IP"). The client resolver is responsible for making the next call.

Hard: How does Anycast routing protect against DDoS attacks, and what are its limitations?

Answer: Anycast routing assigns the same IP address to multiple geographically distributed edge servers. When a DDoS attack strikes an Anycast IP address, the malicious traffic is naturally localized and routed to the nearest physical datacenter containing that IP, distributing the load across multiple globally isolated nodes. This prevents the attack traffic from overwhelming a single central point of failure, keeping the rest of the nodes healthy and online.

Limitations: Anycast is complex to set up, requiring control over BGP routing. Furthermore, it operates at the routing level, which does not naturally guarantee connection state. If internet routes change mid-session, a client's TCP packet could be routed to a different physical Anycast node, resulting in broken TCP handshakes. This is why Anycast is perfectly suited for connectionless UDP-based DNS, but presents challenges for stateful TCP operations.

21. Practice Exercises

These hands-on exercises will test your practical command of DNS tools and concepts (No answers provided):

Easy: Diagnostic Command Mastery

Use the terminal utility dig or nslookup to query the DNS records of wikipedia.org. Find its A, MX, and NS records. Identify which DNS nameserver answered your request, and output the TTL remaining for the cached record on your local resolver.

Medium: DNS Tracing Analysis

Run a full query trace using dig wikipedia.org +trace. Analyze the output to identify every node contacted along the path: identify the IP addresses of the root server, the TLD server, and the authoritative nameserver that resolved the final query.

Hard: Multi-provider Failover Simulation

Draft a BIND zone configuration file that implements a simulated split-horizon DNS routing setup where queries from internal IP networks (e.g., 10.0.0.0/8) get resolved to internal private IP addresses, while external queries get resolved to public load balancer IPs.

22. Challenge Problem

Scenario: You are the Principal Architect at a global e-commerce corporation. During Black Friday, your primary cloud provider's DNS engine suffers a catastrophic routing loop, dropping 95% of incoming DNS queries. The business demands zero downtime and a recovery time objective (RTO) of less than 30 seconds for any component failure.

Design Assignment: Draft an architecture proposal detailing:

• How you will configure an active-active dual-DNS provider architecture.
• The precise configuration of NS records, Glue records, and TTL parameters.
• How client resolvers will respond automatically when one DNS provider's nameservers become unresponsive.
• How to sync DNS record updates dynamically between the two providers (e.g., using dnscontrol or custom zone transfer scripts) to avoid split-brain state configurations.

23. Summary

The Domain Name System (DNS) is the hierarchical, decentralized database that maps friendly names to numeric IP addresses. It consists of the client stub resolver, recursive resolvers (which search on behalf of the client), and a tree structure of nameservers including Root (.), TLD (.com, .net), and Authoritative servers. DNS leverages aggressive caching with Time-To-Live (TTL) variables to limit global traffic overhead. Understanding DNS routing algorithms, UDP/TCP limits, and failover designs is foundational to architecting modern high-availability web applications.

24. Cheat Sheet

25. Quiz

1. Which port and protocol does DNS primarily use for standard queries?
   a) TCP Port 53
   b) UDP Port 53
   c) HTTPS Port 443
   d) TLS Port 853
   Answer: b (Standard queries use UDP 53 because of its speed and lower overhead. Only queries exceeding 512 bytes or DNSSEC verification fall back to TCP 53 or use EDNS).
2. Why is a CNAME record prohibited at the zone apex (e.g., example.com)?
   a) CNAME records cannot handle IPv6 queries.
   b) The zone apex must contain SOA and NS records, and a CNAME cannot coexist with other record types for the same name.
   c) CNAME records do not support TTL caching.
   d) Security protocols prohibit alias records at the root.
   Answer: b (RFC 1034 specifies that CNAME cannot coexist with other records. Since a zone apex must have SOA and NS records, a CNAME is forbidden at the apex).
3. What does DNSSEC primarily protect against?
   a) Distributed Denial of Service (DDoS) attacks
   b) Domain registration hijacking
   c) DNS cache poisoning/spoofing
   d) Unencrypted eavesdropping of domain queries
   Answer: c (DNSSEC uses digital signatures to verify the authenticity and integrity of DNS records, preventing attackers from injecting forged answers).
4. What is the purpose of EDNS Client Subnet (ECS)?
   a) To encrypt the final mile of DNS requests between the client and resolver.
   b) To enable the authoritative nameserver to route traffic based on the client's location rather than the resolver's location.
   c) To fall back automatically to TCP when packets exceed 512 bytes.
   d) To verify that the client has authority to modify DNS records.
   Answer: b (ECS includes a portion of the client's IP address inside the query, allowing authoritative DNS engines to provide geolocation-optimized IPs).
5. Which component is responsible for initiating the recursive lookup process when a browser requests a domain?
   a) Root Nameserver
   b) TLD Nameserver
   c) Recursive Resolver
   d) Web Server
   Answer: c (The Recursive Resolver receives the request from the client and iterates through Root, TLD, and Authoritative servers on the client's behalf).
6. How many logical Root Nameserver IP addresses exist on the global internet?
   a) 8
   b) 13
   c) 256
   d) 1024
   Answer: b (There are 13 logical IP addresses for root servers (a.root-servers.net to m.root-servers.net). However, these are backed by hundreds of physical locations using Anycast).
7. What happens when a DNS query response exceeds 512 bytes and EDNS is not supported?
   a) The response packet is dropped by the router.
   b) The query fails and throws an error.
   c) The server sets the Truncation (TC) flag, prompting the client to retry using TCP port 53.
   d) The resolver uses multiple UDP packets to reconstruct the data.
   Answer: c (If a UDP packet exceeds 512 bytes and EDNS is unavailable, the server truncates the response and sets the TC flag. The client then retries over TCP).
8. If you decrease a record's TTL from 86400 to 60 seconds, when will all resolvers reflect the new target IP?
   a) Instantly.
   b) Within 60 seconds.
   c) Only after the original 86400-second TTL expires from the resolver caches.
   d) After 24 hours plus another 60 seconds.
   Answer: c (A TTL change itself is only read by resolvers when they query the authoritative server. Resolvers that have cached the record with the old 86400s TTL will continue using it until it expires).
9. What is a Glue Record?
   a) A record that binds a CNAME to an A record.
   b) An A record providing the IP address of a nameserver, registered at the parent TLD registry to prevent circular references.
   c) A security TXT record that binds SPF and DKIM signatures.
   d) A record that connects two different DNS providers.
   Answer: b (Glue records provide the IP address of nameservers that are subdomains of the zone they manage, resolving circular lookup dependencies).
10. Which technology encrypts DNS queries to prevent local ISPs from logging domain search history?
    a) DNSSEC
    b) BGP Routing
    c) DoH / DoT
    d) Anycast
    Answer: c (DoH (DNS over HTTPS) and DoT (DNS over TLS) encrypt queries between the client and recursive resolver, protecting DNS privacy).

26. Further Reading

• RFC 1034 & RFC 1035: The foundational standards defining DNS concepts, names, implementation, and specification.
• DNS and BIND (5th Edition) by Cricket Liu & Paul Albitz: The definitive guide to BIND configuration and DNS architecture.
• Cloudflare Learning Center: Comprehensive articles explaining DNSSEC, Anycast routing, and DoH.

27. Next Lesson Preview

Now that we understand how DNS translates names to IP addresses, we will explore the transport protocols that carry this data. In the next lesson, we will compare TCP vs. UDP and deep dive into the 3-way handshake, congestion control, and application protocol selection criteria.