Skip to content
Published on

A DNS Deep Dive — The Infrastructure Hidden Behind Names

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

Introduction — Free DNS Reignites Interest

In the first half of 2026, DNS became a talking point again on GeekNews and Hacker News. The trigger was news that a CDN provider was opening its Anycast DNS service for free. Developers raised the question "you give away DNS for free? then where does this company make money," alongside a more fundamental one: "but why does DNS need such complex infrastructure in the first place?"

For most developers, DNS is just "the thing that turns a domain into an IP." You type an address into the browser and somewhere it is magically resolved and connected to a server. But behind that magic are tens of thousands of servers scattered across the globe, sophisticated caching layers, routing tricks, and security extensions, all intertwined. DNS is the oldest yet most underrated distributed system on the internet.

This article digs deep into the infrastructure hidden behind names. It covers what actually happens in the brief instant a name becomes an IP, why Anycast is needed, what DNSSEC protects, and how DoH and DoT change privacy.

The DNS Hierarchy

DNS is not one giant server but a hierarchy of delegation. At the very top is the root, and it branches out below like a tree.

                    . (root)
                    |
        +-----------+-----------+
        |           |           |
       com         org          kr
        |           |           |
     example     wikipedia    co.kr
        |
      www.example.com

The key is reading names right to left. www.example.com actually has one more hidden dot behind it, making it www.example.com., and the trailing dot is the root. Each level only knows "who knows" the next level.

  • Root servers: know who manages top-level domains (TLDs) like com, org, kr.
  • TLD servers: know where the authoritative server for example.com is.
  • Authoritative servers: know the actual IP of www.example.com.

Thanks to this delegation structure, no single organization needs to manage every name on the internet. Each is responsible only for its own zone and delegates the rest downward.

The Resolution Process — Recursive and Authoritative

Resolving a single name involves two kinds of servers cooperating: the recursive resolver and the authoritative server.

The recursive resolver is an errand-runner that finds the answer on your behalf. Your device, your ISP, or a public resolver plays this role. The authoritative server is the server that holds the final answer for a particular zone.

When resolving www.example.com for the first time, the actual flow is as follows.

client --> recursive resolver
                  |
                  |-- 1. to root: who manages com?
                  |<-- com TLD server address
                  |
                  |-- 2. to com TLD: who has example.com?
                  |<-- example.com authoritative server address
                  |
                  |-- 3. to authoritative: IP of www.example.com?
                  |<-- final IP address
                  |
client <-- recursive resolver (final answer)

This process is called iterative querying. The recursive resolver starts from the root and descends one step at a time, narrowing down the answer. From the client's perspective it is a recursive query, since it asks the resolver once and receives the final answer.

The important thing is that most of this whole process is skipped by caches. The resolver usually already knows root and TLD information, so in practice it often performs only the last step.

Record Types — What DNS Holds

DNS does not hold only IP addresses. Various record types store different kinds of information.

RecordPurposeValue form
AName to IPv4 address93.184.216.34
AAAAName to IPv6 address2606:2800:220:1:248:1893:25c8:1946
CNAMEAlias to another namewww points to example.com
MXMail server designationPriority and mail host
TXTArbitrary text (verification, etc.)Policies like SPF, DKIM
NSAuthoritative servers for this zoneNameserver hostnames
SOAAdministrative info for the zoneSerial, refresh interval, etc.

Among these, CNAME is often misunderstood. A CNAME is an alias declaring "this name is actually the same as that name." So when a resolver hits a CNAME, it must resolve that target name again. Also, a CNAME cannot in principle be placed at the zone apex, so many DNS providers offer a special record to work around this.

TXT records were originally for free text, but now they have become a core means of mail authentication (SPF, DKIM, DMARC) and domain ownership verification. This is a prime example of DNS being used as a policy distribution channel beyond a simple address book.

TTL and Caching — What Makes DNS Fast

If DNS resolved from the root every time, the internet would grind to a halt. The key that makes DNS practical is caching, and what governs caching is TTL (Time To Live).

Each record carries a TTL value. It indicates "for how many seconds may this answer be cached." If the TTL is 3600, the resolver reuses that answer for one hour and does not ask the authoritative server again during that time.

