DNS & Domain Names Intermediate

Every device on the Internet is reached by an IP address — a number such as 93.184.216.34 (IPv4) or 2606:2800:220:1:248:1893:25c8:1946 (IPv6). Numbers are how routers actually deliver packets, but they are hard for people to remember, and a service may change its IP over time.

The Domain Name System (DNS) is a global, distributed directory that maps human-friendly names like www.example.com to those addresses. Names are stable, memorable, and let the underlying IP change without anyone having to relearn the address. DNS is often called “the phone book of the Internet”.

A domain name is read right to left, from the most general part to the most specific. Consider www.shop.example.com. Reading from the right:

• the trailing dot represents the unnamed root of the whole tree;
• com is the top-level domain (TLD);
• example is the registered second-level domain;
• shop is a subdomain;
• www is the host (or leftmost label).

When every label up to the root is present, the name is a Fully Qualified Domain Name (FQDN). The FQDN is unambiguous — it does not depend on any local search domain. Each label is up to 63 characters; the whole name is at most 255 octets.

The rightmost label is the top-level domain. The two main families are:

• Generic TLDs (gTLDs) — not tied to a country. Classic ones include .com, .org, .net, .edu and .gov; many newer ones exist such as .app, .dev and .shop.
• Country-code TLDs (ccTLDs) — two letters tied to a country or territory, such as .fi (Finland), .uk, .de and .jp.

There is also a special infrastructure TLD .arpa used for reverse lookups. The overall coordination of TLDs and the root zone is handled by ICANN and the IANA function.

Three roles keep domain ownership organised:

• A registry operates a TLD and maintains the authoritative database of every domain under it (for example, Verisign runs .com).
• A registrar is an ICANN-accredited company that sells domains to the public and submits registrations to the registry on your behalf.
• A registrant is you — the person or organisation that registers a domain.

Registrations are leased, typically yearly, and must be renewed. WHOIS (and the newer RDAP protocol) lets anyone query who registered a domain, when it was created, and which name servers it uses — though personal contact details are now usually redacted for privacy.

DNS is not one giant database but a delegated tree. Authority is handed down level by level:

• Root name servers sit at the top. They do not know individual websites; they know which servers handle each TLD. There are 13 logical root server identities (a through m.root-servers.net), each backed by many anycast instances worldwide.
• TLD name servers (for .com, .fi, etc.) know which authoritative servers handle each domain registered under that TLD.
• Authoritative name servers hold the actual records (the IP addresses, mail servers and so on) for a specific domain — this is where the real answers live.

Each level only knows enough to point you one step lower. This delegation is what makes DNS scale to billions of names.

Two very different kinds of server do the work:

• An authoritative name server publishes the official records for the zones it is responsible for. When asked about a name it is authoritative for, it answers from its own data and marks the answer as authoritative.
• A recursive resolver (also called a recursive or caching name server) does the legwork on behalf of a client. Your computer normally talks only to a recursive resolver — run by your ISP, your company, or a public provider like 8.8.8.8 or 1.1.1.1. The resolver chases the hierarchy down, caches what it learns, and hands the final answer back to you.

In short: the resolver asks the questions; authoritative servers provide the official answers.

The two query styles are easy to mix up with the two server types.

• In a recursive query, the client says “give me the final answer, do whatever it takes.” Your device sends this to its recursive resolver and expects a complete answer back.
• In an iterative query, the server answers “I don’t have the answer, but here is a referral — go ask this other server.” The recursive resolver uses iterative queries when it talks to the root, TLD and authoritative servers, following each referral one hop at a time.

So a single user request triggers one recursive query (client → resolver) and a chain of iterative queries (resolver → the hierarchy).

Putting it together, here is the full path when your browser needs www.example.com and nothing is cached:

1. Your device asks its recursive resolver for www.example.com (a recursive query).
2. The resolver asks a root server. The root replies: “I don’t know, but the .com servers are over there.”
3. The resolver asks a .com TLD server. It replies: “ask the authoritative servers for example.com — here they are.”
4. The resolver asks the authoritative server for example.com. It replies with the A record: www.example.com → 93.184.216.34.
5. The resolver caches the answer and returns it to your device. Your browser connects to 93.184.216.34.

Steps 2–4 are iterative referrals; step 1 is the single recursive request.

If every lookup walked the whole tree, DNS would be slow and the root servers would be overwhelmed. Caching fixes this. When a resolver learns an answer, it stores it temporarily so the next identical question is answered instantly from memory.

How long an answer may be cached is controlled by its TTL (Time To Live), a value in seconds set by the domain owner on each record. A TTL of 3600 means “you may reuse this for one hour.” When the TTL expires, the cached entry is discarded and the next query fetches a fresh copy.

Trade-off: a long TTL gives faster responses and less load but slower updates; a short TTL lets changes take effect quickly but means more queries. Operators often lower the TTL before a planned change.

