Nach einem Umzug taucht immer wieder die alte Website auf. Bevor Sie weiter warten, finden Sie heraus, welches der drei es ist: die Änderung ist nicht verbreitet, etwas Lokales cacht, oder der Eintrag, den Sie bearbeitet haben, ist nicht der benutzte.

Den autoritativen Server direkt fragen

dig +short yourdomain.com @8.8.8.8
dig +short yourdomain.com @ns1.yourprovider.com    # the authority itself

Liefert die Autorität schon die neue IP, ist die Änderung durch und alles Weitere ist Caching. Liefert sie die alte, wurde der Eintrag nicht gespeichert - oder bei einem Anbieter gespeichert, der Ihr DNS gar nicht mehr betreibt.

Welche Nameserver tatsächlich zuständig sind

dig +short NS yourdomain.com
whois yourdomain.com | grep -i "name server"
Das ist der Fehler, an den Leute einen Tag verlieren: Die Zone wurde beim alten Hoster bearbeitet, während der Registrar die Domain auf einen anderen Anbieter zeigen lässt. Der Eintrag ist tadellos, und niemand liest ihn.

Wenn es Caching ist

# your own machine
sudo systemd-resolve --flush-caches || sudo resolvectl flush-caches
# then check what the TTL was
dig yourdomain.com | grep -A1 "ANSWER SECTION"

Die TTL sagt, wie lange Resolver die alte Antwort behalten sollten. Eine TTL von 86400 heißt bis zu einem Tag, und nichts, was Sie tun, beschleunigt das für jemand anderen. Senken Sie die TTL einen Tag VOR einem geplanten Umzug auf 300.

Und die vergessenen Einträge

  • www zusätzlich zur nackten Domain.
  • Der AAAA-Eintrag, falls es IPv6 gibt - siehe IPv6 auf einem VPS.
  • Ein CNAME, der noch auf den alten Host zeigt.
  • Ein CDN, das unabhängig vom DNS seine eigene Vorstellung von Ihrem Ursprung hat.
Testen Sie den neuen Server, bevor Sie irgendetwas umziehen, mit einem hosts-Eintrag auf Ihrem eigenen Rechner. Dann ist die DNS-Änderung der letzte Schritt und nicht das Experiment - siehe umziehen ohne Ausfallzeit.