Setting TTL is a trade-off.

  • Long TTL: high cache hit rate, so it is fast and reduces load on the authoritative server. But changing the IP takes a long time to reflect worldwide.
  • Short TTL: changes propagate quickly. But queries become frequent, raising load and slowing things slightly.

In practice you tune this trade-off to the situation. For example, ahead of a server migration you lower the TTL in advance, and raise it again once the switch is done. This minimizes downtime at the moment of transition.

Caching happens at multiple layers: browser cache, operating system cache, recursive resolver cache. So even after changing a record, you get the situation "why is it still going to the old IP?" Usually it is because some cache somewhere is waiting for the TTL to expire.

Anycast — One IP, Dozens of Servers

Here comes Anycast, the core technology behind the free DNS news. In ordinary routing (unicast), one IP points to one server. Anycast is different. The same IP address is advertised simultaneously by servers in many locations worldwide.

        the same IP advertised from many places
        
  Seoul user  ---> [Seoul node]  \
  London user ---> [London node]  >  all the same IP
  NY user     ---> [NY node]     /
  
  routing sends each user to the "nearest" node

Internet routing (BGP) automatically sends each user to the network-nearest node. The Seoul user goes to the Seoul node, the London user to the London node. Users do not even need to know which node they are connected to.

Anycast gives DNS three benefits.

  • Reduced latency: a geographically close node responds, so it is fast.
  • Load distribution: traffic naturally spreads across many nodes.
  • Availability and DDoS defense: even if one node dies or is attacked, routing sends users to another node.

This is why root servers and large public resolvers use Anycast. We say "13 root servers," but in reality, thanks to Anycast, there are physical instances in hundreds of places worldwide.

GeoDNS — Different Answers by Location

If Anycast gives "the same answer from the nearest place," GeoDNS gives "a different answer by location." It looks at the recursive resolver's location (or client subnet information) and returns an IP optimized for that region.

For example, it returns an Asian data center IP to Asian users and a European data center IP to European users. The core mechanism by which a CDN sends users to a nearby edge is exactly this GeoDNS.

Anycast and GeoDNS are often used together but operate at different layers. Anycast implements locality at the routing layer, GeoDNS at the DNS response layer. Combining the two lets you process the DNS query itself at a nearby place and also steer the returned content IP toward a nearby place.

DNSSEC — Protecting Answers From Forgery

DNS's fundamental weakness is trust. With original DNS there is no way to tell whether the answer the recursive resolver received truly came from the authoritative server or was forged by someone in the middle. Cache poisoning attacks exploit this. If an attacker plants a fake answer in the resolver cache, the user is steered to a fake server even after typing the real site's address.

DNSSEC solves this with digital signatures. Each DNS response carries the authoritative server's signature, and the resolver verifies it. Since the signature chain runs from the root downward, trusting the root lets you trust the whole chain.

  root signature --> TLD signature --> domain signature --> record
        |                |                  |
    trust anchor     chain verify        chain verify

Note that DNSSEC guarantees only integrity and authenticity. That is, it proves "this answer was not forged," but it does not guarantee "the query content was not eavesdropped." The response itself still travels in plaintext. Privacy is the job of other technologies.

Privacy — DoH and DoT

Traditional DNS queries travel unencrypted in plaintext. This creates a serious privacy problem. Which sites you visit can be seen plainly by anyone on the network path (ISP, public Wi-Fi operator, government). Even when the web traffic itself is encrypted with HTTPS, "where you are trying to connect" leaked out through DNS.

Two standards emerged to solve this.

  • DoT (DNS over TLS): encrypts DNS queries with TLS on a dedicated port. You can tell it is DNS traffic but cannot see the content.
  • DoH (DNS over HTTPS): wraps DNS queries in HTTPS requests. Hard to distinguish from ordinary web traffic, providing stronger concealment.

Summarizing the difference between the two:

AspectDoTDoH
TransportDedicated port, TLSOver HTTPS
IdentifiabilityIdentifiable as DNSBlends into web traffic
Admin controlRelatively easyHard (controversial)
Main useOS/network levelBrowser level

DoH strengthens privacy but also spawned controversy. The way enterprises or schools blocked certain sites via network policy becomes powerless against DoH. The tension between privacy and administrative control is still an ongoing discussion.

Performance and Availability — Why DNS Is the First Bottleneck