DNS data is stored as resource records, each with a name, type, TTL and value. The two most fundamental address records are:

• A — maps a name to an IPv4 address (32-bit), e.g. example.com. A 93.184.216.34.
• AAAA (“quad-A”) — maps a name to an IPv6 address (128-bit), e.g. example.com. AAAA 2606:2800:220:1:248:1893:25c8:1946.

A name can have both, letting clients pick IPv4 or IPv6. The name AAAA comes from IPv6 addresses being four times the size of IPv4 addresses.

Three structural record types:

• CNAME (canonical name) is an alias: it points one name at another name, not at an IP. For example www.example.com. CNAME example.com. means “look up example.com instead.” A name with a CNAME cannot also carry other record types, and CNAMEs are not allowed at the zone apex.
• NS (name server) records list the authoritative name servers for a zone. They are how a parent zone delegates a subdomain to its own servers.
• SOA (start of authority) appears once per zone and holds administrative data: the primary name server, the admin email, a serial number that increases on every change, and timing values (refresh, retry, expire, minimum TTL) used by secondary servers.

Two more widely used record types power email:

• MX (mail exchanger) tells other mail servers where to deliver email for a domain. Each MX has a priority (preference) value; lower numbers are tried first, and equal values share load.
• TXT holds arbitrary text. It is heavily used for email authentication:
  • SPF records (a TXT starting v=spf1) list which servers are allowed to send mail for the domain.
  • DKIM records (a TXT at a _domainkey name) publish a public key used to verify message signatures.
  TXT records are also used to prove domain ownership for many services.

An SRV (service) record advertises the host and port for a specific service, so clients can discover where a service runs without it being hard-coded. The owner name encodes the service and protocol as _service._protocol.domain, for example _sip._tcp.example.com or _xmpp-client._tcp.example.com.

Each SRV record carries four values: priority (lower tried first), weight (relative share among equal priorities), port, and the target hostname. SRV is used by protocols such as SIP, XMPP, LDAP and Microsoft Active Directory.

Normal (“forward”) DNS turns a name into an IP. Reverse DNS does the opposite: it turns an IP back into a name using a PTR (pointer) record.

To make this fit the same hierarchical tree, the IP is rewritten as a special name. IPv4 addresses are reversed and placed under in-addr.arpa: 93.184.216.34 becomes 34.216.184.93.in-addr.arpa. IPv6 uses nibble-reversed addresses under ip6.arpa. The octets are reversed so the most general part (the network) is on the right, matching how DNS delegates from the top down.

Reverse DNS matters most for mail servers: many receivers reject or distrust mail from an IP whose PTR record does not match its forward name.

Two command-line tools let you query DNS directly.

• dig (Domain Information Groper) is the detailed, scriptable favourite. dig example.com A asks for the A record; add +short for just the answer, @1.1.1.1 to pick a resolver, -x for reverse lookups, and a type like MX or NS to choose records.
• nslookup is older and simpler, available on most systems including Windows. nslookup -type=MX example.com queries MX records.

Reading dig output, the ANSWER SECTION holds the records returned, and the flags line tells you whether the answer was authoritative (aa).

When you change a DNS record, the change is instant only on your authoritative server. Everywhere else, resolvers around the world may still be serving the old cached value until its TTL expires. The gradual fade-out of old data and spread of new data is loosely called DNS propagation.

This is why a change can appear live for you but not for a colleague: their resolver still has the old record cached. Propagation time is governed mainly by the record’s TTL (plus how long registrars take to publish NS changes). To make a planned migration smooth, lower the TTL well in advance, make the change, then raise the TTL again once the new value is everywhere.

Traditional DNS queries travel in plain text over UDP/TCP port 53. Anyone on the network path — your ISP, a public Wi-Fi operator, an attacker — can see which sites you look up and could tamper with replies. Two protocols add encryption:

• DoT (DNS over TLS) wraps DNS in a TLS connection on port 853. It is easy for network operators to recognise as DNS.
• DoH (DNS over HTTPS) sends DNS queries inside ordinary HTTPS on port 443, so they blend in with normal web traffic and are hard to single out or block.

Both protect confidentiality and integrity between you and your resolver. They do not hide your traffic from the resolver itself, so the choice of trustworthy resolver still matters.

Plain DNS has no built-in way to prove an answer is genuine, so attackers can attempt cache poisoning — feeding a resolver forged records that send users to the wrong server. DNSSEC (DNS Security Extensions) solves this by adding cryptographic signatures to DNS data.

Each signed zone has key records (DNSKEY) and signature records (RRSIG) over its data. A resolver can verify the signature, and trust is established through a chain: the parent zone signs a hash (DS record) of the child’s key, all the way up to the root, whose key is widely trusted. If a record fails validation, the resolver rejects it.

Important: DNSSEC provides authenticity and integrity — it proves the answer was not forged or altered — but it does not encrypt or hide the query (that is what DoH/DoT do).