1. The problem: why do we need DNS?

Computers route packets using IP addresses like 157.240.22.174 or 2a03:2880:f12f:83:face:b00c:0:25de. Humans and apps use names like instagram.com. Something has to translate — and it has to do so for billions of devices, millions of times per second, in a few milliseconds, without one central server that could fail or be overwhelmed.

Names also give system designers a crucial layer of indirection. If the Instagram app had a hard-coded IP address baked into it:

• Instagram could never move servers, add data centers or change cloud providers without breaking every installed app.
• Every user worldwide would hit the same IP, no matter whether they were in Mumbai or Montreal — no way to send them to a nearby edge.
• If that IP's data center failed, there'd be no way to send users somewhere else.

With DNS, the app asks "where is i.instagram.com right now, for me?" and Instagram's name servers can answer differently depending on the user's location, server health and load. DNS is therefore the very first hop in Instagram's architecture diagram and the first lever for global traffic management.

2. The DNS hierarchy

2.1 Anatomy of a name

Read a domain name right to left. The fully qualified name i.instagram.com. has an invisible trailing dot representing the root:

i   .   instagram   .   com   .   (root)
│        │               │        └── root zone: managed by IANA, served by root servers
│        │               └─────────── top-level domain (TLD): .com, run by Verisign
│        └─────────────────────────── second-level domain: instagram.com, owned by Meta
└──────────────────────────────────── subdomain / hostname inside Meta's zone

Each level is responsible only for delegating to the next. The root doesn't know Instagram's IP; it only knows who runs .com. The .com servers don't know it either; they know which name servers are authoritative for instagram.com. A zone is the slice of the namespace one organisation administers, and NS records are the signposts that delegate a sub-zone to other servers.

2.2 The three kinds of servers in the hierarchy

You don't talk to these servers directly from your phone. That's the job of a resolver.

3. Resolvers and the full resolution walkthrough

3.1 Stub resolvers vs recursive resolvers

• The stub resolver is the tiny DNS client in your phone's OS. It doesn't walk the hierarchy; it sends one question ("A record for i.instagram.com?") to a configured recursive resolver and waits for the final answer. This is a recursive query: "please do all the work for me".
• The recursive resolver (also called a caching or full-service resolver) does the walking. It's typically run by your ISP or mobile carrier, or a public service such as Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1) or Quad9 (9.9.9.9), or by your company. It sends iterative queries to root, TLD and authoritative servers — each of which answers with either the final answer or a referral ("I don't know, ask these servers") — and caches everything it learns.

