Was ist DNS?

Menschen merken sich Namen, Maschinen verbinden sich mit IP-Adressen. DNS verbindet beides. RFC 1034 beschreibt es als baumförmigen Namensraum: Jeder Punkt in einer Domain markiert eine Ebene, und jede Ebene kann an eigene Nameserver delegieren. So verteilen sich die Daten auf viele Server, von denen jeder für seinen Teil zuständig ist.

Gespeichert werden die Informationen in Einträgen. Ein A-Eintrag verweist einen Namen auf eine IP-Adresse. Ein CNAME macht einen Namen zum Alias eines anderen. Ein TXT-Eintrag enthält Text, und RFC 1035 lässt dessen Bedeutung offen: Sie hängt von der Domain ab, in der er steht. NS-Einträge nennen die Server, die für eine Zone antworten, und der SOA-Eintrag enthält die Verwaltungsdaten dieser Zone.

Jeder Eintrag hat außerdem eine TTL (Time to Live). Laut RFC 1035 ist das die Zeit, die er im Cache bleiben darf, bevor die Quelle erneut gefragt wird. Diese Zahl erklärt, was passiert, wenn man einen Eintrag ändert.

Die Domain ist der Name, den man registriert, die IP-Adresse ist das Ziel, und der Server ist die Maschine, die die Website ausliefert. DNS verbindet die drei, betrieben vom Registrar oder von einem DNS-Anbieter.

Wenn jemand eine Domain in den Browser eingibt, fragt das Gerät einen Resolver, meist den des Internetanbieters oder einen öffentlichen. Hat der Resolver die Antwort im Cache und ist die TTL nicht abgelaufen, antwortet er sofort. Andernfalls fragt er die Nameserver entlang des Baums ab, bis er beim autoritativen Server der Domain ankommt, der die verbindliche Antwort gibt. Der Resolver speichert sie für die Dauer der TTL und nutzt sie für weitere Anfragen.

Aus diesem Mechanismus entsteht die sogenannte „Propagation“. Eine DNS-Änderung gilt auf dem autoritativen Server sofort, aber Resolver, die die alte Antwort schon gespeichert haben, liefern sie weiter aus, bis ihre TTL abläuft. Bei einer TTL von 24 Stunden kann ein Teil der Besucher noch bis zu einen Tag lang beim alten Server landen.

Für den CNAME gilt eine eigene Regel. RFC 1034 legt fest, dass ein Name mit CNAME keine anderen Daten haben soll. Auf diesem Weg wird ein CDN üblicherweise angebunden: Der www-Name der Website wird zum Alias eines Namens beim Anbieter, und der Anbieter entscheidet, von welchem Server jeder Besuch bedient wird. Der Stammname der Domain trägt immer die NS- und SOA-Einträge der Zone und sollte deshalb nach derselben Regel nicht zugleich ein CNAME sein.

Für SEO taucht DNS an konkreten, dokumentierten Stellen auf.

Die erste ist die Search Console. Eine Domain-Property, die die Daten von http, https und allen Subdomains zusammenfasst, lässt sich nur per DNS verifizieren, mit einem TXT- oder CNAME-Eintrag, den das Tool vorgibt. Laut Google-Hilfe kann es bis zu zwei oder drei Tage dauern, bis der Anbieter einen manuell angelegten Eintrag ausliefert. Die Verifizierung hält, solange Google den Eintrag findet: Die Search Console prüft ihn regelmäßig, meldet, wenn er fehlt, und entzieht nach einer Kulanzfrist die Berechtigungen.

Die zweite ist der Hosting-Wechsel ohne URL-Änderung. Im Google-Leitfaden, aktualisiert am 10. Dezember 2025, ist der eigentliche Umzug die Änderung der DNS-Einträge, damit sie auf die neue Infrastruktur zeigen. Google empfiehlt, die TTL mindestens eine Woche vorher auf einen vorsichtig niedrigen Wert zu senken, etwa einige Stunden. Außerdem soll man prüfen, dass Firewall oder DoS-Schutz Googlebot nicht den Zugang zum DNS oder zu den Servern versperren, und das alte Hosting erst abschalten, wenn dort kein Traffic mehr ankommt.

Die dritte ist der Domainwechsel. Google empfiehlt permanente Weiterleitungen von der alten auf die neue Domain und rät, sie in der Regel mindestens ein Jahr zu behalten. Eine Weiterleitung funktioniert nur, solange die alte Domain auflöst. Ihre DNS-Einträge und ihre Registrierung müssen also die ganze Zeit aktiv bleiben.

Die vierte ist die Geschwindigkeit. Laut dem web.dev-Artikel zur TTFB, aktualisiert am 18. November 2025, setzt sich die Zeit bis zum ersten Byte aus Weiterleitungen, dem Start des Service Workers, der DNS-Abfrage, dem Verbindungsaufbau mit TLS und der Anfrage zusammen. Als gut gilt bei web.dev eine TTFB von 0,8 Sekunden oder weniger. Die TTFB ist kein Core Web Vital, geht aber allen anderen Lademetriken voraus.

• Die TTL der Einträge mindestens eine Woche vor einem Hosting-Wechsel auf einige Stunden senken.
• Den TXT-Eintrag zur Search-Console-Verifizierung behalten, solange die Property genutzt wird.
• Nach einem Domainwechsel die alte Domain und ihre Einträge behalten, solange die Weiterleitungen laufen.
• Mit mehreren öffentlichen DNS-Prüftools kontrollieren, ob Resolver in verschiedenen Ländern die neuen Einträge schon sehen.
• Prüfen, dass die Firewall Googlebot weder beim DNS noch bei den Servern blockiert.
• Festhalten, bei welchem Anbieter das DNS liegt und wer Zugriff hat.

• Den TXT-Eintrag der Search Console beim Aufräumen der DNS-Zone löschen.
• Einträge ändern, ohne vorher die TTL zu senken, und erwarten, dass die Änderung sofort überall ankommt.
• Den alten Server abschalten, sobald das DNS umgestellt ist, obwohl dort noch Traffic ankommt.
• Die alte Domain auslaufen lassen, während ihre Weiterleitungen noch Signale auf die neue übertragen.
• Einen CNAME auf einen Namen setzen, der schon andere Einträge hat, etwa auf die Stammdomain.
• Eine hohe TTFB allein dem Server zuschreiben, ohne die Dauer der DNS-Abfrage anzusehen.