Module 02 · Lesson 2 of 14Free

DNS: how domain names resolve to IP addresses

Level

Beginner

Topic

Networking, APIs and load balancing

Reading time

15 min

The address changed, not every answer

Kartly moves its public entry point to a new IP address before a festival sale. Ten minutes later, some customers reach it. Others still reach the old address.

The team changed one DNS record. Why didn’t every customer start using the new address?

In this lesson’s scenario, Kartly has four app servers behind a load balancer. DNS returns the load balancer’s public address, not an address for each app server.

DNS, the Domain Name System, lets clients look up information by name. Its distributed design separates the published answer from temporary copies held elsewhere. That separation explains both its speed and Kartly’s migration problem.^{1RFC 1034: Domain names - concepts and facilitiesPaul Mockapetris, RFC Editor, 1987}

All addresses and timings below are examples. Names ending in .example are fictional; the hierarchy shown is a teaching model, not a public lookup to run.

The next question is who owns the answer, and who merely remembers it.

One name outlives one address

Imagine shipping 192.0.2.10 inside Kartly’s mobile app. It works until the team moves the entry point. Every installed app now needs another way to discover the replacement.

A name such as kartly.example gives the app a stable reference. The address can change without changing that reference. This separation is a core DNS design goal.^{1RFC 1034: Domain names - concepts and facilitiesPaul Mockapetris, RFC Editor, 1987}

The answer is stored as a record: a typed piece of information associated with a name.

A CNAME target is a name, not an IP address. Address resolution must eventually find an address record.

For this scenario, Kartly publishes an A record directly. An alias would be useful if several names needed to follow one target. It would also create another record to inspect during troubleshooting.

The record answers “where?”. It does not contain the product page. That distinction builds on the request lifecycle: finding an address comes before contacting the application.

Now we need a way to find the record without copying every domain’s records onto every phone.

The resolver follows the hierarchy

The client asks a recursive resolver to find the answer. The resolver does the lookup work on the client’s behalf.

An authoritative nameserver serves the published records for a particular part of the namespace. A resolver’s cached copy is not the authority.^{1RFC 1034: Domain names - concepts and facilitiesPaul Mockapetris, RFC Editor, 1987}

Here is an empty-cache lookup in our fictional hierarchy:

1. The client asks its resolver for the A record of kartly.example.
2. The resolver asks a root server. It receives a referral towards the .example servers.
3. Those servers refer it towards Kartly’s authoritative nameservers.
4. Kartly’s authoritative server returns 192.0.2.10.
5. The resolver returns the answer to the client and caches it.

A referral points the resolver towards another nameserver; it is not the final address. The resolver follows these referrals rather than making the browser do so.^{1RFC 1034: Domain names - concepts and facilitiesPaul Mockapetris, RFC Editor, 1987}

For our scenario, these parts have distinct responsibilities:

This table describes our deployment model, not a requirement to run each role on one machine.

Kartly’s configuration write path is separate: an operator changes the record through its DNS provider. The authority then serves the updated record. Existing cached answers remain until their old lifetimes expire.

So a successful configuration change is not proof that every customer sees the new address.

Caching avoids repeating the lookup

Suppose the resolver already knows Kartly’s address. It can answer without repeating the hierarchy walk.

The record’s time to live, or TTL, gives a cache lifetime in seconds. A resolver may reuse the answer during that interval. Changing the source does not reset the lifetime of answers already cached elsewhere.

Consider this illustrative resolver entry:

Kartly publishes 198.51.100.20 at noon. Under these assumptions, this resolver can still answer with 192.0.2.10 at 12:30.

Another resolver first asks at 12:01. It receives the new address. Neither resolver needs to be broken for customers to see different answers.

Show the cost of a miss

Assume the following timings for one example lookup. These are not internet-wide latency estimates.

The example assumes no retries, aliases or cached referrals. Its lesson is the dependency chain: each uncached stage waits for the previous answer.

Caching reduces that work, but it also delays how quickly an address change becomes visible.

