What is DNS? (and how it makes the Internet work)

Typing a domain name into a browser works because DNS (Domain Name System) translates human-friendly names into the IP addresses computers actually use to connect. Without that translation layer, websites, email, and much of the internet would fail—often in ways users only notice when DNS breaks or is tampered with.

The process starts locally. A browser’s DNS client (a “stub resolver”) first checks its own cache to see whether the domain’s IP address is already known. If it’s not, the stub resolver sends a DNS query to a configured DNS server—commonly an ISP-provided resolver or a public one such as Google Public DNS at 8.8.8.8. That DNS server typically acts as a recursive resolver: it may not know every answer immediately, so it performs additional lookups on the user’s behalf.

To find the right destination, DNS relies on a hierarchy. At the top sit root servers, operated under the governance of ICANN (Internet Corporation for Assigned Names and Numbers). Root servers don’t map specific domains to IP addresses; instead, they point recursive resolvers toward the correct top-level domain (TLD) servers—such as .com, .net, or country codes like .jp. For a domain like academy.networkchuck.com, the recursive resolver asks the .com TLD servers who manages the second-level domain (networkchuck.com). Those TLD servers respond with authoritative name servers for that domain.

In the example, the authoritative DNS provider for networkchuck.com is Cloudflare. The recursive resolver then queries Cloudflare’s authoritative server, which holds the domain’s zone file—records that include the A record mapping academy.networkchuck.com to its IPv4 address (shown as 104.18.40.213 in the walkthrough). Once the recursive resolver has the answer, it updates its cache and returns the IP address to the stub resolver, allowing the browser to connect.

DNS isn’t just a name-to-IP lookup. The zone file can include NS records (which servers are authoritative), AAAA records (IPv6 mappings), MX records (mail servers), PTR records (reverse DNS), CNAME records (aliases), and TXT records (text metadata). TXT records are especially important for email security, where SPF helps identify which mail servers are allowed to send for a domain, and DKIM (via DKIM-related TXT records) helps verify that messages weren’t altered in transit.

Security is a major theme. By default, DNS queries often use UDP port 53 in plaintext, making them vulnerable to interception and manipulation—DNS spoofing can redirect users to malicious IP addresses. Even ISPs can observe DNS lookups. A key mitigation is DNS over HTTPS (DOH), which wraps DNS queries inside encrypted HTTPS traffic so they blend into normal web traffic and can’t be easily read or altered in transit.

The walkthrough also highlights practical deployment: DOH requires both client and DNS server support, and it can be enforced across devices using tools like Twin Gate. Beyond DOH, other protections mentioned include DNS over TLS (DOT), DNSCrypt, and DNSSEC (which validates that responses are authentic). The broader takeaway is that DNS is foundational infrastructure—fast when it works, and surprisingly consequential when it doesn’t.