Einführung
Willow Commons zieht seine Website auf eine neue Serveradresse um. Die Gemeinschaft muss weiterhin site.community.test verwenden können, und der ursprüngliche Standort muss während des Übergangs verfügbar bleiben. Beide Backends enthalten bereits ihre jeweiligen gültigen Veranstaltungsprogramme; Ihre Aufgabe ist die DNS-Migration, nicht eine Veröffentlichung von Inhalten.
Schließen Sie zuerst Verwendete Adresse eines Clients ermitteln ab. Diese unabhängige Umgebung beginnt erneut mit dem offiziellen Namen auf der alten Adresse, getrenntem autoritativem Server und Cache-Resolvern sowie vorbereiteten alten und neuen HTTP-Diensten. Ihre vorherige VM wird nicht wiederverwendet. Sie bereiten die TTL vor, ändern die Adresse und prüfen tatsächliche Clients und vollständige Inhalte. Planen Sie einschließlich Lesen und gewöhnlicher Fehler etwa 50 Minuten ein; dies ist eine Schätzung des Autors.
Dies ist eine kontrollierte lokale DNS-Übung. Sie verspricht weder weltweite Verbreitung noch unterbrechungsfreien Betrieb, einen Umzug bei einem öffentlichen Registrar oder die Erlaubnis, den alten Server sofort zu löschen.
Das Übergangsfenster vorbereiten
In diesem Schritt prüfen Sie den normalen Dienst und das neue Backend, bevor Sie die TTL des offiziellen Eintrags verkürzen. Beginnen Sie in Community Preview, wählen Sie Warm Client und lesen Sie die bestehende Willow-Commons-Seite mit der Kennzeichnung old location. Verwenden Sie Fresh Client erst nach dem Adresswechsel. Sein separater Resolver hat diese Website noch nicht abgefragt.
Wechseln Sie zu Warm Client. Befehle und curl-Optionen sind dieselben wie in der ersten Einheit. Fordern Sie zuerst den vorhandenen Dienst über seinen Namen an:
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/programme.txt
Sie sollten das vollständige Veranstaltungsprogramm von Service location: old erhalten. Prüfen Sie anschließend das vorbereitete neue Backend über seine Adresse mit demselben Pfad und Port:
curl --noproxy '*' -fsS --max-time 5 http://10.94.0.20:8081/programme.txt
Sie sollten dieselben drei Treffen und Eingangsinformationen mit Service location: new erhalten. Diese direkte Bereitschaftsprüfung umgeht DNS absichtlich; sie beweist nicht, dass ein Client bei Zugriff über den Namen migriert ist. Lassen Sie beide Websites unverändert.
Fragen Sie die aktuelle Kopie von Warm Client ab:
dig @127.0.0.1 site.community.test A +noall +answer
Sie sollten die alte Adresse mit einer TTL von höchstens 120 erhalten. Ist die vorbereitete Cachekopie während des Lesens abgelaufen, beschafft diese echte Anfrage eine weitere Kopie des weiterhin geltenden alten Eintrags. Es gibt keine ab dem Öffnen des Labs laufende Frist.
Wechseln Sie zu DNS Desk in /home/labex/project/site-move und lesen Sie die Eintragsdatei sowie den vorbereiteten Backendplan:
cat backends.tsv
cat community.zone
Als Migrationsänderungen sind nur A-Adresse und TTL von site sowie die notwendige SOA-Seriennummer erlaubt. practice ist für optionale wiederholbare Beobachtungen reserviert; keep, der Nameserver und sämtliche Website-Bytes müssen erhalten bleiben. Der vorbereitete alte Eintrag hat eine echte TTL von 120 Sekunden. Die Übung verwendet bewusst Sekunden; sie behauptet nicht, dass eine eintägige Cachelebensdauer aus einer Produktionsumgebung in zwei Minuten verschwindet.
Senken Sie vor dem Adresswechsel nur die TTL des offiziellen Eintrags. Dieses vollständige wörtliche Here-Dokument verwendet die in der ersten Einheit gelernte Schreibsyntax:
cat > community.zone <<'ZONE'
$TTL 120
@ IN SOA ns.community.test. admin.community.test. (2 60 30 3600 30)
@ IN NS ns.community.test.
ns IN A 10.94.0.2
site 45 IN A 10.94.0.10
practice 120 IN A 10.94.0.10
keep 120 IN A 10.94.0.10
ZONE
named-checkzone community.test community.zone
Sie sollten loaded serial 2 und OK sehen. Korrigieren Sie alle Syntaxprobleme vor dem Neuladen:
sudo /opt/labex/site-move/reload-zone
Bestätigen Sie den Zustand des laufenden autoritativen Servers, nicht nur die gespeicherte Datei:
sudo ip netns exec site-authority dig @10.94.0.2 site.community.test A +noall +answer
Sie sollten 45 IN A 10.94.0.10 erhalten. Das alte Backend ist weiterhin die autoritative Antwort. Wechseln Sie zu Warm Client:
dig @127.0.0.1 site.community.test A +noall +answer
Die alte Cachekopie behält ihre bisherige Restlebensdauer. Eine verbleibende TTL von 40 ist kein Beweis dafür, dass die neue 45-Sekunden-Regel übernommen wurde: Auch eine alte 120-Sekunden-Kopie kann noch 40 Sekunden übrig haben.
Warten Sie, bis die beobachtete alte Kopie abgelaufen ist, und fragen Sie erneut. Sie können die zuletzt angezeigten Restsekunden plus eine Sekunde warten. Der folgende vollständige konservative Befehl deckt das ursprüngliche Maximum von 120 Sekunden ab:
sleep 121
dig @127.0.0.1 site.community.test A +noall +answer
Sie sollten die alte Adresse mit einer neu erhaltenen TTL nahe 45 sehen. Diese letzte DNS-Anfrage ist wichtig: Das Ablaufen entfernt eine alte Kopie, beschafft aber nicht selbst deren Ersatz. Der native DNS-Austausch dokumentiert die alte Adresse mit verkürzter Lebensdauer. Die Prüfung liest diesen bereits vorhandenen Austausch vor eigenen Testanfragen und erledigt die Vorbereitung niemals für Sie.
Fehlt die Antwort oder enthält sie eine andere Adresse, lesen Sie vor dem Fortfahren erneut die genauen Ausgaben des autoritativen Servers und des Clients. Korrigieren Sie Dateifehler in DNS Desk, validieren und laden Sie neu und wiederholen Sie die Namensabfrage in Warm Client. Starten Sie keinen Resolver neu und leeren Sie ihn nicht. Führen Sie die Prüfung dieser Phase erst aus, wenn die alte Adresse tatsächlich mit verkürzter Lebensdauer beschafft wurde.
Die Adresse ändern und zwei Clients vergleichen
In diesem Schritt ziehen Sie den offiziellen Namen um und vergleichen unabhängige Clients. Lesen Sie den Schritt vor Beginn der kurzen Folge. Die nächste Warm-Abfrage zeigt das verbleibende Vergleichsfenster; ein Cachetreffer startet die TTL nicht neu. Nur eine nach natürlichem Ablaufen beschaffte neue Kopie beginnt eine neue Lebensdauer von 45 Sekunden, unabhängig von der Umgebungseinrichtung. Langsames Bearbeiten kann den sichtbaren Unterschied verpassen; die Migration bleibt gültig, und die Wiederholung mit einem separaten Übungsnamen unten ermöglicht eine erneute Beobachtung.
Aktualisieren Sie in Warm Client Ihre aktuelle Sicht:
dig @127.0.0.1 site.community.test A +noall +answer
Ist die Rest-TTL fast aufgebraucht, lassen Sie sie vor der Änderung ablaufen und fragen Sie erneut, während der autoritative Server noch die alte Adresse liefert. Wechseln Sie dann zu DNS Desk. Ändern Sie die offizielle A-Adresse, behalten Sie die TTL von 45 Sekunden bei und erhöhen Sie die Seriennummer:
cat > community.zone <<'ZONE'
$TTL 120
@ IN SOA ns.community.test. admin.community.test. (3 60 30 3600 30)
@ IN NS ns.community.test.
ns IN A 10.94.0.2
site 45 IN A 10.94.0.20
practice 120 IN A 10.94.0.10
keep 120 IN A 10.94.0.10
ZONE
named-checkzone community.test community.zone
sudo /opt/labex/site-move/reload-zone
sudo ip netns exec site-authority dig @10.94.0.2 site.community.test A +noall +answer
Der laufende autoritative Server muss jetzt 45 IN A 10.94.0.20 liefern. Gibt er noch die alte Adresse zurück, stimmen gespeicherte Datei und geladene Daten nicht überein. Prüfen Sie Syntax und Ergebnis des Neuladens, bevor Sie einen Clientcache interpretieren.
Wechseln Sie zu Warm Client:
dig @127.0.0.1 site.community.test A +noall +answer
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/programme.txt
Während seiner verbleibenden Cachelebensdauer darf er weiterhin die alte Adresse verwenden und Service location: old liefern. Wechseln Sie zu Fresh Client, der in /home/labex/project/site-move/fresh mit einem eigenen Resolver startet:
dig @127.0.0.1 site.community.test A +noall +answer
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/programme.txt
Sie sollten die neue Adresse und das vollständige Veranstaltungsprogramm von Service location: new erhalten. Zwei Clients können während eines DNS-Übergangs denselben Namen verwenden und dennoch unterschiedliche gültige Backends erreichen. Sie sind unabhängige Linux-Client-Namensräume und Cacheprozesse in einer VM, keine zwei physischen Geräte oder unabhängigen VMs.
Wenn beide bereits new zeigen: Die Warm-Kopie ist vor dem Vergleich natürlich abgelaufen. Führen Sie die offizielle Migration fort; weder ein Screenshot noch ein historisches Überlappungsfenster ist zum Bestehen nötig. Verwenden Sie für eine Wiederholung ohne Rücknahme der Migration practice.community.test wie in der ersten Einheit. Lassen Sie in DNS Desk site auf der neuen Adresse, setzen Sie nur practice auf die alte Adresse und 120 Sekunden und erhöhen Sie die aktuelle Seriennummer mit nano community.zone (Ctrl+O, Enter, Ctrl+X). Validieren und laden Sie neu. Lassen Sie in Warm Client eine vorhandene Übungskopie ablaufen und fragen Sie anschließend practice ab, um ein neues Fenster zu beginnen. Ändern Sie nur practice auf die neue Adresse und 45 Sekunden mit einer weiteren höheren Seriennummer, validieren und laden Sie neu und vergleichen Sie practice über beide Clients. Der offizielle Eintrag site bleibt dabei durchgehend migriert. Beenden Sie die Übungsbeobachtung durch natürliches Ablaufen; leeren Sie niemals einen Cache und ersetzen Sie keine Website-Inhalte.
Haben Sie die offizielle Adresse vor Abschluss der TTL-Vorbereitung geändert, verwenden Sie den gelernten Bearbeitungsablauf, um nur site auf die alte Adresse und 45 Sekunden mit einer höheren Seriennummer zurückzusetzen. Validieren und laden Sie neu und lassen Sie die aktuelle Antwort von Warm Client ablaufen. Beschaffen Sie die alte Adresse mit kurzer TTL und schalten Sie anschließend mit einer weiteren höheren Seriennummer erneut um. Beide ursprünglichen Backends bleiben verfügbar. Diese begrenzte DNS-Rücknahme repariert daher die Reihenfolge, ohne Dienste zurückzusetzen oder Arbeit zu löschen. Das Endziel bleibt die neue offizielle Adresse. Führen Sie die Prüfung dieser Phase aus, nachdem Sie die Änderung auf dem laufenden autoritativen Server bestätigt haben.
Den neuen Zugriffspfad über DNS bestätigen
In diesem Schritt weisen Sie nach, dass die kontrollierten Clients neue Inhalte erreichen und der alte Dienst verfügbar bleibt. Beginnen Sie in Warm Client. Seine ursprüngliche Migrationskopie hält bei der erlaubten Regel höchstens 60 Sekunden; der gezeigte Ablauf verwendet 45. Prüfen Sie die verbleibende TTL:
dig @127.0.0.1 site.community.test A +noall +answer
Wird noch die alte Adresse angezeigt, warten Sie die Restsekunden plus eine und wiederholen Sie die Abfrage. Diese vollständige konservative Wartezeit deckt die maximal erlaubte kurze Lebensdauer ab:
sleep 61
dig @127.0.0.1 site.community.test A +noall +answer
Sie sollten 10.94.0.20 mit einer verbleibenden TTL von höchstens 45 für die gezeigte Regel erhalten. Eine korrekte Adresse reicht nicht: Fordern Sie die Startseite an und speichern Sie das vollständige Veranstaltungsprogramm über diesen Namen:
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/
curl --noproxy '*' -fsS --max-time 5 -o programme.txt http://site.community.test:8081/programme.txt
cat programme.txt
Sie sollten die tatsächliche Startseite mit new location und das Veranstaltungsprogramm mit Service location: new einschließlich aller drei Treffen und Eingangsinformationen erhalten. Ist DNS korrekt, aber der Inhalt falsch, untersuchen Sie tatsächlichen Backendpfad und Adresse. Die alte Website so zu verändern, dass sie wie die neue aussieht, liegt außerhalb des erlaubten Bereichs.
Wechseln Sie zu Fresh Client und speichern Sie dieselbe vollständige Ressource unabhängig:
dig @127.0.0.1 site.community.test A +noall +answer
curl --noproxy '*' -fsS --max-time 5 -o programme.txt http://site.community.test:8081/programme.txt
cat programme.txt
Sie sollten denselben Inhalt des neuen Standorts erhalten. Wechseln Sie zu Community Preview, gehen Sie nötigenfalls mit Browser-Back zur Auswahlseite zurück, wählen Sie jeden Client aus und aktualisieren Sie die tatsächliche Seite. Beide zeigen jetzt new location. Verwenden Sie Download the programme in jeder Ansicht und öffnen Sie den vollständigen Text. Diese Browseranfragen verwenden den ausgewählten Kursclient, unabhängig vom DNS des Computers, auf dem Ihr Browser läuft.
Lesen Sie oben die Kennzeichnung new location und den ursprünglichen Programmlink unter den drei Treffen. Jeder Client sollte diese echte Seite des neuen Backends anzeigen.
Kehren Sie zu Warm Client zurück, um die Erhaltungsanforderungen nachzuweisen. Fragen Sie das alte Backend direkt an:
curl --noproxy '*' -fsS --max-time 5 http://10.94.0.10:8081/programme.txt
Sie sollten das ursprüngliche Veranstaltungsprogramm des alten Standorts erhalten. Fragen Sie den nicht betroffenen Namen am autoritativen Server ab:
dig @10.94.0.2 keep.community.test A +noall +answer
Sie sollten unverändert 120 IN A 10.94.0.10 erhalten. Der alte Dienst gehört weiterhin zum Übergangsvertrag. Beenden Sie ihn nicht, weil zwei Clients migriert sind; diese Beobachtungen zeigen nicht, dass alle realen Clients aktualisiert wurden.
Enthält eine gespeicherte Datei noch einen früheren Standort, wiederholen Sie den gleichen Downloadbefehl im richtigen Clienttab, nachdem sich dessen tatsächliche DNS-Antwort geändert hat. Bei einem falschen Pfad helfen pwd und cd /home/labex/project/site-move/warm oder das entsprechende Verzeichnis fresh. Die Abschlussprüfungen lesen vorhandene DNS- und Neuladenachweise vor eigenen Anfragen. Wiederholtes Bewerten leert keine Caches und lädt den autoritativen Server nicht neu; normale Lesezugriffe können native Protokolle ergänzen.
Zusammenfassung
Sie haben das neue Backend geprüft, die TTL bei weiterhin autoritativer alter Adresse reduziert und einen echten Client diese Regel beschaffen lassen. Danach haben Sie die Adresse geändert, unabhängige Clients verglichen und nach natürlichem Ablaufen die vollständigen neuen Inhalte geprüft. Der ursprüngliche Name, das alte Backend und die nicht betroffenen Einträge bleiben verfügbar. Dies sind Beobachtungen kontrollierter Clients, keine Garantie weltweiter DNS-Verbreitung.
