DNS, how play.myserver.com becomes an IP address

Field note. When you tell your friends 'connect to play.myworld.com,' DNS is what turns that string into the IP that has your server on it. Most 'I can't connect' tickets start here.

Computers find each other by IP address. Humans don't remember numbers. The system that bridges this gap is DNS, the Domain Name System. Every time you type a name into a browser or game launcher, DNS quietly looks up the IP behind it.

DNS is one of the most important pieces of internet plumbing. It's also one of the most invisible and most misunderstood. This article unpacks it.

The phonebook analogy (and its limits)

Most introductions say "DNS is like a phonebook for the internet." That's true at a high level. You look up a name; you get an address.

Where the analogy breaks: a phonebook is a single document maintained by one entity. DNS is distributed across millions of servers worldwide, with no single authority holding all of it. Names are organized in a tree, with different parts of the tree maintained by different organizations.

A better analogy: DNS is more like the global system of postal address books, where each country maintains its own, each region within each country has its own, and you find an address by asking each level in turn.

The hierarchy

DNS names are read right to left. The rightmost label is the most general; the leftmost is the most specific.

play.myserver.com
^    ^         ^
|    |         +-- TLD (Top-Level Domain): .com
|    +-- second-level: myserver
+-- subdomain: play

Each level is delegated to whoever manages it.

The full hierarchy:

1. The root, denoted by . at the very end (usually invisible). The root is managed by ICANN/IANA via 13 root server clusters worldwide.

2. Top-Level Domains (.com, .org, .net, country codes like .uk, .jp, newer ones like .app, .dev). Each TLD has a registry (Verisign runs .com, etc.) that maintains the list of registered second-level domains.

3. Second-level domains (myserver.com). When you "register a domain," you buy a delegation from the TLD registry that says "I control everything under myserver.com."

4. Subdomains and records (play.myserver.com, www.myserver.com, etc.). The owner of myserver.com decides what subdomains exist and where they point.

The cleverness: each level only knows about the next level. The root doesn't know about your domain. .com doesn't know about your play.myserver.com. The delegation chain handles it.

A lookup, in slow motion

Suppose you type play.myserver.com in a game client. To find its IP, your computer needs to:

1. Ask a recursive resolver. Most computers don't do DNS lookups themselves; they ask a resolver (often your ISP's, or a public one like 1.1.1.1 or 8.8.8.8). "What's the IP of play.myserver.com?"

2. The resolver asks the root. "Where do I find anything about .com?"

3. The root says: "Ask one of these .com nameservers."

4. The resolver asks .com: "Where do I find anything about myserver.com?"

5. .com says: "Ask these nameservers (the ones the owner of myserver.com designated)."

6. The resolver asks myserver.com's nameservers: "What's play.myserver.com?"

7. They answer: "It's at IP 203.0.113.42."

8. The resolver returns this answer to your computer.

Eight steps for one lookup. Inefficient? Not really, because of caching.

Caching is everything

Each step caches answers. The resolver caches the .com nameservers. Your OS caches the resolver's response. Your browser caches it again. Once a name has been looked up, subsequent lookups for hours are nearly instant.

DNS records have a TTL (Time To Live) that determines how long they can be cached. Common values:

• 300 seconds (5 minutes): low, used when you might change the record soon.
• 3600 seconds (1 hour): typical.
• 86400 seconds (1 day): high, used for stable records.

When you change a DNS record, old cached values can persist until their TTL expires. This is why DNS changes "take time to propagate." It isn't propagation per se; it's caches gradually expiring.

Record types

DNS doesn't just return IPs. There are many record types, each providing different information:

Type	Returns	Used for
A	IPv4 address	Most websites and services
AAAA	IPv6 address	IPv6-reachable services
CNAME	Another name	"This name is an alias for that other name"
MX	Mail server name + priority	Email delivery
TXT	Arbitrary text	Email auth (SPF, DKIM), domain verification
NS	Nameserver name	Delegation (who handles this zone)
SRV	Service host + port	Many protocols, including Minecraft
PTR	Name from IP	Reverse DNS (less common)
CAA	Certificate authority authorization	"Only this CA can issue certs for me"
ALIAS / ANAME	Like CNAME but at apex	Some providers, not standardized

For a typical website, you have A and AAAA records for the IPs, MX records for email, and TXT records for various verifications.

For a game server, you might have:

• An A record for the IP.
• An SRV record so players can use a friendly name without specifying a port.

We covered SRV records in detail in article #48 of the main series. The short version: SRV lets a hostname resolve to "this host, this port" rather than just "this host."

A and AAAA, in detail

The two most common record types.

A records point a name to an IPv4 address:

play.myserver.com.   A    203.0.113.42

