How does DNS work? How a phone finds the right server

On Saturday morning, Meera Kulkarni moves SeatJaldi, app and seat database together, to a new ₹1,200-a-month server. She types the new address into her control panel and sees “Saved”. She switches the old ₹1,200 server off. On her laptop, the app works.

Then her phone rings. “The app is down,” one member says. Another booked a ₹299 seat a minute earlier. Out of 100 club members, some could book and some could not.

Arjun Nair stares at the panel. “But it says Saved!” For about an hour, many phones keep knocking on the old, switched-off address. Why?

DNS turns a name like seatjaldi.in into a server address by asking a chain of servers, then remembers the answer for a set time.

Your phone has its own Ramulu. It does not find the number itself; it asks a helper, usually run by your mobile or Wi-Fi company.

Like Ramulu, the resolver does not remember forever. Each answer comes with a timer, counted in seconds.

The one idea to keep: names are looked up once and then remembered for a while, and “a while” is the TTL.

• Look up once: the resolver asks the chain of servers for the address.
• Remember for a while: it keeps the answer for the TTL, counting down.
• Change slowly: a new address reaches a resolver only after its old copy runs out.

• A new website pauses the first time, then opens instantly. Only the first visit did the whole look-up.
• A friend’s new site “cannot be reached” for you, then works an hour later. Your resolver asked before the site was ready, and remembered “no such name”.
• A company moves its website, and some people see the old site for hours. Their resolvers still hold the old answer.

The phone asks its resolver, and the resolver asks the root server, then the .in server, then SeatJaldi’s name server, which gives the address.

So DNS is not one big server. It is a chain, asked one link at a time, like Ramulu going from office to desk.

So the first look-up asked four servers, and the second asked only the resolver, like Ramulu answering at the gate. Real resolvers often remember the .in step too.

The TTL is a countdown on every stored answer, so a change can take up to one full TTL to reach everyone. And no, not everyone sees it at once: each resolver’s clock started when it last asked.

The resolver’s memory is a cache, and so is Ramulu’s. If Ayesha moves flats, Ramulu sends visitors to Flat 304 until his memory runs out.

Resolvers also remember “no such name”, for a time the name’s owner sets. If Ramulu has told a visitor “no Ayesha here”, he keeps saying it for a while after she moves in.

Meera clicked Saved at 10:00. That changed the record on SeatJaldi’s name server, but the TTL was 3600 seconds. One member’s resolver had asked at 9:58, so it kept the old address until 10:58.

Another had asked at 9:15, so its copy ran out at 10:15 and it got the new address. Meera’s laptop worked because its resolver had no copy, so it asked fresh.

Pick a TTL by how fast you may need to change, and lower it ahead of any planned move. Short means faster change and more look-ups. Long means fewer look-ups, slower change, and stored answers that keep working longer if your name servers fail.

A good society tells Ramulu a day early, “Trust your memory for five minutes only.” Then Ayesha moves.

What just happened? The TTL dropped a day before the address changed, so the move took five minutes at most.

Even then, keep the old server on until its traffic stops. Open connections, and apps that keep their own copy of the address, can outlast the TTL. If it still holds any bookings, have it forward each new request to the new server, so every booking lands in one place.

DNS is also something your app quietly depends on, because your app finds its database by name too.

If the database endpoint’s look-up fails, the database looks gone. In October 2025, a large cloud provider’s outage began when its own automation left a database’s DNS record with no address in it. The record was fixed in under three hours, but the knock-on failures took about fourteen and a half hours to clear.

So check your important names often, and know what your app does when a look-up fails.

1. 1

   Run the look-up

   Open a terminal (Command Prompt on Windows) and run nslookup -debug example.com, a name kept for examples. Find the line example.com, type = A, and write down the ttl under ANSWERS below it: the TTL in seconds.

2. 2

   Run it again

   Run it three more times and write down each ttl.

3. 3

   Work out the worst case

   If the owner changed the address now, a resolver could keep the old one for at least the biggest ttl you saw.

4. 4

   Check your answer

   You are right if your worst case is that biggest ttl, not zero. The numbers can drop, stay put or jump, because a fresh copy was fetched or another resolver machine answered.

So that is how a phone that knew only seatjaldi.in found the server’s address. Meera’s one-hour wait was a watchman with a one-hour memory.

Next time she will lower the TTL to 300 seconds a day early, move, and keep the old server on until its traffic stops. The worst wait drops to about five minutes, and afterwards she raises the TTL back to 3600.

Arjun nods, then frowns. “The phone has the address now. But the app and the server only work if both sides agree on what the app may ask and what each answer means. Where is that agreement written down?”