DNS, enough of it

DNS turns names into addresses. Most of the time you do not think about it, and when you do it is because something is behaving inconsistently.

The records you will meet #

A maps a name to an IPv4 address. AAAA does the same for IPv6.

CNAME makes a name an alias for another name. Cannot coexist with other records on the same name, which is why you cannot usually put one on a bare domain.

TXT holds arbitrary text. Used for proving you control a domain, and for mail records.

MX says which servers accept mail for the domain.

NS says which nameservers are authoritative. Changing these at your registrar is how you hand DNS to a provider.

CAA says which certificate authorities may issue for the name. Cheap to set and closes a real attack.

TTL, and why changes take time #

Every record carries a time to live: how long a resolver may cache the answer. Set 3600 and a resolver that asked five minutes ago will keep serving the old answer for another 55.

The practical rule: lower the TTL before you plan a change, not after. Drop it to 300, wait for the old TTL to expire, make the change, then put it back up.

The other practical rule: when something "has not propagated", it has almost always been served correctly for a while and something in the middle is still holding a cached answer.

Who is actually answering #

The most useful debugging skill here is knowing which resolver gave you the answer, because your laptop, your phone and your server may all be asking different ones.

$ dig +short photos.example.com
$ dig +short @1.1.1.1 photos.example.com
$ resolvectl query photos.example.com

The first asks whatever your machine is configured to use. The second asks a public resolver directly, bypassing local caches and any local override. If those disagree, the difference is local: a hosts file, a VPN's resolver, a router doing its own thing.

resolvectl query on systemd machines tells you which interface's resolver answered, which is exactly what you want when a VPN is involved.

Do not forget /etc/hosts. It bypasses DNS entirely, it is invisible to dig, and a line you added months ago will outlive your memory of it.

Split horizon #

One name, different answers depending on who asks. Common and legitimate.

You might want photos.example.com to resolve to a private address for devices on your own network, and a public one for everyone else. Traffic at home stays local and fast; traffic from outside goes the public route.

Three ways it happens:

• A private resolver for your network that overrides certain names.
• A VPN's resolver answering for its own domain while other names go to the normal resolver.
• A hosts file entry on one machine.

The costs are worth knowing. Debugging gets harder, because "does it work" now depends on where you are standing. Certificates must match the name, which they will, since the name is the same. And a device that moves between networks may hold a cached answer from the wrong side, which is where TTL bites.

Certificate validation and DNS #

Public certificate authorities usually verify control by asking you to publish a record. That is how a name that resolves only on a private network can still get a publicly trusted certificate: the challenge proves you control the name, not that the service is reachable.

Chapter 10 uses exactly this. It also means every certificate issued for your names is recorded in public Certificate Transparency logs, so the names become public even when the services are not.

When it is not DNS #

It usually is DNS. When it is not, these are the ways it looks like DNS and is not:

• The name resolves and the connection fails. DNS did its job. Look at firewalls, routing and whether anything is listening.
• It works by address and not by name. That really is name resolution.
• It works on one device only. A hosts file, a different resolver, or a cached answer.
• It worked and then stopped at a predictable interval. A TTL expired and the real answer is different from the cached one.