This means "to reach play.myserver.com, use IP 203.0.113.42."

AAAA records point a name to an IPv6 address:

play.myserver.com.   AAAA 2001:db8::1

A name can have both. Modern clients try IPv6 first, falling back to IPv4 if IPv6 fails.

A name can also have multiple A records:

play.myserver.com.   A    203.0.113.42
play.myserver.com.   A    203.0.113.43

Used for crude load balancing. The DNS server returns both; the client picks one (often the first, but DNS servers can shuffle the order on each query).

CNAME records, the alias

CNAME is "this name is just another name for that name."

www.myserver.com.   CNAME    myserver.com.

When a client looks up www.myserver.com, the DNS server returns the CNAME, pointing them at myserver.com. The client then looks up myserver.com's records.

Useful for:

• Pointing www.example.com at example.com (or vice versa).
• Pointing a custom subdomain at a third-party service ("app.mycompany.com is a CNAME to mycompany.herokuapp.com").

Important rule: a CNAME cannot coexist with other records on the same name. You can't have both a CNAME and an MX on www.example.com. This is a quirk of the DNS spec that catches people.

There's also no CNAME at the apex of a domain (i.e., example.com itself can't be a CNAME). Some providers offer ALIAS or ANAME records to work around this, but they're not standardized.

NS records and delegation

The mechanism that lets myserver.com's owner control its own records.

When you register myserver.com, you tell the registrar which nameservers will be authoritative for it. The .com zone gets an NS record:

myserver.com.   NS   ns1.cloudflare.com.
myserver.com.   NS   ns2.cloudflare.com.

This says "for anything under myserver.com, ask these nameservers."

You then configure those nameservers with the actual records for your domain (A, MX, etc.).

The chain: root delegates .com to .com registry's nameservers; .com delegates myserver.com to your nameservers; your nameservers actually answer queries about play.myserver.com.

Your resolver

Every device on the internet uses a DNS resolver. By default, it's whatever your ISP provides. You can change it.

Common public resolvers:

• 1.1.1.1 (Cloudflare)
• 8.8.8.8 (Google)
• 9.9.9.9 (Quad9, focused on blocking malicious domains)

Reasons to change:

• Speed (some ISPs' resolvers are slow).
• Privacy (some ISPs log and sell DNS queries).
• Bypassing censorship (your ISP might block certain domains at the resolver level).
• Reliability (public resolvers are typically more reliable than ISP ones).

On most operating systems, changing your DNS resolver is a few clicks in network settings.

DNS isn't really encrypted

Classic DNS is sent over UDP port 53, in plaintext. Anyone watching the wire can see what names you're looking up. This is a privacy leak.

Modern alternatives:

• DoT (DNS over TLS): DNS queries encrypted in a TLS tunnel. Port 853.
• DoH (DNS over HTTPS): DNS queries sent as HTTPS requests. Port 443, indistinguishable from web traffic.

Most modern browsers can use DoH by default. Public resolvers like 1.1.1.1 support both.

For ordinary users, this matters because your ISP can't watch your DNS lookups when you use encrypted DNS. For governments and ISPs that traditionally relied on DNS blocking for content control, encrypted DNS is a workaround.

When DNS goes wrong

DNS is one of the most common "the internet is broken" causes. Specific failures:

The name doesn't resolve. Either:

• The name doesn't exist (typo).
• Your resolver can't reach the authoritative servers.
• The domain has been delisted (e.g., expired registration).

The name resolves to the wrong IP. Either:

• A change is in progress and you have a stale cache.
• A misconfiguration on the authoritative side.
• DNS poisoning (rare but happens).

Resolution is slow. Often:

• Your resolver is overloaded.
• The path to your resolver is laggy.
• The authoritative servers are slow.

Diagnostic tools:

dig play.myserver.com

(Linux/Mac) returns full DNS lookup details.

nslookup play.myserver.com

(Windows or Unix) also works.

These show you exactly what was returned, from where, with what timing. Essential for diagnosing DNS issues.

Why DNS matters

For end users, DNS is invisible 99% of the time. When it isn't:

• Websites and games fail to load.
• Email fails to deliver.
• Random services don't work.

For server operators, DNS controls:

• Where players connect (A/AAAA records).
• Whether your friendly hostname works (SRV records).
• Whether email delivery succeeds (MX, SPF, DKIM, DMARC TXT records).
• Whether HTTPS works (CAA records hint at this).

Mismanaged DNS can take a service offline more thoroughly than almost any other failure. Conversely, well-managed DNS is invisible. Aim for invisible.

Coming up

We've covered the high-level lookup. Next we'll dig deeper into how the DNS hierarchy actually works: root servers, TLDs, registrars, and the chain of trust that makes a domain "yours."