What is DNS? How the Domain Name System works, record by record

Short answer: DNS, the Domain Name System, is the internet’s directory. It turns names people can remember, like example.com, into the IP addresses computers connect to, like 203.0.113.10 or an IPv6 address — and it also tells mail servers where to deliver mail, certificate authorities who may issue certificates, and much more. It is not one server but a worldwide, hierarchical, heavily cached database, run by thousands of organisations, that is asked before almost every connection on the internet.

What happens when you look up a name?

Take a browser opening www.example.com with nothing cached yet:

• The operating system’s stub resolver asks the recursive resolver it is configured to use — your router, your ISP’s resolver, or a public one such as 1.1.1.1, 8.8.8.8 or 9.9.9.9.
• The recursive resolver asks a root server where .com is handled. There are 13 root server identities, a to m.root-servers.net, run by 12 organisations and answered by more than 2,000 server instances worldwide through anycast.
• The root refers it to the .com TLD servers, which refer it to the domain’s authoritative nameservers.
• The authoritative nameserver returns the answer — say an A record with an IPv4 address — together with a TTL saying how long it may be cached.
• The resolver caches the answer and hands it back; the browser connects to the address.

All of that typically takes tens of milliseconds, and only the first time: the next visitor using the same resolver gets the cached answer at once. You can watch the whole chain from a Linux server with dig +trace, which skips your resolver and walks from the root down itself:

dig +trace www.example.com A

Which kinds of DNS server are there?

The split explains two very different problems people both call “DNS”: a computer that cannot resolve anything has a resolver problem, and a domain that nobody can resolve has an authoritative problem. Which nameservers are authoritative for a domain is set at its registrar — nameservers are that layer of the system.

What are DNS records?

A few rules that trip people up:

• A CNAME cannot share its name with other records, so the bare domain (where NS and SOA live) cannot be a CNAME. Providers that allow it call the workaround ALIAS, ANAME or CNAME flattening.
• An MX record must name a host — a fully qualified domain name such as mail.example.com — with A or AAAA records, not an IP address and not a CNAME.
• PTR records for a server’s IP are set by whoever owns the IP range — your hosting provider — not in your domain’s zone. Mail servers check them, so set reverse DNS before sending mail.

Pointing a domain at a server comes down to an A record, an AAAA record if the server has IPv6, and usually a CNAME or second A record for www — the walkthrough is pointing a domain to your VPS. Why the AAAA side matters as much as the A side is explained in IPv4 vs IPv6.

What is TTL, and why do DNS changes take time?

Every answer carries a time to live in seconds. Resolvers may reuse it until it expires, so after you change a record, users of a resolver that cached the old value keep getting it for up to the old TTL. That is all “DNS propagation” is: caches expiring, not changes travelling. Negative answers — “this name does not exist” — are cached too, for a time taken from the zone’s SOA record.

Which ports and protocols does DNS use?

• UDP port 53 for ordinary queries — one packet each way, no handshake.
• TCP port 53 for answers too large for UDP, for zone transfers between nameservers and as a fallback. Firewalls that allow only UDP 53 break lookups of big records, such as long TXT or DNSSEC-signed answers.
• DNS over TLS (DoT, RFC 7858) on TCP port 853 and DNS over HTTPS (DoH, RFC 8484) on port 443 encrypt the hop to the resolver, so the local network cannot read or change your queries.
• DNSSEC signs records so a resolver can prove an answer came from the zone owner unaltered. It provides authenticity, not privacy — the queries stay readable unless DoT or DoH carries them.

How do you query DNS from the command line?

dig example.com A +short          # the IPv4 address
dig example.com AAAA +short       # the IPv6 address
dig example.com MX                # mail servers, with TTLs
dig @1.1.1.1 example.com          # ask a specific resolver
dig @ns1.example-dns.net example.com   # ask the authoritative server directly
dig -x 203.0.113.10 +short        # reverse lookup (PTR)

resolvectl status                 # systemd-resolved: upstream servers per interface
cat /etc/resolv.conf              # 127.0.0.53 means the systemd-resolved stub
getent hosts example.com          # resolves like applications do, /etc/hosts included

Resolve-DnsName example.com -Type A
nslookup example.com 1.1.1.1
ipconfig /flushdns

nslookup exists on Linux and macOS too; its record types, the server argument and how to read its output are in the nslookup command guide.

Asking the authoritative server directly and then a public resolver is the quickest way to tell a wrong record from a stale cache: if the authoritative answer is right and the resolver’s is old, you are waiting for a TTL.

In a browser, the DNS lookup tool shows a name’s records with their TTLs, and the DNS propagation checker asks twelve public resolvers the same question at once, which shows which caches still hold the old answer.

What are the common DNS problems?

• Nothing resolves on a machine — the resolver is unreachable or misconfigured. On Windows that is “DNS server not responding”; on a Linux server it is “Temporary failure in name resolution”.
• One domain fails everywhere — wrong or unreachable authoritative nameservers, an expired domain, or broken DNSSEC. Chrome shows a name that does not resolve while others do as DNS_PROBE_FINISHED_NXDOMAIN.
• Some users see the old server — cached records; wait out the TTL and lower it next time.
• Mail is rejected or lands in spam — missing SPF, DKIM or DMARC TXT records, or no matching PTR for the sending IP.
• A site behind a proxy CDN times out — the DNS record points at the CDN, which cannot reach your origin; that is a connection problem, not a DNS one.

Running DNS on your own server

Two separate things can run on a VPS. A caching resolver such as Unbound, bound to localhost, gives the server fast, validated lookups that do not depend on anyone else’s resolver — useful on mail servers, which make many blocklist queries. An authoritative nameserver such as BIND, Knot or PowerDNS serves your own zones to the world; run at least two, on different networks, and never let it answer recursive queries for strangers, or it becomes a tool for amplification attacks. Running your own nameservers, glue records included, is covered in what are nameservers.

Either fits on the smallest Standard KVM plan in Amsterdam: every server has root access and its own IPv4 address. For a second nameserver in another city, DMCA Ignored KVM and Pentesting KVM are also sold in Frankfurt.

Frequently asked