When talking about web performance, DNS is often forgotten, yet it is the first gate of every connection. The first thing the browser does when opening a page is DNS resolution, and if that is slow, everything after it is delayed.

There are several practical techniques to improve performance.

  • Appropriate TTL: too short and frequent queries slow you down; too long and you lose flexibility.
  • Using Anycast resolvers: resolution at a nearby node shortens round-trip time.
  • Connection reuse and prefetch: use DNS prefetch, where the browser resolves domains in advance.
  • Minimizing CNAME chains: layered aliases increase resolution steps.

On the availability side, DNS easily becomes a single point of failure. If DNS dies, nobody can connect even if the server is perfectly fine. So important services duplicate nameservers across different providers so that name resolution continues even if one provider suffers an outage.

The Relationship Between CDN and DNS

In the modern web, DNS and CDN are inseparable. The first step by which a CDN sends users to the nearest edge server is DNS. When a user resolves a domain, the CDN's GeoDNS or Anycast returns the address of the edge that is optimal for that user.

Thanks to this structure, the CDN keeps content close to users, and DNS guides users to that nearby content. This is also why the free DNS service mentioned earlier became a talking point. A CDN provider offering DNS for free uses DNS as an entry point and a strategy to funnel users to its CDN and add-on services. The economics of "free DNS" is explained this way.

The Actual DNS Packet — What Travels

To understand how DNS works, it helps to see what actually travels. DNS queries and responses mostly travel over UDP as very small packets. This lightness is the key that makes DNS fast, but it is also the source of its weaknesses.

A typical query carries these elements.

+---------------------------+
| transaction ID (16 bits)  |  <- match query and response
+---------------------------+
| flags (query/response,rec)|
+---------------------------+
| question section          |  <- name + type (A, AAAA...)
+---------------------------+
| answer section            |  <- records (response only)
+---------------------------+
| authority section         |
+---------------------------+
| additional section        |
+---------------------------+

The transaction ID matters here. The resolver attaches a random ID when sending a query and accepts a response only if it carries the same ID. An early DNS vulnerability was that this ID was predictable. If an attacker guessed the ID, they could inject a fake response as if it were real. So now not only the ID but also the source port is randomized to widen the guessing space.

Traditionally, DNS responses had trouble once they exceeded 512 bytes. When UDP packets grew, they were truncated or had to retry over TCP. As large data like DNSSEC signatures came in, this limit became a burden, and an extension mechanism (EDNS) came to allow larger UDP responses.

Negative Responses and Caching

DNS handles not only "it exists" answers but also "it does not exist" answers. When you query a nonexistent name, the authoritative server returns a negative response. The interesting thing is that this "nonexistence" is also cached.

If negative responses were not cached, you could load the authoritative server just by repeatedly querying a nonexistent name. In fact, a misconfigured application sometimes keeps looking up nonexistent names and torments the DNS infrastructure. Negative caching absorbs such load.

The cache time for negative responses is managed separately. The zone's administrative info (SOA record) specifies the negative caching time, so the resolver reuses the "this name does not exist" answer for that duration. Setting this value too long delays reflection of a newly created name, so balance is needed.

Round-Robin and Load Distribution

DNS is also a primitive but effective means of load distribution. If you register multiple A records under one name, the resolver returns them in a different order each time or picks one of several IPs, distributing traffic. This is called DNS round-robin.

  www.example.com query
        |
        v
  +------------------+
  | A 203.0.113.1    |
  | A 203.0.113.2    |  <- return multiple IPs
  | A 203.0.113.3    |
  +------------------+
        |
   client picks one (usually the first)

Round-robin is simple but has clear limits. DNS does not know each server's actual load or health. It calmly returns the IP of a dead server too. So modern systems use intelligent DNS combined with health checks instead of pure round-robin, or place a load balancer behind DNS. Even so, round-robin is still widely used as the simplest distribution layer.

Choosing a Resolver — Public or ISP

Users can choose which recursive resolver to use. By default you use the resolver your ISP provides, but many users switch to a large public resolver. This choice has effects on several fronts.

AspectISP resolverPublic resolver
LatencyUsually closeCan be fast via Anycast
PrivacyISP logsPublic provider logs
FilteringISP policy appliedUsually little filtering
StabilityDepends on ISPLarge provider's infra
FeaturesLimitedLatest support like DoH/DoT

