Hostname, Domain Name, FQDN, and DNS Resolution

The naming hierarchy

www.api.mybusiness.com.
│   │   └─────────┘  └─ root (the trailing dot, usually omitted)
│   │   domain name (registered, second-level domain)
│   └─── subdomain (third-level domain, can be arbitrary)
└─────── hostname (identifies the specific server)
         ↑ full string = FQDN

| Term | Definition | Example | |---|---|---| | Hostname | Name of a specific device/service | www, api, mail | | Domain name | Registered name for an organization/service | mybusiness.com | | Subdomain | Prefix under a domain, controlled by domain owner | api.mybusiness.com | | FQDN | Full dot-separated name from host to root | www.mybusiness.com. | | TLD | Top-level domain | .com, .org, .io |

The trailing dot in an FQDN (www.mybusiness.com.) represents the DNS root. Resolvers strip it when displaying to users, but it's significant internally — www.mybusiness.com without a trailing dot is relative; with the dot, it's absolute from the root.

DNS resolution path

Browser: "what's the IP of api.mybusiness.com?"
         ↓
1. Check local cache + /etc/hosts
         ↓ (cache miss)
2. Ask recursive resolver (ISP or 8.8.8.8)
         ↓ (resolver asks root)
3. Root nameserver: "I don't know, but .com TLD is at 192.5.6.30"
         ↓
4. .com TLD nameserver: "I don't know api, but mybusiness.com NS is at ns1.examplehost.com"
         ↓
5. mybusiness.com authoritative NS: "api.mybusiness.com → 203.0.113.10"
         ↓
6. Recursive resolver caches the answer (until TTL expires) and returns to browser

Each level is authoritative for its zone. The DNS root delegates to TLD nameservers. TLD nameservers delegate to domain registrars. Domain owners control their authoritative nameservers (via their registrar's NS records).

A hostname resolves differently depending on the search domain — relative names without a dot can produce unexpected results

GotchaNetworking

Most operating systems have a search domain list (/etc/resolv.conf on Linux, System Preferences on macOS). When you query a name without a trailing dot, the resolver may append search domains. Inside a Kubernetes cluster, 'redis' resolves to 'redis.default.svc.cluster.local' because the cluster sets a search domain of 'default.svc.cluster.local'. This is why Kubernetes service DNS works with short names — but it also means 'mail' might resolve to 'mail.yourcompany.com' unexpectedly if your corporate DNS has a search domain configured.

Prerequisites

• DNS resolution
• /etc/resolv.conf
• Kubernetes DNS

Key Points

• FQDN with trailing dot → absolute DNS query, no search domain appended.
• Name without trailing dot → resolver may try appending search domains before querying root.
• Kubernetes: service name 'redis' resolves via search domain 'namespace.svc.cluster.local'.
• /etc/hosts overrides DNS — entries here bypass the resolver entirely, affecting all processes on the host.

Inspecting DNS records

# Full resolution path
dig api.mybusiness.com +trace

# Check A record (IPv4)
dig api.mybusiness.com A

# Check AAAA record (IPv6)
dig api.mybusiness.com AAAA

# Check NS records (authoritative nameservers)
dig mybusiness.com NS

# Check MX records (mail exchange)
dig mybusiness.com MX

# Reverse DNS: IP → hostname
dig -x 203.0.113.10

# Query specific resolver (bypasses /etc/resolv.conf)
dig @8.8.8.8 api.mybusiness.com

The TTL in the response controls how long resolvers cache the record. Lower TTL (60s) enables faster propagation of DNS changes; higher TTL (86400s = 24h) reduces resolver load and improves performance.

A team changes their A record from 203.0.113.10 to 203.0.113.20. The old server starts receiving traffic for days afterward. Why?

easy

The A record had TTL=86400 (24 hours). DNS changes were applied to the authoritative nameserver immediately.

• AThe change wasn't applied to the authoritative nameserver correctly

  Incorrect.The question states the change was applied immediately. The issue is downstream caching, not the authoritative server.
• BRecursive resolvers and clients cached the old A record for up to 86400 seconds (24 hours). Clients that resolved before the change will use the cached address until their TTL expires.

  Correct!DNS TTL controls how long resolvers cache a record. With TTL=86400, a resolver that fetched the old IP at 10am will keep serving that old IP until 10am the next day, regardless of when you changed the authoritative record. Different resolvers and clients queried at different times, so the old IP trickles out over up to 24 hours. Best practice: lower the TTL to 60-300 seconds several hours before a planned migration, then make the change. After confirming the new IP serves correctly, raise the TTL again.
• CThe old server needs to be shut down to stop receiving traffic

  Incorrect.Traffic goes to whichever IP address clients resolve. Shutting down the old server would cause connection errors for clients that still have the cached old IP, but it doesn't clear the DNS cache.
• DDNS changes take 48-72 hours to propagate globally — this is a known limitation

  Incorrect.DNS changes propagate as TTLs expire. With TTL=86400 (24 hours), full propagation takes up to 24 hours, not 48-72 hours. The 48-72 hour figure is a legacy rule of thumb from when TTLs were commonly set to 2-3 days. With appropriate TTLs, propagation can be minutes.

Hint:What does TTL=86400 mean for caching behavior at recursive resolvers?