An Introduction to DNS Traffic Management - Shopify

DNS as a Resiliency Tool

The Domain Name System (DNS) does far more than translate human-readable names into IP addresses. When used deliberately, it becomes a traffic management layer that can steer requests, absorb failures, and distribute load across distributed systems. This first part of a two-part series covers the fundamentals: what DNS is, how traffic management works, and why the two belong together.

From Host Tables to the Domain Name System

DNS predates the modern internet by roughly a decade. In the early days of ARPANET, only a handful of university computers were connected, and their addresses were easy enough to remember. As the network grew, the Stanford Research Institute maintained a shared file mapping hostnames to addresses. This file, originally HOSTS.TXT and now familiar to Unix users as /etc/hosts, was distributed to member organizations.

By the early 1980s, the file had become too large to download and maintain efficiently. The manual process could not keep pace with the network's expansion. DNS emerged as the automated replacement: a protocol that converts memorable domain names into Internet Protocol (IP) addresses, structured so that no single authority must track every host.

How DNS Is Organized

Think of DNS as a hierarchical library. Domain names are organized from least to most specific. For shops.myshopify.com, the .com suffix is the broadest category, and shops is the most precise qualifier. Resolving that name means navigating the library: find the .com shelf, pick the myshopify book, and open it to the shops page.

That page contains a fundamental pairing: the hostname and the IP address it maps to, for example 23.227.38.64. It also contains a due date, called Time To Live (TTL) — the duration for which the mapping is considered valid. Resolvers cache that answer for the TTL period. After expiration, the mapping must be fetched again to confirm it is still accurate.

The library keeps multiple identical copies of each book, held by different editors. In DNS terms, the editors are DNS providers, the shelves point to domain nameservers, the books are zones hosted on those servers, and the pages are DNS records. At the top are the root servers: a set of 13 nameservers, named a through m, responsible for directing queries to the nameservers of the Top Level Domains (TLDs).

Caching applies to failures as well. A Negative TTL defines how long a resolver may cache an NXDOMAIN response for a non-existent domain. Until that timer lapses, even a newly published record will not be visible to every requester.

Traffic Management Fundamentals

Traffic management is the discipline of planning and controlling movement to keep it safe, orderly, and efficient. On roads, that means detecting congestion and redirecting drivers before they hit the jam. Navigation apps gather real-time data about position and speed, then suggest alternative routes so that traffic can be spread across available capacity.

The same logic applies in other contexts. Borders route travelers through different booths depending on their passport. Cities route bikes, trucks, and cars on separate infrastructure. In every case, the guiding principle is the same: use available data to decide where each request should go.

Applying Traffic Management to DNS

DNS traffic management means serving data-driven answers: different responses to a DNS query depending on who asked, or on the request itself. A service with two server clusters can respond to half the queries with one cluster's address and the other half with the second cluster's address. Clients connect to whichever cluster they were directed to, with no further intervention.

That flexibility is limited by caching behavior. Answer
s are cached by resolvers for the TTL duration, so a client will not re-query until the TTL expires. A short TTL, like 15 seconds, forces frequent re-resolution, allowing fast changes to take effect quickly, but it also imposes an ongoing performance cost. If resolution adds one second per query, a 15-second TTL adds up to 5760 seconds of additional delay per client per day — roughly 1 hour 36 minutes. Raising the TTL to 60 seconds cuts that overhead to 1440 seconds, or 24 minutes per day.

The trade-off is between freshness and speed, and traffic changes through DNS are not instant. Updates propagate within a window that should be no longer than the configured TTL, though on rare occasions downstream resolvers may override TTL values without the client's knowledge. It does not happen often, but it is a factor to account for when relying on DNS for traffic shaping and failover.

DNS Traffic Management in Practice

DNS traffic management proves especially valuable for systems that lack network-level load balancing—no IP-level load balancer or front-facing proxy to distribute connections once a client has reached the service. At Shopify, several operational patterns rely on DNS-level control.

Failover Without a Network Load Balancer

A primary use case is failing over a service when its live instance crashes or becomes unreachable. With DNS management configured to target two clusters—one active by default—traffic can be redirected to the secondary cluster as soon as the primary is detected as unavailable. This is known as active-passive operation. When the primary recovers, traffic shifts back.

The client-visible impact depends largely on the DNS TTL, but if the primary's unavailability is detected promptly, the failover can be nearly seamless. The approach also relieves pressure on on-call teams: end users continue reaching the healthy cluster while the underlying issue is diagnosed and resolved, sometimes allowing the work to be deferred to the next business day.

Splitting Traffic Across Endpoints

As a service grows and receives requests from more clients, the load must be distributed among multiple endpoints offering identical functionality. This is active-active traffic sharing. The percentage of DNS requests answered with a given endpoint determines the proportion of traffic it receives.

There can also be a financial incentive for this pattern. When contracting external vendors with minimum usage commitments, splitting traffic between them helps ensure those commitments are met.

Progressive Deployment

Rolling out a potentially disruptive change—a new feature, altered behavior, or a system upgrade—carries inherent risk if done all at once. DNS traffic management enables a more controlled approach. A small percentage of traffic is initially directed to a cluster running the updated code. That percentage is gradually increased until all traffic reaches the new version. This is called a green-blue deployment. The remaining cluster can then be updated, leaving it ready for the next release or prepared to serve as a failover target.

Location-Aware Traffic Routing

Certain endpoints may perform better in some geographies than others, particularly when external vendors are involved. For services where performance matters—as it does for Shopify's merchants and their customers—DNS answers can be tailored to the client's location. Geolocation rules can be defined at various granularities, from country and state or province level to broader world regions. When a request originates from a particular location, the DNS response returns the endpoint best suited for that origin.

From Manual Setup to Self-Service

Shopify's DNS traffic management evolved from numerous manually configured, maintained, and updated setups into a fully automated, self-served system. That system now supports more than 40 domains across over 12 teams, handling more than 100 million requests per 24 hours.