There is a trade-off here. Public resolvers have good performance and features via Anycast and the latest protocols, but in exchange all your visit records concentrate on a few providers. ISP resolvers are local but subject to the ISP's filtering and surveillance. There is no perfect choice; it is a matter of whom you trust more.

DNS Prefetch and Browser Optimization

Browsers use several optimizations to reduce DNS latency. A representative one is DNS prefetch. If a page has links, the browser resolves those domains in advance before the user clicks. At the moment of the actual click, the IP is already ready, so the connection is fast.

  page load
      |
      v
  link found (different domain)
      |
      v
  resolve DNS in background in advance
      |
      v
  on user click --> IP already cached --> instant connect

This optimization is mostly beneficial but is controversial on the privacy front. Resolving even the domains of links the user did not click exposes that visit intent to the resolver. So some browsers restrict prefetch depending on the situation.

Beyond this, browsers reduce connection-setup cost including DNS through techniques like connection reuse, HTTP connection pooling, and early connection in newer protocols. In web performance optimization, DNS is often forgotten, but polishing this first gate has a surprisingly large effect on overall perceived speed.

Why DNS Uses UDP

There is a reason DNS mostly uses UDP. TCP requires a round trip to establish a connection and must maintain state. UDP, by contrast, finishes with one query and one response, without a connection. This lightness is the key to handling DNS's enormous query volume.

But UDP has a cost. It does not tell you when a packet is lost, does not guarantee order, and has a size limit. So DNS falls back to TCP when responses are large (e.g., DNSSEC signatures, many records) or when UDP is not reliable. That is, DNS takes a dual strategy of fast UDP in normal times and reliable TCP when needed.

This design is a case of the good engineering principle "optimize for the common case, handle the exception separately." The vast majority of queries are handled well by small, fast UDP, and only the rare large response borrows TCP's reliability.

Email and DNS — The World of MX and Authentication

DNS is the backbone of email infrastructure too, not just the web. When sending mail, the sending server looks up the recipient domain's MX record to decide which server to deliver mail to. MX records carry priorities, so the server tries the lower-numbered one first and moves to the next if it fails.

Modern email layers three DNS-based authentications on top of this.

  • SPF: specifies via a TXT record which servers may send mail on behalf of this domain.
  • DKIM: attaches a digital signature to mail and publishes the public key for verification in DNS.
  • DMARC: declares a policy in DNS for what to do (reject, quarantine, pass) when the above two fail.

Without these three, anyone can impersonate your domain and send mail. This clearly shows that DNS sits at the center of trust infrastructure, beyond a simple address book. A large part of spam and phishing defense depends on policies published in DNS.

Observability — How to Diagnose DNS

DNS problems are notoriously tricky to diagnose. Behind the vague symptom "sometimes I cannot connect" may hide cache problems, propagation delays, or wrong records. There are a few approaches to diagnosing DNS in practice.

First, query the same name from multiple locations. Because of Anycast and GeoDNS, different answers may come per location, so looking from only one place misses the problem. Tools that query DNS from multiple points worldwide are useful for this.

Next, check TTL and propagation state. If you changed a record but it is not reflected, usually some cache somewhere is holding the old TTL. Ask the authoritative server directly to confirm the latest value, and back-calculate the time it takes to spread to resolvers from the TTL.

The core principle of DNS observability is "look from multiple layers." You must narrow down which layer among browser, OS, resolver, and authoritative server the problem occurs at to find the cause. Looking from only one layer keeps the truth hidden behind caches.

Pitfalls and a Critical Perspective

Let us point out the pitfalls commonly encountered when handling DNS infrastructure.

Downtime from TTL misunderstanding. If you change the IP but the TTL is long and caches worldwide still hold the old address, for some users the service looks cut off for hours. You need the habit of lowering TTL in advance before a migration.

Single-provider dependency. If a large DNS provider suffers an outage, the countless services depending on it are paralyzed at once. There have been several cases where a large-scale DNS outage halted a big part of the internet. Nameserver duplication is not a choice but a necessity.

Low DNSSEC adoption. DNSSEC is a good idea but its setup is finicky and, done wrong, risks making the entire domain unresolvable. Because of this complexity, adoption is slow. Using automated signing management tools is important for safety.