A shorter TTL buys faster change

Kartly now needs a policy, not just a record.

For this scenario, the team can keep both entry points working during a planned migration. It wants most standard cache lifetimes to clear within minutes after cutover.

TTL-based reuse and zero-TTL behavior are defined by DNS. Existing connections are a separate concern.

Count queries, not page views

Assume 1,000 independent resolver caches continuously need this one record. Each refreshes once per TTL interval. Ignore eviction, retries and additional record types.

Do not apply this formula directly to Kartly’s HTTP request rate. Many requests can reuse one cached address.

The team has chosen a shorter TTL. It still must apply that choice before the migration, not during the outage.

Change the address before retiring it

Return to the opening failure. Suppose Kartly lowered its TTL at noon and immediately removed the old entry point.

A resolver that cached the previous one-hour answer at 11:59 never received the new TTL. Its users can still be sent to the retired address until 12:59. Lowering the TTL now cannot shorten that existing entry.

For the scenario, use this sequence:

1. Prepare the new entry point. Confirm that it serves the same Kartly application.
2. Lower the old record’s TTL. Leave its address unchanged.
3. Wait out the previous TTL. Existing standard cache entries need time to expire.
4. Publish the new address. Keep the old entry point serving traffic.
5. Observe both entry points. Investigate continued old-address traffic before retiring it.

Waiting after lowering the TTL is the important ordering rule. Published migration procedures use this same sequence.

Do not treat TTL expiry as a promise that every connection moved. A long-lived connection can remain attached to its original endpoint.

For Kartly, DNS should locate the load balancer. Individual app-server replacement belongs behind that entry point, covered in Load balancers.

That boundary prevents an ordinary app-server restart from becoming a public DNS migration.

Diagnose the failure at its boundary

In this scenario, use two questions:

• Did the client obtain the expected address?
• After obtaining it, could the client reach Kartly?

A wrong address suggests inspecting records and caches. An expected address shifts the investigation towards the endpoint and connection path.

Also distinguish two DNS outcomes. NXDOMAIN means the queried name does not exist. A name can exist without having the requested record type. Those are different negative answers.^{2RFC 2308: Negative Caching of DNS Queries (DNS NCACHE)Mark Andrews, RFC Editor, 1998}

Negative answers can be cached too. Suppose a customer looks up sale.kartly.example before Kartly creates it. Publishing the record later does not necessarily clear that customer’s resolver’s cached nonexistence answer. This is negative caching.^{2RFC 2308: Negative Caching of DNS Queries (DNS NCACHE)Mark Andrews, RFC Editor, 1998}

For a launch, create the name before customers need it. Otherwise, the first failed visits can outlive the configuration mistake.

Try it yourself

Run this in a Bash-compatible shell against a public example site:

curl --silent --show-error --output /dev/null \
  --write-out 'lookup_seconds=%{time_namelookup}\n' \
  https://example.com/

Illustrative output:

lookup_seconds=0.018742

The value measures seconds from the start until name resolution completed. It does not measure the page’s download time.

Repeat it, but do not assume a faster second result proves a particular cache answered. This measurement alone cannot identify the cache layer. On a proxy-managed network, it may not represent direct resolution of the destination.

Where this shows up

• Design: a fast product catalog page: lookup time can precede the work that produces a fast page.
• Design: a URL shortener for millions of users: a stable public name must survive infrastructure changes.

DNS gives the client an address; HTTP and HTTPS explain the conversation that follows.

Common mistakes

Treating an edit as a global cache update. Plan for old and new answers to coexist until existing cache lifetimes end.

Using a CNAME as an address record. Its value must be another name, not the replacement IP address.

Calling every lookup failure “the name doesn’t exist”. A negative existence answer differs from a missing record type. Diagnose the actual outcome before changing records.^{2RFC 2308: Negative Caching of DNS Queries (DNS NCACHE)Mark Andrews, RFC Editor, 1998}

Check your understanding

Summary