Before Googlebot can send the first HTTP request to a URL, it has to resolve the domain name to an IP address, exactly like any browser. It's such a routine step that it's rarely thought of as part of technical SEO, but a poor DNS setup can introduce crawl errors, slow down every single request, or turn a well-planned migration into a string of intermittent failures lasting days.
How DNS fits into the crawl pipeline
DNS resolution is the first phase, even before establishing the TCP connection, of any request made by a crawler or a browser, as detailed in the full phase breakdown in the server speed and TTFB guide. If that resolution fails, the domain doesn't respond, the nameserver doesn't answer in time, or it returns an error, Googlebot logs it as a specific crawl error, distinct from a server error or a 404, precisely because it happens before there's even a connection to the origin server. Repeated, sustained DNS failures over time can lead Google to lower its crawl rate limit for the domain, just as it would with recurring 5xx errors, as explained in the crawling and indexing guide.
TTL: the setting that decides between propagation speed and query load
A DNS record's TTL (Time To Live) specifies, in seconds, how long a resolver, an ISP's, a browser's, Googlebot's, can reuse an already-obtained answer without querying the authoritative server again. It's a setting with a real trade-off, and there's no universally correct value.
A low TTL (300 seconds, for example) lets an IP change propagate fast, useful ahead of a server or hosting provider change, but it means resolvers query the authoritative server far more often, adding constant query load and, for uncached lookups, a small added latency cost paid on every fresh resolution. A high TTL (86,400 seconds, a day, or more) drastically reduces that load and makes better use of resolver caching, but it means any change to the record takes up to that full duration to reach every resolver that already had the previous answer cached.
What happens during a DNS migration or a nameserver change
The word "propagation" is misleading: there's no single moment when a DNS change syncs globally, only a period during which different resolvers in different parts of the world keep serving the previous answer until their cached copy expires, determined by the TTL the record had before the change, not the new TTL, which only applies from the point it's queried again. During that period, it's entirely possible for Googlebot to resolve the domain to the old IP while a real user, with a different resolver, already sees the new one, or the other way around.
The practice that avoids most problems is lowering the TTL of the affected record, to 300 seconds or less, several days before the migration, so that when the real change lands, the previous cached copy expires much faster across every resolver. Just as important: keep the old server running and responding correctly throughout the entire transition period, not shutting it down the moment the change happens, precisely because part of the traffic (both human and crawl) will keep arriving there for hours or days.
DNSSEC: what it adds and the misconfiguration that can take down an entire domain
DNSSEC adds a chain of cryptographic signatures to DNS responses, letting a resolver verify the response it received hasn't been tampered with by an intermediary, a DNS cache-poisoning attack, for example, which could redirect users and crawlers to a malicious server without the domain itself ever changing. It isn't, by itself, a ranking factor, but it protects against a real compromise vector that, if it does materialize, does carry serious SEO consequences, as explained in the compromised security and index recovery guide.
DNSSEC's real technical risk isn't in enabling it but in disabling or rotating it badly: if the signature chain breaks, a key rotated on the domain without updating the corresponding DS record at the registrar, for example, resolvers that validate DNSSEC, which are most of the major public resolvers, stop resolving the domain entirely for anyone relying on them. It's a failure that looks like the domain has disappeared, not like a simple server error, and it can go undetected for weeks if nobody specifically checks the state of the trust chain.
CDN and DNS: anycast, geo-routing and a server's perceived location
A modern CDN usually doesn't resolve the domain to a single fixed IP but uses anycast: the same IP address is announced simultaneously from multiple distinct physical locations via the BGP routing protocol, and it's the network infrastructure itself that steers each user or crawler toward the physically nearest node, without DNS having to return different IPs based on the location of whoever's asking. It's an additional layer on top of traditional DNS-based geo-routing, where the nameserver itself calculates and returns a different IP depending on the querying resolver's region, and it explains why, on a site served by a large CDN, the question of where the server is physically located stops having a single answer: it is, in practice, everywhere at once, and that's precisely what reduces perceived latency, and therefore TTFB, for geographically distributed audiences, as explained in the server speed and TTFB guide.
Frequently asked questions
How long does a DNS change actually take to "propagate"?
It depends exclusively on the TTL the record had before the change: it can be a matter of minutes with a low TTL, or up to 24-48 hours, the practical limit registrars usually cite, if the previous TTL was high or if some specific resolver ignores the declared TTL, something that happens occasionally but isn't the norm.
Is enabling DNSSEC mandatory?
It isn't mandatory, and most domains work perfectly fine without it, but once enabled it needs to be managed carefully, especially during key rotations, because a misconfiguration is more disruptive than never having enabled it at all.
Does the DNS provider affect SEO beyond just uptime?
Indirectly, yes: a DNS provider that's slow to resolve, even with a correctly configured record, adds latency to every first uncached resolution, and a provider with low availability produces exactly the "DNS not found" crawl errors described in this guide.
Should I always keep the TTL very low just in case?
It's neither necessary nor advisable to do so permanently: a constantly low TTL generates unnecessary query load with no benefit if there are no changes planned. The usual practice is keeping a moderate TTL, an hour, for example, and lowering it temporarily only in the days leading up to a planned change.
Can a DNS change affect users' cookies or session?
Not directly: DNS only resolves the name to an IP, it plays no part in cookie or session management, which depend on the server the browser ultimately connects to after resolution.