The centralization paradox of privacy. DoH claims to protect privacy, but if browsers funnel queries to a handful of large resolvers, all visit records concentrate on those few providers. There is criticism that trying to protect privacy can create a new point of surveillance.

Split-Horizon — Same Name, Different Answer

Another technique that shows DNS's flexibility is split-horizon DNS. It gives a completely different answer for the same name depending on where the query comes from. Query from the internal network and it returns an internal IP; query from the external internet and it returns an external IP.

This is common in enterprise environments. When an in-house employee connects to a company service, they connect directly to a private IP on the internal network, and when connecting from outside they go through a public gateway. They use the same domain name, but the actual path differs by location.

Split-horizon is convenient but raises management complexity. You must maintain two sets of zones for internal and external use, and if the two diverge, you get the confusing situation of "it works outside but not inside." So such setups make clear documentation and automated management especially important.

Global Traffic Management — Beyond DNS

For large-scale services, GeoDNS alone is not enough. When deciding which data center to send a user to, you want to consider not just geographic distance but also each data center's current load, health, and network latency. This is the domain of Global Traffic Management (GTM).

GTM, also called intelligent DNS, dynamically adjusts DNS responses according to real-time signals.

  user query
      |
      v
  +--------------------+
  | traffic manager    |
  |  - geo location    |
  |  - data center load|
  |  - health checks   |
  |  - network latency |
  +--------------------+
      |
   pick optimal IP and return

This approach is far more flexible than simple GeoDNS. For example, if a nearby data center is overloaded or in an outage, GTM avoids it and sends the user to a slightly farther one. The user never notices this decision and simply feels the service is working well.

TTL matters again here. However smartly GTM decides, if that decision is held in a stale cache it is useless. So GTM records usually use short TTLs. This is a trade-off that gives up some caching benefit in exchange for real-time responsiveness. You reconfirm that every decision in DNS design ultimately sits on this kind of balance point.

New Records and Evolving DNS

DNS is an old protocol but is still evolving. New record types and features keep being added to reflect the web's new needs.

A representative example is the service binding record. Traditionally, to connect to a server, a client had to resolve the name to an IP and then separately find out connection parameters (port, protocol, encryption settings). New record types carry this information together in the DNS response, letting the very first connection start with optimal settings. This is especially useful for reducing connection latency in newer web protocols.

Summarizing the evolution directions of DNS:

  • Connection optimization: provide connection hints during the name-resolution step to reduce round trips.
  • Privacy strengthening: beyond DoH/DoT, techniques to conceal the query itself more finely are discussed.
  • Security expansion: DNSSEC automation tools have matured, lowering the adoption barrier.
  • Edge integration: as the boundary between CDN and DNS blurs, name resolution itself becomes an entry point of edge computing.

This trend shows that DNS is expanding from a simple "name-to-address converter" into an "intelligent coordinator of internet access."

Practical Tips Summary

Compressing practical tips for developers and operators handling DNS:

  • Lower the TTL in advance before a migration to reduce transition downtime.
  • Always duplicate nameservers. Preferably across different providers.
  • Check the negative caching time to predict delay in reflecting new records.
  • Keep CNAME chains short to reduce resolution steps.
  • Adopt DNSSEC together with automation tools to prevent configuration mistakes.
  • When diagnosing problems, query from multiple locations and multiple layers.
  • Always configure SPF/DKIM/DMARC for email domains.
  • If performance matters, use Anycast resolvers and DNS prefetch.

Most of these tips summarize to "prepare in advance" and "look from multiple angles." DNS is infrastructure that runs quietly well and then blows up big once a problem occurs, so preventive habits are far more valuable than after-the-fact response.

Closing

DNS is the least visible yet most fundamental infrastructure on the internet. Behind a single domain name we casually type, layers of delegation hierarchy, sophisticated caching, Anycast routing, localization, and security signatures are stacked. Because they quietly work well, we usually forget they exist.

The 2026 free DNS trend shows that this old infrastructure is still evolving. Anycast is getting denser, privacy technology is maturing, and the barrier to entry is lowering. But behind that convenience there is always a trade-off. Performance and flexibility, privacy and control, centralization and resilience. That brief instant of turning a name into an IP actually stands on one of the most delicate balance points of internet design.

Next time you type an address into your browser, take a moment to picture the vast machine quietly turning behind it.

References

Discuss on Twitter • View on GitHub