DNS trennt die clientseitige Rekursion von der autoritativen Veröffentlichung. Wer diese Grenze versteht, verwechselt eine zwischengespeicherte Antwort nicht mit dem Eigentümer einer Zone.
DNS · Lektion 2
DNS-Komponenten
Lerne, wie rekursive Resolver, autoritative Server, Zonen und Resource Records die DNS-Aufgaben aufteilen.
Stub- und rekursive Resolver
Ein Stub-Resolver in einer Anwendung oder einem Betriebssystem sendet Abfragen an einen konfigurierten rekursiven Resolver. Dieser liefert ein endgültiges Ergebnis, einen Fehler oder das Ergebnis einer Weiterleitung, nachdem er seinen Cache genutzt und bei Bedarf iterative Abfragen ausgeführt hat. Seine Antwort kann das Kennzeichen für eine autoritative Antwort nur dann tragen, wenn der antwortende Server für die Daten autoritativ ist; Rekursion allein macht ihn nicht autoritativ.
Was übernimmt ein rekursiver Resolver für einen Stub-Client?
Autoritative Nameserver
Ein autoritativer Server antwortet aus Zonendaten, für die er Autorität besitzt. Eine Zone sollte mehrere autoritative Server mit synchronisierten Daten und voneinander unabhängigen Ausfallrisiken besitzen. Ein ausschließlich autoritativer Server muss für beliebige Clients keine Rekursion durchführen.
Wodurch ist ein Server für eine Zone autoritativ?
Zonen und Zonenspeicher
Eine Zone ist ein administrativ bereitgestellter Teil des DNS-Namensraums. Sie beginnt an einem Zonen-Apex und kann untergeordnete Zonen delegieren. Zonendaten können in einer Text-Zonendatei gespeichert, aus einer Datenbank erzeugt, über eine API geladen oder von Software synthetisiert werden. Eine „Zonendatei“ ist keine zwingende physische Implementierung.
Der Zonen-Apex besitzt normalerweise einen SOA-Eintrag und eine Gruppe von NS-Einträgen. Delegierungsdaten beim Elternknoten bezeichnen die autoritativen Server der untergeordneten Zone. Mitunter werden sie durch Glue-Adresseinträge ergänzt, die zum Erreichen von Servernamen innerhalb der delegierten Zone erforderlich sind.
Was ist eine DNS-Zone?
Felder eines Resource Records
Ein Resource Record besitzt Eigentümername, TTL, Klasse, Typ und typspezifische RDATA. Beispiel:
www.example.com. 300 IN A 192.0.2.25
Der Eigentümer ist www.example.com., die TTL beträgt 300 Sekunden, die Klasse ist Internet, der Typ eine IPv4-Adresse und RDATA ist die Adresse. Regeln für ausgelassene Felder und relative Namen in der Zonendateisyntax erfordern einen sorgfältigen Umgang mit dem Origin.
Welcher Eintragstyp veröffentlicht Priorität und Hostnamen von Mail Exchangern?
TTL und negatives Caching
Positive Einträge begrenzen mit TTLs ihre Wiederverwendung aus Caches. Auch negative Antworten, etwa ein nachweislich nicht vorhandener Name, können gemäß aus dem SOA abgeleiteten Regeln zwischengespeichert werden. Das Absenken einer TTL kurz vor einer geplanten Änderung wirkt sich nur auf Einträge aus, die nach dem Bekanntwerden des niedrigeren Werts abgerufen werden. Zuvor mit einer längeren TTL zwischengespeicherte Einträge bleiben bis zu ihrem Ablauf erhalten.
Warum sollte eine DNS-TTL lange vor einer geplanten Adressänderung abgesenkt werden?
Lektion abgeschlossen
Sie haben DNS-Komponenten abgeschlossen
Du kannst DNS-Rekursion, Autorität, Namensraumverwaltung und zwischengespeicherte Einträge nun voneinander trennen.
Erkenne die Rollen von Stub- und rekursivem Resolver.
Definiere Autorität durch die Bereitstellung einer delegierten Zone.
Betrachte eine Zone als Zuständigkeit im Namensraum und nicht als zwingend erforderliche Datei.
Lies Eigentümer-, TTL-, Klassen-, Typ- und RDATA-Felder.
Plane Cache-Lebensdauern vor DNS-Änderungen.
Lernfortschritt speichern
Erstellen Sie ein kostenloses Konto, um diese Lektion zu speichern und auf jedem Gerät weiterzulernen.
Kostenloses Konto erstellen