Erarbeiten Sie zuerst die Idee, und nutzen Sie dann die nächste Aktivität, um sie zu überprüfen.
Records, Resolver und die Reihenfolge der Lookups
Was ein Resolver tatsächlich konsultiert und in welcher Reihenfolge, welchen Recordtypen Sie begegnen werden, und warum ein Name auf einem Host aufgelöst werden kann und auf dem nächsten fehlschlägt.
Was Sie können werden
- Die gängigen Recordtypen benennen und was jeder beantwortet
- Einen Lookup durch Cache, Hosts-Datei und konfigurierten Resolver nachvollziehen
- Erklären, warum zwei Hosts sich über denselben Namen uneinig sein können
Zuvor: Sie benötigen "DNS - Namen statt Adressen" für die Grundidee, und die DHCP-Lektion, da der von einem Host genutzte Resolver meist über sein Lease ankommt.
Warum es wichtig ist: "Bei mir funktioniert es" ist fast immer eine DNS-Antwort, die sich zwischen zwei Hosts unterscheidet - ein zwischengespeicherter Record, ein Hosts-Datei-Eintrag oder ein anderer, von einem anderen Scope vergebener Resolver. Die Lookup-Reihenfolge zu kennen macht daraus statt eines Rätsels drei zu prüfende Dinge.
Ein Resolver fragt nicht sofort einen DNS-Server. Er geht eine kurze Liste von Quellen der Reihe nach durch und hält bei der ersten Antwort an. Fast jeder verwirrende DNS-Fehler ist eigentlich eine Unstimmigkeit darüber, welche dieser Quellen geantwortet hat.
Wichtige Recordtypen
| Typ | Antwort | Typische Verwendung |
|---|---|---|
| A | Name zu IPv4-Adresse | Die alltägliche Abfrage |
| AAAA | Name zu IPv6-Adresse | Dasselbe über IPv6 |
| CNAME | Name zu einem anderen Namen | Ein Alias der einem Umzug folgt |
| MX | Domain zu Mailserver | Ziel der Mailzustellung |
| PTR | Adresse zurück zu einem Namen | Reverse-Lookups und Protokollierung |
| NS | Zone zu ihren Servern | Delegation zwischen Zonen |
Reihenfolge einer Namensauflösung
- Der eigene Cache der Anwendung, sofern sie einen führt.
- Der Resolver-Cache des Betriebssystems mit einer früheren, noch gültigen Antwort.
- Die Hosts-Datei, die lokal und statisch ist und Vorrang vor dem Netzwerk hat.
- Der konfigurierte Resolver, meist derjenige aus dem DHCP-Lease.
Zwei dieser vier Quellen enthalten hostspezifische Daten. Deshalb kann ein Rechner einen Namen auflösen und sein Nachbar nicht. Im Cache liegt noch eine alte Antwort oder jemand hat vor zwei Jahren einen Eintrag in der Hosts-Datei hinterlassen.
Zwei Hosts, ein Name, zwei Antworten
Das Bestandssystem zieht planmäßig auf eine neue Adresse um und der A-Record wird aktualisiert. Ein Host, der den Namen noch nie abgefragt hat, erhält sofort die neue Adresse. Deles Rechner hat ihn eine Stunde vor der Umstellung mit einem TTL von einem Tag abgefragt und verwendet deshalb für den Rest des Tages die alte Adresse. Er meldet einen Ausfall, während alle um ihn herum normal arbeiten.
TTL bestimmt die Lebensdauer veralteter Antworten
Jeder Record hat eine Lebensdauer, die festlegt, wie lange ein Resolver eine Antwort behalten darf, bevor er erneut fragt. Ein langes TTL senkt die Abfragelast, verzögert aber Änderungen. Ein kurzes TTL bewirkt das Gegenteil. Vor einer geplanten Umstellung wird das TTL frühzeitig gesenkt, damit die Änderung schnell wirksam wird.
Wichtigste Erkenntnisse
- Ein Resolver hält bei der ersten Antwort aus Cache, Hosts-Datei oder konfiguriertem Server an.
- Zwei dieser Quellen sind hostspezifisch; deshalb können Hosts unterschiedliche Antworten erhalten.
- CNAME liefert einen Namen statt einer Adresse. Diese Umleitung vereinfacht Umstellungen.
- TTL bestimmt, wie lange eine veraltete Antwort erhalten bleibt. Senken Sie es vor einer geplanten Änderung, nicht erst währenddessen.
Bereit weiterzumachen?
Erstellen Sie ein kostenloses Konto, um Ihren Fortschritt zu speichern und den Wissenscheck zu absolvieren.