DNS

In short: Domain Name System — translates human-readable domains (e.g. emzett-digital.com) into numeric IP addresses, which computers need for a connection.

In more detail: Works hierarchically: a DNS resolver first asks the root name servers, then the servers responsible for the TLD, then the name servers responsible for the specific domain — until the matching IP is found. Thanks to the TTL, results are cached (caching), so that not every request goes through the full chain.

In Depth

The resolution process step by step

A typical DNS resolution runs in several steps, usually invisible to the user:

1. Browser asks the local resolver (e.g. the ISP's or 1.1.1.1): "Where is emzett-digital.com?"
2. Resolver asks a root name server: "Who is responsible for .com?"
3. Root server answers with the TLD name server address for .com
4. Resolver asks the .com name server: "Who is responsible for emzett-digital.com?"
5. TLD server answers with the domain's authoritative name server
6. Resolver asks the authoritative name server for the actual A record
7. The answer (the IP address) goes back to the browser and is cached

This process is called “recursive resolution”, because the resolver runs through the whole chain on behalf of the client, instead of leaving each intermediate step to the client (which is called “iterative resolution” — internally the resolver itself uses iterative requests to the individual servers, but only gives the client the finished end result). The 13 root name server “addresses” (named A to M) are in reality themselves anycast addresses behind which hundreds of physical servers worldwide are hidden, so that this most critical part of the entire internet infrastructure doesn’t depend on 13 actual individual machines.

Record types and caching

Different DNS record types answer different questions: A/AAAA return IP addresses, MX the responsible mail server, CNAME an alias to another name, TXT any free text (often used for domain verification or anti-spam mechanisms such as SPF/DKIM). The TTL of each record determines how long a resolver may cache the result before asking again — short TTLs (e.g. 60 seconds) allow quick changes, for example when moving servers or during a failover, but generate more request load on the authoritative name servers; long TTLs (several hours to days) are the opposite. Caching happens at several levels at the same time — in the end device’s operating system, at the ISP’s resolver, and sometimes even in the browser itself — which explains why a DNS change sometimes takes hours to really arrive everywhere, even though the TTL has long expired.

Security: unencrypted by default

DNS historically runs unencrypted over UDP port 53 (for larger answers also over TCP), which enables both manipulation (DNS spoofing, where an attacker injects forged answers and redirects users to a phishing page instead of the real domain, for example) and simple eavesdropping — an internet provider or anyone along the transmission path can basically see which domains are requested, even if the actual connection afterwards runs encrypted via HTTPS. Modern alternatives such as DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt the request itself and are increasingly supported by default by browsers and operating systems. In addition, DNSSEC (DNS Security Extensions) provides cryptographically signed answers that can be checked against subsequent manipulation — DNSSEC doesn’t encrypt the request itself, but guarantees that an answer received really comes from the authoritative server and wasn’t altered in transit.

Practical diagnostic tools

For troubleshooting, commands such as dig, nslookup and host are standard tools for diagnosing DNS resolution problems directly — for example to check whether a record has propagated correctly, which TTL is currently active, or whether a particular authoritative name server answers at all.

See also: DNS records, Domain, TTL, Anycast