DNS — Names to Addresses

Learning goals

Explain how a hostname becomes an IP address, distinguish recursive from authoritative DNS servers, interpret common record types (A, AAAA, CNAME), understand TTL and caching behavior, and read basic dig output without memorizing every flag.

The problem DNS solves

Humans remember names (api.example.com). Networks route to IP addresses (203.0.113.10 or 2001:db8::1). The Domain Name System (DNS) is the distributed phone book that translates one into the other.

Plain English: before your browser opens a TCP connection, it almost always asks DNS, “What IP goes with this name?” If that lookup fails or returns a stale address, nothing else in the HTTPS story can start.

Resolution steps (stub resolver → answer)

Typical path on a laptop or phone:

1. Application asks the OS resolver: “IP for learning.jdfive.com?”
2. OS cache — if a recent answer exists and TTL has not expired, return it.
3. Configured recursive resolver — often your ISP, 8.8.8.8, or 1.1.1.1 (company laptops may use an internal resolver).
4. Recursive resolver walks the tree — starting at root, then TLD (.com), then authoritative servers for jdfive.com, following delegations until it gets an answer.
5. Answer returned to the app with A/AAAA records (and cached at each layer per TTL).

Your app → OS cache → recursive resolver → root → .com → jdfive.com authoritative → answer

Authoritative servers hold the truth for a zone (the records your DNS provider lets you edit). Recursive resolvers do the legwork on behalf of clients and cache results.

Record types you will see daily

CNAME chain: A CNAME points to another hostname, not directly to an IP. The resolver follows CNAMEs until it hits A/AAAA. You cannot put a CNAME at the zone apex (example.com bare) in classic DNS—providers use ALIAS/ANAME tricks at the edge instead.

Plain English: A/AAAA are the final numeric destination. CNAME says “ask again under this other name.”

TTL: time to live

Every DNS answer carries a TTL (seconds). Caches—recursive resolvers, OS, sometimes the browser—may reuse the answer until TTL expires.

• Low TTL (60–300 s): faster failover when you change IPs; more DNS queries.
• High TTL (hours): less load; slow propagation when you misconfigure a record.

Operational pain: you fix a wrong A record but users still hit the old IP until caches expire. Lower TTL before a planned migration if your provider allows it.

Recursive vs authoritative (precise)

• Recursive resolver (client-facing): accepts queries from stubs, performs full lookup, returns a final answer or NXDOMAIN. Configured via DHCP or /etc/resolv.conf / system settings.
• Authoritative server: answers only for zones it owns; responds with AA (authoritative) bit set for those names.

Your app’s server is neither—it is a stub resolver that delegates to the recursive resolver.

dig intuition

dig (domain information groper) queries DNS from your machine—useful to see what the world gets vs what you think you configured.

dig learning.jdfive.com A +short
dig learning.jdfive.com AAAA +short
dig www.example.com CNAME +trace   # verbose delegation path

Read the ANSWER SECTION for records and TTL. AUTHORITY SECTION shows which nameservers serve the zone. Compare:

dig @8.8.8.8 learning.jdfive.com A    # query Google recursive directly
dig @ns1.yourprovider.com learning.jdfive.com A   # query authoritative

If authoritative is correct but recursive is wrong, wait for TTL or check stale cache. If authoritative is wrong, fix the DNS panel first.

DNS and HTTPS together

TLS certificates are issued for names, validated against what the client requested. DNS must resolve to the server that holds the matching private key. Certificate mismatch (cert for example.com, user typed www.example.com) is a common misconfiguration—fix DNS/CNAME and cert SANs together.

CDNs often ask you to CNAME www to their edge; they terminate TLS at the edge. The DNS story and the TLS story stay linked.

Common mistakes (beginners)

1. Editing DNS and expecting instant global change. TTL and resolver caches delay propagation.
2. CNAME at apex. Classic DNS forbids CNAME on bare example.com; use provider-specific apex records or redirect.
3. Confusing registrar with DNS host. Buying a domain vs hosting its zone files are separate; nameserver (NS) records must point to where records live.
4. Ignoring AAAA. IPv6-only or dual-stack clients may prefer AAAA; missing record can mean slow fallback or failure.
5. Using ping hostname as proof DNS is “fine.” ping uses its own resolver path; use dig for the exact record type you need.

Practice checkpoint

1. What is the difference between authoritative and recursive DNS?

   • Answer: Authoritative servers hold official zone data; recursive resolvers fetch answers on behalf of clients and cache them.

2. A record vs CNAME—when do you stop resolving?

   • Answer: Stop at A/AAAA (IP). CNAME requires further lookup of the target name until A/AAAA.

3. TTL is 3600 and you change an A record. Why might some users still hit the old IP for up to an hour?

   • Answer: Resolvers and OS caches may keep the previous answer until the original TTL expires.

4. What does dig +short learning.jdfive.com A show?

   • Answer: Just the IPv4 address(es) returned for that name, without verbose sections.

Interview angles

• “What happens in DNS when you hit a URL?” — Stub asks recursive; recursive cache or iterative query from root → TLD → authoritative; A/AAAA returned; cached per TTL.
• “CNAME vs A record?” — A maps name to IP; CNAME maps name to another name (alias). Apex CNAME limitations.
• “How would you debug DNS for a production outage?” — Compare authoritative vs public recursive (dig @8.8.8.8), check TTL, trace delegations, verify NS glue, check recent panel changes.

Next: /networking/learn/http/http-semantics/