DNS: How Your Browser Translates a Domain into an IP Address

⏱️ Lectura: 12 min

Every time you type a URL into your browser, you have less than a second for that text to turn into an IP address before the actual connection starts. That process is called DNS resolution, and it happens in the background, without you noticing, thousands of times a day.

📑 En este artículo

1. TL;DR
2. What DNS Resolution Is and Why It Matters
3. How It Works: The Journey of a DNS Query
   1. Why Root Servers Don’t Collapse: Anycast
4. Types of DNS Records
5. Practical Examples: Inspecting a Real DNS Resolution
6. Getting Started: Configuring Your Own DNS Records
7. Real-World Use Cases
8. Cache and TTL: Why a Change Takes Time to Propagate
9. DNSSEC: Going Deeper
10. Comparison: Public Resolvers
11. Common Mistakes and Best Practices
12. Frequently Asked Questions
    1. What’s the difference between a recursive resolver and an authoritative server?
    2. Why does a DNS change sometimes take hours to show up?
    3. Is DNS the same thing as DHCP?
    4. Does DNSSEC replace HTTPS?
    5. What is DNS over HTTPS (DoH)?
13. References

Behind that translation lies a chain of up to four different servers, a caching system with scheduled expiration, and a protocol that follows the rules defined in RFC 1035 in 1987.

TL;DR

• You’ll understand the servers involved in every DNS query: recursive, root, TLD, and authoritative.
• You’ll know how to tell apart A, AAAA, CNAME, MX, and TXT records and when to use each one.
• You’ll be able to inspect a real resolution with dig and read the response step by step.
• You’ll understand how DNS caching works and why TTL affects how long a change takes to propagate.
• You’ll know what DNSSEC adds and what specific attack it addresses.
• You’ll be able to configure your own records in a zone file or a provider’s dashboard.
• You’ll know how to diagnose NXDOMAIN errors, expired TTLs, and subdomain takeovers.

What DNS Resolution Is and Why It Matters

The Domain Name System (DNS) is the layer that translates human-readable names like programacion.example into IP addresses like 192.0.2.10 or 2001:db8::1. Without that translation, you’d have to memorize a numeric address for every site you visit.

DNS resolution isn’t a single server answering a question: it’s a hierarchical chain of queries. That hierarchy is what allows millions of domains to coexist without a single central server getting overloaded or becoming a single point of failure.

Think of it like your phone’s contact list: you save “Mom” and the phone knows that means a ten-digit number. DNS does the same thing at internet scale, except that contact list is distributed across millions of servers instead of living on a single device.

The protocol was born in 1983, designed by Paul Mockapetris to replace a single text file (HOSTS.TXT) that Stanford maintained by hand and that no longer scaled with ARPANET’s growth, according to the Wikipedia entry on the system.

How It Works: The Journey of a DNS Query

When you type programacion.example into the address bar, the browser first checks its own cache. If it doesn’t find a valid answer, it hands the query off to the recursive resolver configured in your operating system or router, usually your internet provider’s or a public one like 1.1.1.1 or 8.8.8.8.

The recursive resolver does the heavy lifting: it first asks one of the root servers, historically identified by 13 letters, from A to M, though each letter now corresponds to hundreds of physical instances distributed via anycast. The root server doesn’t know the final IP, but it points to which TLD zone server (.com, .org, .example) to ask.

The TLD server doesn’t have the final answer either: it points to the domain’s authoritative server, which does hold the actual record. Only then does the recursive resolver get the IP, hand it to the browser, and cache a copy for as long as the record’s TTL (Time To Live) specifies.

Why Root Servers Don’t Collapse: Anycast

Thirteen letters don’t mean thirteen physical machines. Each root server uses anycast: the same IP address is announced from dozens of different locations around the world, and network traffic automatically routes to the nearest instance. That way, even if millions of resolvers query at once, no single location bears the full load.

sequenceDiagram
participant N as "Browser"
participant R as "Recursive resolver"
participant Raiz as "Root server"
participant TLD as "TLD server"
participant A as "Authoritative server"
N->>R: "resolve programacion.example"
R->>Raiz: "responsible for .example"
Raiz-->>R: "redirects to TLD server"
R->>TLD: "responsible for programacion.example"
TLD-->>R: "redirects to authoritative"
R->>A: "IP address of programacion.example"
A-->>R: "192.0.2.10"
R-->>N: "192.0.2.10, cached"

