What DNS is
DNS is the address book of the internet: it takes a domain name like rgb.ir and returns the numeric address of the server the browser has to connect to. What an ordinary address book does not do is cache the answer at every point along the way, and that caching is the main reason a record change is not instant.
- Lesson 4 of 12
- Beginner
- Free, no signup
The path of one lookup, when the answer is not cached
-
1
The cache
browser, operating system and router each hold their own copy
-
2
The lookup server
the one that asks on your behalf and keeps the answer
-
3
A root server
does not know your domain, only who to ask about the extension
-
4
The extension server
for ir, the servers that say who holds this domain answers
-
5
The authoritative server
hands over the record itself and its lifetime
In practice most lookups never reach the second station, because the answer is already cached. This full path is the first time case.
Last checked: Facts and tool names in this lesson are re-checked against their sources on this date.
What does DNS actually do?
DNS translates a name into an address. You type rgb.ir, the browser wants a numeric address, and DNS provides it. Without that translation you would have to memorise the numeric address of every site, and more importantly, a site owner could never change servers without losing every visitor.
The address book comparison is right but it covers half the story. The address book is not one book; it is a tree that starts at the root, reaches the extension, and from there the servers that hold the answers for your domain. Nowhere is there a complete file of every name in the world.
The other half is the part the comparison never mentions: everyone along that path keeps the answer for a set period. Your browser, the operating system, the home router and your operator's lookup server all hold copies. That is why the answer to the question everybody asks, "why has my DNS change not taken effect yet", has nothing to do with whether the record is correct.
Let us drop one common misconception here too: DNS only gives directions and moves no data itself. Once you have the address, your connection is straight to the destination server and DNS is no longer on the path.
How does a name turn into an address?
In four questions, and in zero questions if the answer is already cached. First the lookup server checks its own memory. If it has nothing, it asks a root server which servers know the ir extension, then asks those who holds the answers for rgb.ir, and finally takes the record itself from that server.
The good thing about this is that it can be measured. Today, from this server, we asked a public lookup server for a completely new name under our own domain: the first time took 66 milliseconds and the second and third took 7. That difference is exactly what caching does.
And one detail shows the path better than any explanation: moments later we asked for another new name under the same domain, and its first time was 11 milliseconds, not 66. The lookup server no longer needed to start from the root; it simply did not remember the answer for that particular name. Memory fills separately at every step of this tree.
A useful consequence: the slowness of a foreign site opening for the first time is not always the destination server. Sometimes it is exactly these few round trips, and because it happens only once, a second test does not show it. If you have measured speed and got a better result on the second run, this is probably what you saw.
What is TTL, and why is a record change not instant?
TTL is a number sent with every record saying how many seconds the answer stays valid. Any lookup server that took the answer will not ask again until that period ends. So when you change a record, the world is behind you by the length of the old TTL, not by whatever the control panel shows.
The numbers are visible in this site's own zone, and today they were these: the A record has a lifetime of 300 seconds, that is five minutes. The MX record is 300 as well. The NS records at the authoritative server are 86400 seconds, that is a day, while the same domain is introduced one level higher with a lifetime of 900 seconds. The root servers introduce the ir extension with a lifetime of 172800 seconds, that is two days.
Draw one practical conclusion from that mismatch: changing an A record is fast and changing nameservers is slow. If you are only moving the server, five minutes; if you are moving the whole domain to another provider, count in hours.
And the trap that catches a lot of people is negative caching. If a name does not exist, that "does not exist" gets cached as well. Its lifetime is set by the SOA record and for our domain it is 1800 seconds, that is half an hour. So if you test a subdomain before you create it, it will still not be found for half an hour after you create it, and that behaviour is exactly what RFC 2308 defines. The rule is simple: do not test a record before you create it.
The ladder of lifetimes on our own domain
-
1
A record: 300 seconds
Five minutes. Moving the server is the fast change, and it happens here.
-
2
MX record: 300 seconds
The mail destination, on the same five minute lifetime.
-
3
A negative answer: 1800 seconds
Half an hour. Test a subdomain before creating it and this is your wait.
-
4
NS records: 86400 seconds
One day, at the authoritative server. One level higher the same domain is introduced with 900 seconds.
-
5
The ir extension at the root: 172800 seconds
Two days. The highest rung, the slowest one, and the one never in your hands.
These five numbers belong to the rgb.ir zone on 7 September 2026 and are nobody's default value. Your domain has different numbers; read yours.
Why does your email depend on DNS too?
Because the decision on whether your mail lands in the inbox or in spam is effectively taken inside these records. Three text records do that work and all three sit in the domain's DNS: SPF says which servers may send mail in your name, DKIM holds the cryptographic signature, and DMARC says what to do with mail that fails those two.
On this very domain, our SPF record is v=spf1 +mx +a ~all, the DKIM key is published under the name default._domainkey, and our DMARC policy is set to quarantine. Anyone can see these from outside, because a DNS record is public; it is the same thing the receiving server sees.
Here is where the mental model goes wrong: people assume that mail not arriving means a mail server problem. More often it is a record problem. And there is one limit that almost no tutorial mentions and that gets expensive later: SPF has a ceiling of ten DNS lookups, and if adding services pushes you past it the whole record becomes invalid. That ceiling is set by RFC 7208, not by your provider.
So before you add another mail service, count what the current record already costs. Breaking that ceiling once sends mail that arrived correctly yesterday into spam, and no error is shown in your panel at all.
Three text records that decide the fate of your mail
Must be there
- SPF: the list of servers allowed to send in your domain's name.
- DKIM: the public signing key the receiver uses to check the message is genuine.
- DMARC: the policy for mail that fails those two.
Where it breaks
- Going past the SPF ceiling of ten lookups, which invalidates the whole record.
- Two separate SPF records instead of one, which is an error in itself.
- Adding a new service without updating the record, then wondering about the spam folder.
Having all three records does not guarantee inbox delivery. The content of the mail, the history of the sending address and each receiver's policy all count too.
How do you look at a domain's records yourself?
The simplest route with nothing to install is our own free DNS check tool. It queries the A, AAAA, CNAME, NS, MX, TXT and SOA records live from our server and reports SPF and DMARC health separately. The lookup is real and is not copied from anywhere; its daily cap exists so that a script cannot turn our server into its own free tool.
If you have a terminal, dig on Linux and macOS does the same job more precisely, and nslookup on Windows has a simpler version of it. One habit separates the amateur from the professional: ask the domain's own authoritative server, not your local lookup server. The local one gives you a cached answer and the remaining lifetime; the authoritative one gives the record's real value.
We saw that same difference on our own domain today: the local server returned the NS records with a lifetime of 21600 seconds and the authoritative server returned the same records with 86400. Neither is wrong; the first is what is left of a countdown and the second is the original number.
And one thing worth doing after every change: ask from more than one place. Answers that do not match are not necessarily a fault; caches may simply not have emptied yet, or the destination service may deliberately give each asker a nearer address. To know what a domain is in the first place and who registered it, the article on what a domain is opens that layer.
The fast path, with AI
Moving a site without downtime used to be something people learned by breaking it once. Now the whole plan can be derived from your own real zone in a few minutes, provided you supply the real output and do not ask the model to guess the values.
- Take the whole zone in one line: for t in A AAAA MX NS TXT SOA CAA; do dig +noall +answer $t example.com; done, with your own domain in place of the example.
- Paste that output untouched and say what you intend to change: only the server, or the nameservers as well. A fast cheap class of model is enough here; the work is arithmetic on data you brought yourself.
- Ask for a schedule rather than general advice: for every record that will change, how long before you must lower its lifetime and how long you then have to wait.
- Before executing, check two values with your own eyes: the current lifetime of the A record and that of the NS records. If the model writes a number that is not in your output, throw the whole answer away right there.
Copy-ready recipe
You are a DNS administrator. The text below is the raw record output of one domain, untouched.
{paste the dig output here}
The change I intend: {only the A record, or the nameservers, or both}
Preferred execution time: {hour and day}
Write only these:
1. The current lifetime of every record that will change, verbatim from this text.
2. How many minutes or hours before execution I must lower that lifetime, and to what value.
3. How long after the change I must wait to be sure every lookup server has the new answer, based on these same values.
4. A short list of what to check after the change, including the mail records.
Rule: write no number that is not in the text above. If a value is not in the text, say it was not in the output. Give no general advice; only the timetable for this domain.Before you trust the output: This plan is only as right as your output is fresh and taken from the authoritative server; local output shows the remaining lifetime, and planning from it makes you confident earlier than you should be. Keep the execution in your own hands as well: do not change the mail records on the same day you move the server, and do neither at an hour when traffic is high.
AI in this kind of work
A DNS record is text, and text is what a language model is good at. Paste the dig output and ask which record is missing, why SPF is not passing, or what this SOA value means; the answers are usually good. Our position on the other side is just as clear: do not let the model write a record that you then install without understanding it. A wrong record in DNS stays wrong for the length of its own lifetime, and mail is the one thing that breaks silently when it breaks.
Tools that actually help
- Claude Works well for reading dig output and comparing two zones against each other, for instance when you want to know what differs between the domain whose mail arrives and the one whose mail does not. Iran is not on Anthropic's supported countries list, so there is no official route to sign up or pay.
- Gemini Good for explaining DNS jargon and error messages in Persian. Google's own page says the Gemini app works in more than 230 countries and territories, and Iran is not on that list.
- Gemini Notebook The right use here is this: give it your own DNS provider's help page and ask your question from inside that document, because field names and limits differ in every panel. It runs on the same Google account, and Iran is not among the available regions.
Where it backfires
The specific risk here is a record that looks handsome and is wrong. The model knows the syntax of SPF, DKIM and DMARC, and in the same confident tone it will build a record that may cross the ten lookup ceiling, leave out a service that genuinely sends mail, or set the DMARC policy one notch stricter than you are ready for. That ceiling is set by RFC 7208, and the model does not count it while writing a record. Anthropic itself calls this confident invention hallucination in its documentation and writes about reducing it. Our rule: test the proposed record with a lookup tool before installing it, and after installing it send a real message and read its headers. And the thing you must never paste into a chat is your DNS provider's API key or your DKIM private key; Google's own help page also says plainly not to enter confidential information. For what paying for each of these tools looks like from Iran, see the buying guide.
Sources: RFC 7208: SPF, the ten lookup limit Anthropic: reduce hallucinations Anthropic: supported countries Google: Gemini Apps privacy and data Google: where Gemini Apps are available
Where this advice stops
Every value in this lesson belongs to our own zone on one specific day and is nobody's default; your domain may have an A record with a one hour lifetime, and then every calculation here doubles for you. The lookup times were taken from this server and from one public lookup server: from inside Iran and over mobile networks the numbers differ, and we cannot measure that from here. And most importantly, this lesson is about finding an address, not about reaching it; a name that correctly resolves to an address may still fail to open, and that problem sits elsewhere on the path.
From our own work
We took every number in this lesson from this server on the same day and the raw output is in this session's report, but the most interesting thing we saw was not a number. When we asked for our own domain's A record once from the local lookup server and once from our own authoritative server, we got two different sets of addresses. Neither was broken: the service sitting in front of our site deliberately gives each asker an address that is nearer to them. The lesson this holds for everyday work is that "I checked the record and it was right" is not a complete sentence until you say where you asked from, and that single ambiguity is why two people can argue for hours over one DNS change while both of them are telling the truth.
Real follow-up questions
Why does the site open for me after a DNS change but not for my colleague?
Because you and they ask two different lookup servers, and the memories of those two do not empty at the same moment. The old record's lifetime started at a different time for each of them. There is nothing to do but wait out the previous record's lifetime; clearing the cache on your own machine does not solve theirs.
Does switching my device's DNS to a public server make the internet faster?
It only speeds up that small part and nothing else. The difference we measured between a fresh lookup and a cached one was 59 milliseconds, and that once per name. Once the address is in hand, the rest of the site's speed depends on the path and the destination server, and neither changes when you switch lookup servers.
I created the record but it is still not found, where is the mistake?
If you tested it once before creating it, there is probably no mistake at all and it is simply negative caching: the answer "does not exist" was cached and stays until its lifetime ends, which for our domain is half an hour. To be sure, ask the same name directly from the domain's authoritative server; if it answers there, the record is fine and all you need is to wait.