3.2 Full resolution, step by step (cold caches)

 Phone app/OS        Recursive resolver        Root server        .com TLD server     instagram.com auth NS
 (stub resolver)     (ISP / 8.8.8.8)
     |                      |                       |                    |                      |
 (1) | A? i.instagram.com   |                       |                    |                      |
     |--------------------> |  cache miss           |                    |                      |
     |                      | (2) A? i.instagram.com|                    |                      |
     |                      |---------------------> |                    |                      |
     |                      | (3) referral: ".com is served by a.gtld-servers.net …" (NS + glue IPs)|
     |                      | <-------------------- |                    |                      |
     |                      | (4) A? i.instagram.com                     |                      |
     |                      |------------------------------------------>|                      |
     |                      | (5) referral: "instagram.com NS = Meta's name servers" (+ glue)   |
     |                      | <------------------------------------------|                      |
     |                      | (6) A? i.instagram.com                                            |
     |                      |----------------------------------------------------------------->|
     |                      | (7) answer: i.instagram.com A 157.240.x.x  TTL 60                 |
     |                      |     (chosen for THIS resolver's location / client subnet)         |
     |                      | <-----------------------------------------------------------------|
     |                      | (8) cache: root/TLD referrals for days, the A record for 60 s     |
 (9) | <-- 157.240.x.x ---- |                                                                   |
     | OS + app cache it; now open a connection (TCP/TLS or QUIC) to 157.240.x.x            |

1. The app calls the OS resolver (e.g. getaddrinfo), usually asking for both A (IPv4) and AAAA (IPv6) records. The OS checks its own cache first.
2. On a miss, the stub sends a UDP packet (port 53) — or an encrypted DoH/DoT query — to the recursive resolver.
3. The resolver checks its cache. It almost always already knows the root and .com servers (their NS records have TTLs of days), so steps 2–5 are usually skipped. It starts at the closest ancestor it knows.
4. The root answers with a referral: NS records for .com, plus glue records (the IPs of those name servers, needed to avoid a chicken-and-egg lookup).
5. The .com TLD server answers with another referral: the NS records for instagram.com (Meta's own name servers) and their glue.
6. Meta's authoritative server answers with the final record. This is where the intelligence lives: the IP returned depends on where the query appears to come from and which PoPs/regions are healthy.
7. The resolver caches the answer for its TTL and returns it to the phone; the OS and the app may cache it too.
8. Only now can the app start the TCP/TLS or QUIC handshake (see Networking basics).

Timing: a fully cold lookup needs up to four network round trips from the resolver (root, TLD, authoritative, plus the phone ⇄ resolver hop) — easily 100–300 ms if any of those servers is far away. A warm lookup answered from the resolver's cache costs one phone ⇄ resolver round trip (5–50 ms; more on a 3G radio), and an OS/app cache hit costs ~0 ms. Because root and TLD answers are cached for days and popular names like i.instagram.com are queried constantly, most lookups at big ISPs are cache hits.

DNS mostly uses UDP because a query and answer each fit in a single packet — no handshake needed, which keeps lookups to one round trip. Responses that are too large (e.g. big DNSSEC answers) fall back to TCP; EDNS(0) extensions allow larger UDP payloads and extra options such as Client Subnet.

4. Caching layers and TTLs

DNS works at planetary scale only because of caching. Every answer carries a TTL (time to live) in seconds, set by the zone owner: "you may reuse this answer for this long without asking again". Caches exist at several layers:

Each cache counts the TTL down from when it received the answer. If the authoritative TTL is 300 s and the resolver got the answer 200 s ago, it hands your phone the record with TTL 100.

4.1 How much load does caching save?

Assume 500M daily users, each device resolving the API hostname 20×/day (app opens, network changes)
  device-level lookups = 10 billion/day ≈ 116,000 per second
Assume those devices sit behind ~100,000 recursive resolver instances and the TTL is 60 s
  worst case at the authoritative = 100,000 resolvers × 1 query / 60 s ≈ 1,700 QPS
→ resolver caching cuts authoritative load by ~70× even with a short 60 s TTL.
  With TTL = 3600 s it would be ~28 QPS — but changes would take up to an hour to propagate.

5. Record types

A zone is a list of resource records: name, TTL, class (almost always IN), type, value. The ones every engineer should know:

Here is a tiny, illustrative zone (documentation IP ranges, not Instagram's real records):

$ORIGIN example-photos.com.
@        3600  IN SOA  ns1.example-photos.com. hostmaster.example-photos.com. (
                       2026102301 ; serial (bump on every change)
                       7200       ; refresh: secondaries check every 2 h
                       900        ; retry
                       1209600    ; expire: secondaries give up after 14 days
                       300 )      ; negative-cache TTL
@        172800 IN NS   ns1.example-photos.com.
@        172800 IN NS   ns2.other-provider.net.     ; second provider = no single point of failure
api        60   IN A    203.0.113.10                ; short TTL: steered dynamically
api        60   IN AAAA 2001:db8::10
www       300   IN CNAME web.example-photos.com.
media     300   IN CNAME photos.cdn-provider.example.  ; hand media off to a CDN
@        3600   IN MX   10 mail.example-photos.com.
@         300   IN TXT  "v=spf1 -all"

Use dig to explore real DNS: dig i.instagram.com A, dig +trace instagram.com (shows the root → TLD → authoritative walk), dig instagram.com NS.

6. DNS as a traffic-steering tool

A simple authoritative server returns the same static records to everyone. A smart authoritative server (sometimes called a Global Server Load Balancer, GSLB) computes the answer per query. This is the first layer of global load balancing in Instagram's architecture (see Load balancing).

6.1 GeoDNS and latency-based routing

• Geolocation routing maps the query's source IP to a country/region using a GeoIP database and returns the PoP or region assigned to that area. Also used for data residency rules (e.g. keep EU users on EU infrastructure — see Multi-region).
• Latency-based routing goes further: the provider continuously measures real latency from networks to each PoP (from probes or from real-user measurements in the app/browser) and returns the endpoint with the lowest measured latency for that network — which isn't always the geographically closest one.

The catch: the authoritative server sees the resolver's IP, not the user's. If a user in Chennai uses a public resolver whose nearest instance is in Singapore, a naive GeoDNS might send them to a Singapore PoP. The fix is EDNS Client Subnet (ECS): the resolver forwards a truncated prefix of the client's IP (e.g. a /24) so the authoritative server can geolocate the actual user. (Some privacy-focused resolvers deliberately don't send ECS.) Anycast resolvers with instances in many cities also mitigate the problem.

6.2 Weighted routing

Return different answers in configured proportions: 90% of responses point at the old cluster, 10% at the new one. Uses: canary releases of a new region or load balancer, gradual migrations between data centers or clouds, and balancing between regions of different capacity. Because resolvers cache answers and share them among many users, weights are approximate — one resolver serving 1M users who got the "10%" answer moves a big chunk of traffic at once.

6.3 DNS failover with health checks

The DNS provider continuously health-checks each endpoint (e.g. an HTTPS request to /healthz every 10 s from several vantage points). If a region fails N consecutive checks, it's removed from answers; traffic shifts to the remaining healthy endpoints. Variants: active-passive (return the primary unless it's unhealthy, then the secondary) and active-active (return all healthy endpoints).

worst-case failover time ≈ detection time + TTL + client stickiness
  detection: 3 failed checks × 10 s           = 30 s
  TTL                                          = 60 s
  clients that keep existing connections open  = until those connections fail
  → ~1.5 minutes for most users, longer for stragglers that ignore TTLs

That's why DNS failover is good for region-level disasters but too slow and coarse for individual server failures — those are handled by load balancer health checks in seconds.

7. Anycast DNS

Anycast means announcing the same IP address from many locations via BGP. Internet routing then delivers each packet to the "closest" location in network terms. (Contrast with unicast, where one IP = one machine.) DNS is the perfect anycast workload: a query and its answer are each a single UDP packet, so there is no long-lived connection that could break if routing shifts mid-conversation.

• Speed: users automatically reach the nearest DNS server instance — all 13 root server names are anycast, and so are major public resolvers (8.8.8.8, 1.1.1.1) and big authoritative providers.
• Resilience: if one site fails, it stops announcing the route and traffic flows to the next-closest site — no TTLs involved.
• DDoS absorption: an attack is split across every site instead of concentrating on one; each site only absorbs the attack traffic originating near it.

GeoDNS and anycast are often combined: anycast gets the DNS query to a nearby DNS server, and GeoDNS logic in that server picks a nearby PoP for the actual traffic. Anycast is also used directly for HTTP edges and L4 load balancers — see Load balancing and CDN.

8. TTL trade-offs

Practical rules:

• Use short TTLs (e.g. 30–300 s) on hostnames you steer dynamically, and long TTLs on NS records and anything static.
• Before a planned migration, lower the TTL (e.g. from 1 day to 60 s) at least one old-TTL period in advance, make the change, verify, then raise it again.
• Don't rely on DNS alone to drain traffic: some clients and resolvers cache longer than you asked. Keep old endpoints serving (or redirecting) for a while.
• Remember the resilience paradox: very short TTLs make you more dependent on your DNS servers being reachable every minute.

9. DNS as a single point of failure

Every request to Instagram starts with DNS. If clients can't resolve the hostname, it doesn't matter that every server, database and cache is perfectly healthy — to users, the service is down. And because DNS outages affect every hostname in a zone at once, they tend to be total rather than partial. Caching softens the blow (answers already cached keep working until their TTL expires), but with short TTLs the grace period is minutes.

9.1 Case study: the 2016 Dyn DDoS

On 21 October 2016, Dyn — a major managed DNS provider serving as the authoritative DNS for many large websites — was hit by a series of massive distributed denial-of-service attacks. The traffic came from the Mirai botnet: a large army of compromised Internet-of-Things devices (cameras, DVRs, home routers with default passwords) flooding Dyn's servers with DNS queries.

• For several hours, especially on the US East Coast and in Europe, resolvers couldn't get answers from Dyn's name servers.
• As cached records expired, sites such as Twitter, GitHub, Reddit, Netflix, Spotify and many others became unreachable for large numbers of users — even though their own servers were fine.
• Companies that used only Dyn had no fallback. Companies with a second DNS provider listed in their NS records stayed largely reachable, because resolvers retry other name servers when one doesn't answer.

9.2 Case study: the October 2021 Facebook / Instagram / WhatsApp outage

On 4 October 2021, Facebook, Instagram, WhatsApp and Messenger disappeared from the internet for roughly six hours — one of the largest outages in internet history. Meta's public post-mortem explained the chain of events:

 1. Routine maintenance: an engineer runs a command intended to ASSESS global backbone capacity.
        │  a bug in the audit tool that should have blocked it lets it through
        ▼
 2. The command takes down ALL connections in Meta's backbone network
    → data centers are disconnected from each other and from the edge PoPs.
        ▼
 3. Meta's authoritative DNS servers (at the edge) run a safety check:
    "If I can't reach the data centers, I'm unhealthy → stop advertising my anycast IPs via BGP."
    Every DNS site reaches the same conclusion at the same time.
        ▼
 4. BGP withdrawal: the internet's routers forget how to reach Meta's DNS server IP prefixes.
    The DNS servers are RUNNING — but unreachable.
        ▼
 5. Resolvers worldwide: "A? i.instagram.com" → no route to the name servers → SERVFAIL.
    Cached answers expire within minutes; apps and users RETRY aggressively
    → public resolvers see a big surge in queries for Meta's domains.
        ▼
 6. Internal tools that depended on the same network/DNS are also down;
    engineers must get PHYSICAL access to data-center hardware (behind strict security) to fix it.
        ▼
 7. Backbone restored → BGP routes re-announced → DNS reachable → traffic returns.
    Load is ramped back carefully: suddenly restoring all traffic risks power surges and cache stampedes.

Why this case study is so instructive for system design:

• A "safe" local rule caused a global failure. Withdrawing an unhealthy site from anycast is correct for one site; doing it everywhere simultaneously removed the whole service. Health-check logic needs a "don't all fail closed at once" safeguard (e.g. never withdraw the last N sites, or fail open when every site is affected).
• DNS + BGP sit beneath everything. Even perfectly healthy data centers are useless if nobody can find them.
• Shared fate between production and recovery tooling. When the network and DNS went down, so did the internal tools engineers would normally use to fix them. Out-of-band management access is critical.
• Retry storms amplify outages — for third parties too (public resolvers got hammered). Clients need backoff with jitter (see Resilience patterns).
• Recovery is its own risk: restoring billions of users at once can overload power, caches and databases. Meta had rehearsed "storm" drills for exactly this kind of recovery.
• Change safety: audit tools, staged rollouts and blast-radius limits for network changes are as important as for code deploys.

10. DNS security and privacy

10.1 Attacks

• Spoofing / cache poisoning: classic DNS over UDP has no authentication. An attacker who guesses a query's ID and port can inject a forged answer into a resolver's cache, sending everyone using that resolver to a malicious IP. The 2008 "Kaminsky attack" made this practical; resolvers responded by randomising source ports and other hardening.
• Hijacking: compromise the domain's registrar account or DNS provider account and change the NS or A records. Mitigate with registrar locks, MFA and change alerts.
• DDoS on authoritative servers (Dyn) or reflection/amplification attacks that abuse open resolvers to flood a victim.
• Surveillance and tampering: plaintext DNS reveals every hostname you visit to anyone on the path, and some networks rewrite answers (censorship, ad injection).

10.2 Defences

For a mobile app, DoH has a practical bonus: the app (or OS) can resolve names over the same HTTPS stack it already uses, which avoids broken or hijacking ISP resolvers. Note that DoH protects the hop to the resolver — the TLS SNI field and the destination IP can still reveal which site you're connecting to (Encrypted Client Hello is the emerging fix). See also Security.

11. How Instagram uses DNS

Instagram's DNS has two jobs: tell clients where to connect, and steer them to the right nearby place — for two very different kinds of traffic.

11.1 Why separate hostnames for API and media?

• Different infrastructure: media goes to CDN cache servers optimised for throughput and disk; API calls go to proxies that forward to application servers. Separate names let DNS send each to the right fleet.
• Different routing and TTL policies: media hostnames can be pinned to a specific cache cluster to maximise cache hit ratio; API hostnames are steered to the best region for that user.
• Cookieless, isolated domain: putting user-generated media on a separate registrable domain (cdninstagram.com, not instagram.com) means browsers never attach Instagram login cookies to image requests (saving bytes on every request) and isolates any malicious uploaded content from the main site's security origin.
• Independent scaling and failure domains: a CDN problem doesn't have to break the API, and vice versa.

11.2 Steering users to nearby PoPs and regions

1. The app asks for i.instagram.com. The query reaches one of Meta's anycast authoritative DNS servers — a nearby one, thanks to anycast.
2. That server looks up the resolver's network (and the client subnet via ECS, if provided) in a mapping computed centrally from latency measurements, PoP capacity and health. Meta engineers have publicly described such a system (named Cartographer) that computes which edge PoP each client network should use and pushes the map to the DNS servers.
3. The answer — the VIP (virtual IP) of the best nearby PoP — comes back with a short TTL, so the mapping can change quickly when a PoP is overloaded, drained for maintenance, or fails.
4. The app connects to that PoP. From there, Meta's own L4/L7 load balancers and backbone take over (see Load balancing).
5. The feed response contains media URLs on CDN hostnames, which the app resolves the same way — landing on a nearby cache. See CDN.

Rough numbers

Assume 500M DAU, 20 lookups/device/day for the API host and ~5 distinct CDN hostnames
  device lookups ≈ 500M × 20 × (1 + 5) = 60 billion/day ≈ 700K/s at the device level
  most are answered by OS or resolver caches;
  authoritative QPS ≈ (number of active resolvers × hostnames) / TTL
                    ≈ (200,000 × 6) / 60 s ≈ 20,000 QPS — modest for an anycast fleet.
  A cache miss adds ~20–150 ms to the first request; with a 60 s TTL and long-lived
  connections, that cost is paid on only a small fraction of requests.

12. Trade-offs & common pitfalls

Common pitfalls

• Single DNS provider (Dyn 2016): add a second, independent provider or self-hosted secondary.
• Using DNS for fast failover of individual servers: use load balancer health checks for that; DNS is for region-level steering.
• Forgetting to lower the TTL before a migration, then waiting a day for caches to expire.
• Tiny TTLs everywhere: higher latency and query cost, and no cushion if DNS itself has problems.
• CNAME at the zone apex or long CNAME chains (each hop can add a lookup).
• Clients that cache DNS forever (long-running JVMs, connection pools that never re-resolve) and keep hitting decommissioned IPs.
• Health checks that can all fail together and withdraw every site (Meta 2021).
• Unprotected registrar accounts: domain hijacking via a phished password.
• Ignoring resolver geography: GeoDNS without ECS sends some users to far-away PoPs.

13. Real-world technologies

14. Interview corner

15. Check your understanding

Related lessons

• Networking basics — IP, BGP, UDP and what happens after the IP is known
• CDN — how DNS steers media requests to nearby PoPs
• Load balancing — GSLB vs local load balancing and anycast L4 edges
• Clients — DNS caching, pre-connecting and the client's view of the first hop
• Multi-region — DNS-based regional failover and data residency
• Security — DDoS protection, DNSSEC, DoH and domain hijacking
• Resilience patterns — retries with backoff to avoid DNS query storms
• Core principles — single points of failure and availability math