Types of DNS Records

A domain doesn’t store a single piece of data: it stores an entire zone with different types of records, each with a specific purpose.

Record	What It Resolves	When to Use It
A	Domain to IPv4 address	Pointing a domain to a server with IPv4
AAAA	Domain to IPv6 address	Same as A but for IPv6 networks, defined in RFC 3596
CNAME	Alias to another domain	Subdomains pointing to an external service (CDN, hosting)
MX	Mail server	Defining where the domain’s email gets delivered
TXT	Free-form text	Domain ownership verification, SPF, DKIM
NS	Authoritative servers for the zone	Delegating the zone to a specific DNS provider

Practical Examples: Inspecting a Real DNS Resolution

The most direct way to see DNS resolution in action is with dig, available on Linux and macOS (on Windows, the equivalent is nslookup).

dig programacion.example A +short

That query returns only the IPv4 address associated with the domain, without the rest of the metadata. It’s the equivalent of asking the resolver directly: just give me the IP and nothing else.

To see the full path, with every intermediate server, use the +trace flag:

dig +trace programacion.example

; <<>> DiG <<>> +trace programacion.example
;; global options: +cmd
.                       518400  IN      NS      a.root-servers.net.
example.                172800  IN      NS      a.iana-servers.net.
programacion.example.   3600    IN      A       192.0.2.10

Each line represents a response from a different level of the hierarchy: first the root, then the TLD, and finally the domain’s authoritative server.

If you’d rather resolve DNS from code, Node.js exposes the native dns module:

const dns = require('node:dns').promises;

async function resolverDominio(dominio) {
  const direcciones = await dns.resolve4(dominio);
  console.log(`${dominio} resolves to:`, direcciones);
}

resolverDominio('programacion.example');

This code uses the operating system’s resolver to get the domain’s IPv4 addresses and prints them to the console. If the domain doesn’t exist, the promise rejects with an ENOTFOUND error.

Getting Started: Configuring Your Own DNS Records

If you manage a domain, configuring its records doesn’t require spinning up your own server: it’s done through the DNS provider’s dashboard (Cloudflare, Route 53, the domain registrar) or by editing a zone file if you run your own authoritative server with software like BIND.

A minimal zone file in BIND format looks like this:

$TTL 3600
@   IN  SOA ns1.programacion.example. admin.programacion.example. (
        2026082001 ; serial
        3600       ; refresh
        900        ; retry
        604800     ; expire
        3600 )     ; minimum TTL

@       IN  NS      ns1.programacion.example.
@       IN  A       192.0.2.10
www     IN  CNAME   programacion.example.
@       IN  MX  10  mail.programacion.example.

That file defines the authoritative server (NS), the main IP (A), an alias for www (CNAME), and the mail server (MX). The SOA (Start of Authority) sets the refresh timing between secondary servers.

The general steps, regardless of provider, are the same: create the record with the correct type, point it to the target value (IP or destination domain), set the TTL, and wait for it to propagate.

💡 Tip: before migrating a domain to a new provider, lower the TTL of the existing records to 300 seconds one day in advance. That way, if something goes wrong, the rollback propagates in minutes instead of hours.

Real-World Use Cases

Beyond translating a name into an IP, DNS is used as an infrastructure building block in several scenarios you’ve probably already used without noticing.

• Load balancing with DNS round robin: the same domain can have several different A records; the resolver returns the IPs in a different order on each query, spreading traffic across servers without a dedicated load balancer.
• GeoDNS for CDNs: services like Cloudflare or Akamai respond with a different IP depending on the geographic location of the requester, so the user connects to the nearest server.
• Automatic failover: some DNS providers monitor the health of the server behind each record and, if they detect an outage, stop returning that IP until it responds again.
• Subdomain takeover: a CNAME pointing to an external service that’s been decommissioned is left dangling; an attacker can claim that same name on the external service and take control of the subdomain.

Cache and TTL: Why a Change Takes Time to Propagate

