Einführung
Willow Commons hat bereits eine funktionierende Gemeinschaftswebsite. Finden Sie vor dem Umzug heraus, welche Adresse ein Client tatsächlich verwendet. Ein gespeicherter DNS-Eintrag, eine Antwort im Cache und eine Website-Antwort beschreiben unterschiedliche Teile des Ablaufs.
Sie verwenden zuerst die normale Website, vergleichen einen echten autoritativen Server mit einem unabhängigen Cache-Resolver und ändern einen separaten Übungsnamen. Der von der Gemeinschaft verwendete Websitename bleibt in dieser Einheit unverändert. Zwei HTTP-Backends und DNS-Dienste sind in isolierten Linux-Netzwerk-Namensräumen vorbereitet, die denselben VM-Kernel verwenden.
Sie sollten Terminalbefehle eingeben, Pfade erkennen und zwischen Tabs wechseln können. Dieses Lab erklärt die verwendeten DNS-Befehle und kleinen Konfigurationsänderungen. Ein öffentliches Domainkonto oder BIND-Administrationskenntnisse sind nicht erforderlich. Planen Sie einschließlich Lesen und gewöhnlicher Fehler etwa 40 Minuten ein; dies ist eine Schätzung des Autors.
Die funktionierende Website über ihren Namen verwenden
In diesem Schritt lesen Sie die bestehende Gemeinschaftswebsite und speichern ihr tatsächliches Veranstaltungsprogramm. Beginnen Sie in Community Preview und wählen Sie Warm Client. Sie sollten die Willow-Commons-Seite, drei Treffen und die Kennzeichnung old location sehen. Wählen Sie Download the programme und öffnen Sie den heruntergeladenen Text. Die Standortkennzeichnung identifiziert das Backend; sie ist keine Erfolgsanimation.
Lesen Sie oben die Standortkennzeichnung und verwenden Sie anschließend Download the programme unter den drei Treffen. Die abgebildete Seite ist eine echte Antwort des ursprünglichen Backends.
Die Vorschau führt eine echte DNS-Abfrage und HTTP-Anfrage vom ausgewählten Kursclient aus. Ihre äußere Plattform-URL ist ein Browser-Gateway; sie bedeutet nicht, dass Ihr Computer das Kurs-DNS verwendet. Das Aktualisieren des Browsers sendet eine neue Anfrage, ohne den Resolver-Cache des Kurses zu leeren. Verwenden Sie Fresh Client zunächst nicht.
Wechseln Sie zum Terminal Warm Client. Es startet in /home/labex/project/site-move/warm mit eigenen Resolver-Einstellungen. pwd gibt das aktuelle Verzeichnis aus:
pwd
DNS, das Domain Name System, ordnet einem Namen eine Adresse zu. Ein A-Eintrag ordnet einem Namen eine IPv4-Adresse zu. HTTP verwendet anschließend diese Adresse und einen Port, um Inhalt anzufordern. Hier lautet der Name site.community.test; 8081 ist der HTTP-Port und kein DNS-Eintragswert. .test ist eine reservierte Testendung, keine öffentliche Gemeinschaftsdomain.
curl stellt eine HTTP-Anfrage. --noproxy '*' schließt für diese Anfrage sämtliche Proxys aus; die Anführungszeichen erhalten den Stern als wörtliches Zeichen. -f behandelt HTTP-Fehler als Fehlschläge, -s blendet die Fortschrittsanzeige aus und -S zeigt Fehler weiterhin an. --max-time 5 begrenzt die Anfrage auf fünf Sekunden:
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/
Sie sollten HTML mit Willow Commons und old location erhalten. Das Terminal zeigt Quelltext; der Browser stellt dieselbe Seite dar. Laden Sie jetzt die echte Textressource herunter. -o programme.txt speichert die Antwort im aktuellen Verzeichnis dieses Clients:
curl --noproxy '*' -fsS --max-time 5 -o programme.txt http://site.community.test:8081/programme.txt
cat gibt die gespeicherte Datei aus:
cat programme.txt
Sie sollten alle drei Treffen, die Informationen zum stufenlosen Eingang und Service location: old sehen. Eine vorhandene Datei oder ein HTTP-Status allein beweist nicht, dass der Inhalt korrekt ist.
Wenn curl Could not resolve host meldet, prüfen Sie die Schreibweise des Namens. Failed to connect bedeutet, dass keine HTTP-Verbindung aufgebaut wurde; das unterscheidet sich von HTTP 404, bei dem ein Server antwortete, der Pfad aber fehlte. Korrigieren Sie den Tippfehler und wiederholen Sie die angegebene URL. Ändern Sie weder das Plattform-DNS noch /etc/hosts oder eine Resolver-Datei des Kurses. Wenn Sie ein weiteres Terminal öffnen, verwenden Sie den tatsächlichen Tab Warm Client und führen Sie vor dem Speichern cd /home/labex/project/site-move/warm aus. Dateien und Arbeitsverzeichnisse gehören zu diesem Client; ein Browserdownload gehört zu Ihrem Browser.
Autoritativen Server und Cache vergleichen
In diesem Schritt unterscheiden Sie den Quelleintrag von einer vorübergehend zwischengespeicherten Kopie. Bleiben Sie in Warm Client. Der autoritative Server verwaltet community.test; seine Adresse ist 10.94.0.2. Der Cache-Resolver des Clients lauscht auf 127.0.0.1, der Loopback-Adresse innerhalb dieses Clients. Der andere Client hat einen eigenen Resolver und einen eigenen Cache.
dig stellt DNS eine Frage. @10.94.0.2 wählt den Server ausdrücklich aus. A fragt nach einer IPv4-Adresse. +noall blendet die üblichen dig-Abschnitte aus und +answer zeigt die Antwortzeilen:
dig @10.94.0.2 site.community.test A +noall +answer
Sie sollten eine Zeile dieser Form erhalten:
site.community.test. 120 IN A 10.94.0.10
Die Spalten sind Name, TTL, Klasse, Typ und Adresse. TTL, Time to Live, ist die Anzahl der Sekunden, die eine Antwort im Cache bleiben darf. IN bezeichnet die Internetklasse. Der abschließende Punkt kennzeichnet einen vollständigen DNS-Namen. Leerzeichen und Tabulatoren können abweichen.
Fragen Sie stattdessen den Resolver des Kursclients:
dig @127.0.0.1 site.community.test A +noall +answer
Die Adresse sollte weiterhin 10.94.0.10 sein, der TTL-Wert kann aber niedriger sein, weil die vorherige Anfrage den Cache gefüllt hat. sleep 5 wartet fünf echte Sekunden, ohne DNS zu verändern:
sleep 5
dig @127.0.0.1 site.community.test A +noall +answer
Normalerweise nimmt die verbleibende TTL ab. Ist die vorherige Kopie abgelaufen, fragt der Resolver erneut den autoritativen Server und die TTL steigt wieder in Richtung 120. Das Lesen dieses Labs kann das gesamte Intervall verbrauchen. Das ist ein normales Ablaufen, kein defekter Cache. Ein Beobachtungsfenster unmittelbar nach der Einrichtung ist nicht erforderlich.
Verwenden Sie für die kommende Änderung einen separaten Namen. Er zeigt auf dasselbe alte Backend, ist aber nicht der offizielle Name der Gemeinschaftswebsite:
dig @127.0.0.1 practice.community.test A +noall +answer
Behalten Sie Name, Adresse und verbleibende TTL im Blick. Eine erfolgreiche Namensabfrage beweist nicht, dass die Website erreichbar ist; Schritt 1 hat dafür eine gesonderte HTTP-Anfrage gestellt. Führen Sie die Prüfung dieses Schritts aus und lesen Sie danach den nächsten Schritt, bevor Sie dessen kurze Änderungs- und Vergleichsfolge beginnen.
Übungseintrag ändern und den Cacheeintrag ablaufen lassen
In diesem Schritt validieren Sie eine kleine Eintragsänderung, laden sie in den autoritativen Server und sehen, warum eine niedrigere TTL eine bereits gespeicherte Kopie nicht verkürzt. Sie dürfen nur practice und die erforderliche SOA-Seriennummer in community.zone ändern. Bewahren Sie den offiziellen Eintrag site, keep, den Nameserver und beide Websites unverändert.
Lesen Sie zuerst die folgenden Bearbeitungshinweise. Fragen Sie dann in Warm Client den Übungsnamen unmittelbar vor dem Tabwechsel erneut ab:
dig @127.0.0.1 practice.community.test A +noall +answer
Wenn nur wenige Sekunden verbleiben, warten Sie dieses Intervall ab und fragen Sie erneut, während der autoritative Server noch den ursprünglichen Eintrag bereitstellt. Dadurch erneuert eine echte DNS-Abfrage das Beobachtungsfenster; der Cache wird nicht geleert. Eine neue Kopie hält bis zu 120 Sekunden. Arbeiten Sie in Ihrem Tempo und verwenden Sie den Wiederherstellungsabsatz, falls Sie das Fenster verpassen.
Wechseln Sie zu DNS Desk mit dem Verzeichnis /home/labex/project/site-move. Lesen Sie die Datei:
cat community.zone
Eine Zone ist der autoritative Datenbestand für einen Teil des DNS. $TTL 120 gibt eine Standardlebensdauer vor. practice 120 IN A 10.94.0.10 legt für den Übungsnamen ausdrücklich Lebensdauer und Adresse fest. SOA, Start of Authority, enthält eine Versionsnummer, den Serial. Erhöhen Sie diese Zahl beim Veröffentlichen einer Änderung und erhalten Sie die übrigen SOA-Werte. DNS-Lebensdauern und SOA-Zeitgeber erfüllen unterschiedliche Aufgaben. Hier steht @ für den Zonenursprung community.test.. NS benennt den autoritativen Server und der A-Eintrag ns liefert dessen Adresse. Klammern fassen die SOA-Felder zu einem Eintrag zusammen. Die vorhandenen Werte für Aktualisierung, Wiederholung, Ablauf und negatives Caching gehören zur Zonenverwaltung; lassen Sie sie unverändert. Sie sind nicht die TTL des Übungs-A-Eintrags.
Das folgende Here-Dokument schreibt die gesamte kleine Zone. > ersetzt die Datei. Das zitierte 'ZONE' erhält $TTL wörtlich, anstatt es als Shellvariable zu expandieren. Das letzte ZONE muss am Zeilenanfang stehen. Kopieren Sie den gesamten Block:
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 120 IN A 10.94.0.10
practice 45 IN A 10.94.0.20
keep 120 IN A 10.94.0.10
ZONE
Nur Adresse und Lebensdauer des Übungseintrags sowie die Seriennummer wurden geändert. named-checkzone validiert die gesamte gespeicherte Zone, ohne sie zu laden. Das erste Argument ist der Zonenname, das zweite die Datei:
named-checkzone community.test community.zone
Sie sollten loaded serial 2 und anschließend OK sehen. Dies ist ein Ergebnis der Dateivalidierung, kein Beweis dafür, dass der laufende Server die Datei geladen hat. Bei einem Syntaxfehler lesen Sie die Datei, stellen den vollständigen Block wieder her und prüfen erneut. Eine fehlerhafte gespeicherte Datei lässt die bisherige laufende Zone verfügbar, bis eine gültige Version neu geladen wird.
sudo führt diesen einzelnen Verwaltungsbefehl aus. Das bereitgestellte, eng begrenzte Hilfsprogramm ruft BINDs echtes rndc reload community.test innerhalb des autoritativen Kursservers auf; es startet keinen der Caches neu:
sudo /opt/labex/site-move/reload-zone
Sie sollten zone reload queued erhalten. Fragen Sie den laufenden autoritativen Server ab, um die tatsächlich geladenen Daten zu bestätigen. Der Arbeitsplatz hat keinen voreingestellten Kursresolver; diese Diagnose wechselt deshalb ausdrücklich in den Netzwerk-Namensraum des autoritativen Servers. ip netns exec site-authority führt nur den folgenden Befehl in diesem Kursnetz aus:
sudo ip netns exec site-authority dig @10.94.0.2 practice.community.test A +noall +answer
Sie sollten 45 IN A 10.94.0.20 erhalten. Wechseln Sie zu Warm Client und fragen Sie dessen Cache ab:
dig @127.0.0.1 practice.community.test A +noall +answer
Während der verbleibenden ursprünglichen Lebensdauer kann er weiterhin 10.94.0.10 liefern, sogar mit mehr als 45 verbleibenden Sekunden. Die neue TTL von 45 Sekunden gilt für neue Kopien; sie schreibt die alte gespeicherte Antwort nicht um. Beide Backends funktionieren weiter, während die Clients berechtigterweise unterschiedliche Ergebnisse erhalten können.
Warten Sie die gerade beobachtete verbleibende TTL plus eine Sekunde und fragen Sie erneut. Wurden beispielsweise 37 Sekunden angezeigt, genügt sleep 38 für diese Kopie. Die folgende konservative Wartezeit deckt das ursprüngliche Maximum von 120 Sekunden vollständig ab, selbst wenn Sie den genauen Wert nicht notiert haben:
sleep 121
dig @127.0.0.1 practice.community.test A +noall +answer
Jetzt sollten Sie 10.94.0.20 und eine verbleibende TTL von höchstens 45 erhalten. Lesen Sie die tatsächliche Zeile; ein abgelaufener Zeitgeber allein beweist nichts. Stellen Sie vom selben Client eine HTTP-Anfrage über den Namen:
curl --noproxy '*' -fsS --max-time 5 http://practice.community.test:8081/programme.txt
Sie sollten Service location: new mit dem vollständigen Veranstaltungsprogramm erhalten. Der offizielle Name site.community.test liefert weiterhin den alten Standort.
Wenn Sie den Unterschied verpasst haben: Das fertige Ergebnis bleibt gültig. Verwenden Sie für eine Wiederholung nur practice: Stellen Sie in DNS Desk dessen Zeile auf practice 120 IN A 10.94.0.10 zurück und erhöhen Sie die aktuelle SOA-Seriennummer mit nano community.zone. nano ist ein Texteditor: Bewegen Sie sich mit den Pfeiltasten, ändern Sie nur diese Zeile und die Seriennummer, drücken Sie Ctrl+O, Enter zum Speichern und Ctrl+X zum Beenden. Validieren und laden Sie mit denselben Befehlen wie oben neu. Warten Sie, bis die aktuell beobachtete TTL des Übungsclients natürlich abläuft, und fragen Sie ihn ab, um die alte Adresse mit bis zu 120 Sekunden zu erhalten. Ändern Sie dann nur practice wieder auf die neue Adresse und 45 Sekunden mit einer weiteren höheren Seriennummer. Validieren, laden und vergleichen Sie sofort. Beenden Sie mit natürlichem Ablaufen und einer echten Anfrage an die neue Website. Setzen Sie niemals die offizielle Website zurück, starten Sie keine Resolver neu und ersetzen Sie keinen Website-Inhalt, um ein Fenster zu wiederholen.
Bei einem falsch eingegebenen Pfad verwenden Sie in DNS Desk pwd und cd /home/labex/project/site-move, bevor Sie die Datei erneut lesen. Syntaxfehler und falscher Inhalt sind unterschiedliche Probleme: Validieren Sie die Datei, prüfen Sie den laufenden autoritativen Server, prüfen Sie den Cache und fordern Sie dann HTTP an. Führen Sie die abschließende Prüfung aus, sobald der Übungsclient die neue Adresse auflöst.
Zusammenfassung
Sie haben eine funktionierende Website über ihren Namen verwendet, ihr vollständiges Veranstaltungsprogramm gespeichert und autoritative Daten, gespeicherte DNS-Antworten und HTTP-Inhalte unterschieden. Sie haben eine begrenzte Übungsänderung validiert und gesehen, dass eine niedrigere TTL eine vorhandene Cachekopie nicht verkürzt. Die offizielle Gemeinschaftswebsite und das alte Backend bleiben verfügbar. Die nächste Einheit wendet dieses Wissen auf eine schrittweise Adressmigration an.
