DNS (Domain Name System) is the system that translates a domain name such as zds.es into the data a browser needs to connect, above all the server's IP address. It is based on RFC 1034 and RFC 1035, published in November 1987.
DNS translates domain names into IP addresses. Where it touches SEO: Search Console verification, site moves, TTFB and CDNs.
What DNS means
People remember names; machines connect to IP addresses. DNS links the two. RFC 1034 describes it as a tree-shaped name space: each dot in a domain marks a level, and each level can delegate to its own name servers. The data is therefore spread across many servers, each responsible for its own part.
The information is stored in records. An A record points a name to an IP address. A CNAME makes one name an alias of another. A TXT record holds text, and RFC 1035 leaves its meaning open: it depends on the domain where it is found. NS records name the servers that answer for a zone, and the SOA record holds that zone's management data.
Every record also carries a TTL (time to live). According to RFC 1035, this is how long it may be cached before the source should be consulted again. That number explains what happens when a record is changed.
The domain is the name you register, the IP address is the destination, and the server is the machine that delivers the website. DNS connects the three, and it is hosted by the registrar or by a DNS provider.
How it works
When someone types a domain into a browser, the device asks a resolver, usually the one run by the internet provider or a public one. If the resolver has the answer cached and the TTL has not expired, it replies at once. If not, it queries name servers down the tree until it reaches the domain's authoritative server, which gives the definitive answer. The resolver stores that answer for the length of the TTL and reuses it for later queries.
This mechanism is behind what people call "propagation". A DNS change takes effect immediately on the authoritative server, but resolvers that already hold the old answer keep serving it until their TTL runs out. With a TTL of 24 hours, some visitors can still reach the old server up to a day later.
The CNAME has a rule of its own. RFC 1034 states that if a name has a CNAME, no other data should be present. This is the usual way to connect a CDN: the site's www name becomes an alias of a name at the provider, and the provider decides which server handles each visit. The root name of a domain always carries the zone's NS and SOA records, so under the same rule it should not also be a CNAME.
Why it matters
For SEO, DNS comes up at specific, documented points.
The first is Search Console. A Domain property, which combines data for http, https and every subdomain, can only be verified through DNS, with a TXT or CNAME record supplied by the tool. According to Google's help page, it can take up to two or three days for the provider to start serving a manually added record. Verification lasts as long as Google can find the record: Search Console checks it periodically, notifies you if it disappears and, after a grace period, removes the permissions.
The second is a hosting change without URL changes. In Google's guide, last updated on 10 December 2025, the move itself is the change to the DNS records so that they point to the new infrastructure. Google recommends lowering the TTL to a conservative low value, for example a few hours, at least a week in advance. It also asks you to check that firewall or denial-of-service protection does not stop Googlebot reaching the DNS or the servers, and to shut down the old hosting only once its traffic has reached zero.
The third is a change of domain. Google recommends permanent redirects from the old domain to the new one and keeping them, generally, for at least a year. A redirect only works while the old domain still resolves, so its DNS records and its registration have to stay active for that whole period.
The fourth is speed. According to the web.dev article on TTFB, last updated on 18 November 2025, time to first byte is the sum of redirect time, service worker startup, the DNS lookup, connection and TLS negotiation, and the request. web.dev treats a TTFB of 0.8 seconds or less as good. TTFB comes before every other loading metric, although web.dev does not count it among the Core Web Vitals.
Path of a lookupWhere SEO comes in
DNS lookup · one of the phases that make up TTFB
1BrowserSomeone types a domain and the device asks a resolver.
2ResolverIf it has the answer cached and the TTL has not expired, it replies at once. If not, it stores the new answer for the length of the TTL.
Hosting changeLower the TTL to a few hours at least a week in advance. Resolvers keep serving the old answer until their TTL runs out.
3Name serversThe resolver queries them down the tree.
Hosting changeCheck that the firewall does not stop Googlebot reaching the DNS.
4Authoritative serverGives the definitive answer with the domain's records: A for the IP address, CNAME for an alias, TXT for text.
Search ConsoleThe TXT or CNAME verification record has to stay: Search Console checks it periodically.Change of domainA redirect only works while the old domain still resolves. Google recommends keeping redirects, generally, for at least a year.
5ServerDelivers the website at the IP address from the answer.
CDNConnected through a CNAME, normally on www rather than on the root domain.Hosting changeShut down the old server only once its traffic has reached zero.
Five stops in a lookup, and the ones where SEO comes in.
Best practices
Lower the TTL of your records to a few hours at least a week before changing hosting.
Keep the Search Console TXT verification record for as long as the property is in use.
After a domain change, keep the old domain and its records for as long as the redirects run.
Use several public DNS checking tools to confirm that resolvers in different countries see the new records.
Check that the firewall does not block Googlebot at the DNS or at the servers.
Record which provider hosts the DNS and who has access.
Common mistakes
Deleting the Search Console TXT record while tidying up the DNS zone.
Changing records without lowering the TTL first and expecting the change to reach everyone at once.
Shutting down the old server as soon as the DNS is switched, while it still receives traffic.
Letting the old domain expire while its redirects are still passing signals to the new one.
Putting a CNAME on a name that already has other records, such as the root domain.
Blaming a high TTFB on the server alone without checking how long the DNS lookup takes.
Manuel Riveiro RodriguezCEO & Digital Strategist
A technical audit covers this and everything else in one pass.
Indirectly, at points Google documents. The DNS lookup is part of TTFB. A DNS change is the step that moves a site to new hosting. If a firewall stops Googlebot reaching the DNS, it cannot crawl. And a Search Console Domain property can only be verified with a DNS record.
Why does Search Console ask for a TXT record?
Because it is how you prove that you control the whole domain. A Domain property covers http, https and every subdomain, and Google only verifies it through DNS, with a TXT or CNAME record. The record has to stay in place: Search Console checks it periodically and removes permissions if it disappears.
What TTL should I use before a migration?
For a hosting change, Google recommends lowering the TTL to a conservative value, for example a few hours, at least a week before the move. When you then change the record, resolvers drop the old answer within hours rather than after a day or two. Once the move is complete, you can raise the TTL again.
How long does a DNS change take to propagate?
Mainly as long as the old record's TTL, because resolvers keep using the cached answer until it expires. A new record, such as the one for Search Console verification, can take up to two or three days before the provider serves it, according to Google's help page. Public DNS checking tools show the current state.
What does DNS have to do with a CDN?
A CDN is usually connected through a CNAME record: the site's name becomes an alias of a name at the provider, which decides which server handles each visit. Under RFC 1034, a name with a CNAME should have no other records, which is why this connection is normally made on www rather than on the root domain.