Every DNS record carries a TTL in seconds that tells any resolver how long it can reuse that answer without asking again. A TTL of 3600 means that, for one hour, any resolver that already queried that record will keep serving the cached answer, even if the record has since changed on the authoritative server.

This explains why changing DNS is never instant: there’s no single cache to clear, but thousands of recursive resolvers around the world, each with its own expiration clock.

flowchart TD
A["Resolver receives the query"] --> B{"Has the record in a valid cache"}
B -->|"Yes, TTL valid"| C["Responds from cache"]
B -->|"No or TTL expired"| D["Queries the authoritative server"]
D --> E["Stores the response and the new TTL"]
E --> C

DNSSEC: Going Deeper

The original design of DNS doesn’t verify that a response actually comes from the authoritative server: an attacker on the same network can inject a fake response before the real one arrives, an attack known as DNS cache poisoning.

DNSSEC (DNS Security Extensions) solves this by cryptographically signing each response with an RRSIG record, verifiable against the public key published in the parent zone’s DNSKEY record. The chain of signatures goes all the way up to the root zone, which acts as the trust anchor.

You can check whether a domain has DNSSEC enabled with:

dig programacion.example DNSKEY +short

If the command returns one or more keys, the zone signs its records. If it comes back empty, the domain doesn’t implement DNSSEC and its resolution is vulnerable to in-transit manipulation, even though it keeps working the same way for the end user.

⚠️ Watch out: DNSSEC protects the integrity of the response, not the confidentiality of the query. Someone observing the traffic can still see which domains you’re resolving, unless you also use DNS over HTTPS or DNS over TLS.

Comparison: Public Resolvers

Resolver	IP	Advantage	Limitation
Cloudflare	1.1.1.1	Stated privacy-first approach, deletes logs within 24 hours	Doesn’t filter content by default
Google Public DNS	8.8.8.8	High global availability	Logs more extensive telemetry
ISP resolver	Variable	Lower latency if it’s close to your network	Some inject ads on NXDOMAIN errors

Common Mistakes and Best Practices

• NXDOMAIN: the queried domain doesn’t exist in any record. Before assuming DNS is misconfigured, check that the domain is spelled correctly and that the zone exists.
• TTL too high in production: a TTL of 86400 (one day) on a record that changes often turns any migration into a long wait. Lower it before a planned change.
• Forgetting the AAAA record: if your server has IPv6 but you only publish the A record, you’re leaving out networks that prioritize IPv6, which are increasingly common.
• CNAME at the domain root: the standard doesn’t allow a CNAME to coexist with other records at the apex (programacion.example with no subdomain); for that, alternatives like the ALIAS or ANAME record from some providers exist.

📖 Summary on Telegram: View summary

Your next step: run dig +trace yourdomain.com in a terminal and manually follow each hop until you find the real authoritative server for your own domain.

Frequently Asked Questions

What’s the difference between a recursive resolver and an authoritative server?

The recursive resolver asks the questions on behalf of the client and doesn’t hold the original records, just a cached copy. The authoritative server is the real source: that’s where the record managed by the domain owner actually lives.

Why does a DNS change sometimes take hours to show up?

Because different resolvers around the world cached the previous record with different TTLs. Until each cached copy expires, those resolvers will keep returning the old value.

Is DNS the same thing as DHCP?

No. DHCP assigns an IP address to a device within a local network. DNS translates domain names into IP addresses on the internet. They’re different protocols that often coexist on the same infrastructure.

Does DNSSEC replace HTTPS?

No. DNSSEC verifies that the DNS response wasn’t altered in transit. HTTPS encrypts and verifies the connection with the server once you already have the IP. They’re complementary security layers, not substitutes for one another.

What is DNS over HTTPS (DoH)?

A mechanism that sends DNS queries encrypted inside a regular HTTPS connection, so a network observer can’t see in plain text which domains you’re resolving.

References

• RFC 1035: the original DNS protocol specification, published by the IETF.
• IANA, Root Servers: official list of the 13 root server letters and their operators.
• MDN Web Docs, DNS Glossary: reference explanation aimed at web developers.
• Cloudflare Learning Center, What Is DNS: introductory guide with diagrams of a query’s journey.

📱 Like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.

Imagen destacada: Foto de Tyler en Unsplash