Was ist rekursives DNS: Funktionsweise und Relevanz
Was ist rekursives DNS? Erfahren Sie mit anschaulichen Beispielen, wie ein Resolver Anfragen beantwortet, Caching nutzt und wo Sicherheitsprüfungen greifen.
Published 2. November 2026
Ein rekursiver DNS-Resolver ist der Server, der eine Namensabfrage von Ihrem Gerät entgegennimmt, in dessen Namen die passende IP-Adresse durch Abfrage anderer DNS-Server ermittelt und die Antwort zur erneuten Verwendung speichert.
Angenommen, Sie haben eine Einstellung für Ihr Gäste-WiFi geändert, aber ein Besucher kann immer noch eine Website erreichen, die Sie blockieren wollten. Überprüfen Sie vor einer erneuten Änderung der Firewall, welchen Resolver das Gerät des Besuchers verwendet und ob Ihre Richtlinie für zwischengespeicherte Antworten gilt. Diese Details erklären oft die Lücke zwischen der Änderung einer Regel und deren Wirksamkeit.
Inhaltsverzeichnis
- Was ein rekursiver DNS-Resolver für Ihr Gerät leistet
- Rekursive und autoritative DNS-Server im Vergleich
- Wie eine rekursive Abfrage die DNS-Hierarchie durchläuft
- Caching, TTLs und wie lange eine Änderung dauert
- Filterung und Sicherheit am Resolver
- Ausfälle, veraltete Antworten und häufige Missverständnisse
- Bestätigen Sie, welchen Resolver Ihr Netzwerk verwendet, bevor Sie ihn ändern
Was ein rekursiver DNS-Resolver für Ihr Gerät leistet
Ein rekursiver DNS-Resolver ermittelt DNS-Antworten für ein Gerät - ähnlich wie ein Hotel-Concierge, der verschiedene Abteilungen kontaktiert, anstatt einen Gast von Schalter zu Schalter zu schicken. Der Gast stellt eine Frage und erwartet eine Antwort, keine Anweisungen zur Fortsetzung der Suche.
Angenommen, ein Hotelgast öffnet seinen Laptop und gibt den Namen einer Website ein. Wenn der Laptop lokal noch keine verwendbare Antwort gespeichert hat, sendet er eine Anfrage an seinen konfigurierten DNS-Dienst. Dieser Dienst kann vom Hotelnetzwerk, vom Internetanbieter oder von einem separat konfigurierten Resolver bereitgestellt werden.
Die Rollen hinter einer Abfrage
- Client: Das Gerät oder die Anwendung, die eine DNS-Antwort anfordert.
- Rekursiver Resolver: Der Dienst, der für das Suchen und Zurückgeben dieser Antwort verantwortlich ist.
- Autoritativer Server: Der Server, der die offiziellen DNS-Einträge für die angeforderte Domain veröffentlicht.
Die Analogie zum Concierge erleichtert die Unterscheidung dieser Zuständigkeiten.
Bei einer erfolgreichen Adresssuche erhält das Gerät eine IP-Adresse und eine Time-to-Live, meist als TTL abgekürzt. Dieser Wert teilt Caching-Systemen mit, wie lange sie die Antwort wiederverwenden dürfen. Der Browser kann die Adresse anschließend nutzen, um die Zieladresse zu kontaktieren.
Rekursiv bedeutet nicht endlose Wiederholung. Es beschreibt die Verantwortung, die der Resolver übernimmt: die finale Antwort für den Client zu finden oder einen entsprechenden Fehler zurückzugeben, wenn dies nicht möglich ist.
Der Hotelgast weiß in der Regel nichts von diesen Vorgängen. Er muss keine Root-Server auswählen und auch nicht verstehen, wer den DNS-Dienst der Website hostet.
Die Überprüfung des Verständnisses ist einfach: Ihr Gerät fordert eine Adresse an, der Resolver findet sie und Ihr Browser nutzt sie, um eine Verbindung herzustellen.
Vergleich von rekursiven und autoritativen DNS-Servern
Rekursiver Resolver im Vergleich zum autoritativen Server
| Kriterium | Rekursiver Resolver | Autoritativer Server |
|---|---|---|
| Hauptaufgabe | Findet Antworten für Clients durch Abfragen anderer Server | Veröffentlicht die offiziellen Datensätze für die Domains, für die er zuständig ist |
| Herkunft der Antworten | Sein Cache oder Upstream-DNS-Server | Seine eigenen Zonen-Datensätze |
| Typischer Betreiber | Internet-Anbieter, öffentlicher Resolver-Dienst, Netzwerkeigentümer | Domain-Inhaber oder Hosting-Anbieter |
| Direkt von Geräten kontaktiert | Ja | In der Regel nicht; Resolver kontaktieren ihn |
| Cacht Antworten für andere Domains | Ja, vorbehaltlich TTL und lokaler Cache-Regeln | Nein, nicht im Rahmen seiner autoritativen Rolle |
Der wesentliche Unterschied liegt zwischen Abruf und Autoriät. Ein rekursiver Resolver ruft Informationen für jemanden ab. Ein autoritativer Server veröffentlicht Informationen für eine Domäne unter seiner Verantwortung.
Dieser Unterschied ist bei der Fehlerbehebung wichtig. Wenn alle Personen die falsche Adresse für die Website Ihrer Organisation erhalten, überprüfen Sie die autoritativen Datensätze. Wenn nur Besucher in einem bestimmten Netzwerk Probleme haben, untersuchen Sie den Resolver dieses Netzwerks, seinen Cache und seine Richtlinien.
Betreiber können Überschneidungen aufweisen, ohne die Rollen zusammenzuführen
Ein Internetanbieter betreibt möglicherweise ein rekursives DNS für Abonnenten, während ein Hosting-Anbieter autoritatives DNS für Kunden bereitstellt. Ein Netzwerkbesitzer kann auch einen internen Resolver für Mitarbeitergeräte betreiben.
Dieselbe Organisation - und manchmal dieselbe Server-Software - kann beide Aufgaben erfüllen. Ein Server könnte autoritativ für eine interne Domain antworten, während er nicht verwandte Internet-Namen für Mitarbeiter auflöst. Die Rolle hängt von der verarbeiteten Anfrage ab, nicht nur vom Unternehmensnamen auf dem Dienst.
Die Weiterleitung bringt eine weitere Unterscheidung mit sich. Ein lokaler DNS-Server kann Anfragen an einen vorgelagerten Resolver weiterleiten, anstatt die Hierarchie selbst zu kontaktieren. Das Verständnis der DNS-Weiterleitung hilft Ihnen zu identifizieren, welcher Dienst die externe Abfrage durchführt.
Ein autoritativer Server ist normalerweise nicht der Kontrollpunkt für die Inhaltsfilterung des Besuchers. Er veröffentlicht die Einträge der Domain, anstatt die Netzwerktag-Regeln des Besuchers anzuwenden.
Diagnosefrage: Antwortet dieser Server aus Einträgen, für die er verantwortlich ist, oder sucht er Einträge im Namen eines Clients?
Diese Frage ist hilfreicher als anzunehmen, dass jeder als DNS bezeichnete Server dieselbe Aufgabe erfüllt.
Wie ein rekursiver Lookup die DNS-Hierarchie durchläuft
Betrachten Sie eine Abfrage für www.example.com, wenn weder das Gerät noch sein Resolver über die zur Beantwortung erforderlichen Informationen verfügen.
Das Gerät sendet eine rekursive Anfrage an seinen Resolver, um ein endgültiges Ergebnis zu erhalten. Der Resolver stellt in der Regel iterative Anfragen an übergeordnete Instanzen: Root- und Top-Level-Domain-Server liefern Verweise, während der autoritative Server den angeforderten Datensatz bereitstellt.
Dieses Diagramm zeigt den Gesamtablauf vor den einzelnen Interaktionen.
Verfolgen Sie die Anfrage und die Antwort
Das Gerät kontaktiert seinen konfigurierten Resolver. Es sendet den Namen der Website, da es eine Adresse benötigt, bevor es das Ziel kontaktieren kann.
Der Resolver prüft seinen Cache. Eine verwendbare gecachte Antwort beendet die Suche sofort. Es gibt keinen Grund, Upstream-Server nach Informationen zu fragen, die der Resolver noch wiederverwenden kann.
Bei einem Cache-Miss fragt er einen Root-Server. Der Root-Server leitet ihn an die Server weiter, die für die entsprechende Top-Level-Domain zuständig sind, in diesem Fall .com.
Er fragt einen .com-Server. Dieser Server identifiziert die autoritativen Nameserver für example.com und grenzt die Suche auf die zugewiesenen Instanzen der Domain ein.
Er fragt einen autoritativen Server ab. Der autoritative Server gibt den angeforderten Adressdatensatz und dessen TTL in Sekunden zurück.
Er speichert und gibt die Antwort zurück. Der Resolver behält eine wiederverwendbare Kopie und sendet das Ergebnis an das Gerät.
Spätere Anfragen können diese gecachte Kopie verwenden. Solange die Antwort verwendbar bleibt, muss der Resolver den Upstream-Pfad für denselben Namen und Datensatztyp nicht wiederholen.
Die Hierarchie verteilt die Verantwortung. Root-Server identifizieren die Autoritäten für Top-Level-Domains, diese Autoritäten identifizieren Domain-Name-Server und Domain-Administratoren verwalten die Ziel-Einträge.
Eine zwischengespeicherte Antwort ist weiterhin eine gültige Antwort
Die Antwort des Resolvers ist normalerweise nicht-autoritativ. Das bedeutet, dass er Informationen weiterleitet, anstatt als Autorität der Domain zu antworten, und nicht, dass die Antwort nicht vertrauenswürdig ist.
Einige Bereitstellungen leiten die Anfrage an einen vorgelagerten rekursiven Dienst weiter, der diese Aufgabe in ihrem Namen ausführt. Zudem kann ein Resolver mit zwischengespeicherten Verweisen Teile des dargestellten Pfads überspringen.
Lokale Cache-Regeln spielen ebenfalls eine Rolle. Die Anmerkungen von APNIC zu RIPE 91 zeigen häufig beobachtete maximale Cache-Timer von Resolvern von 6 Stunden, 12 Stunden, 24 Stunden und 7 Tagen. Dies verdeutlicht, warum Administratoren nicht davon ausgehen sollten, dass jeder Resolver identische Cache-Grenzwerte nutzt.
Für eine weitere Ansicht des Abfrageprozesses verfolgt dieses Video die DNS-Auflösung.
Caching, TTLs und die Dauer einer Änderung
Eine Domain wird um 9:00 Uhr gesperrt, und ein Laptop im selben Netzwerk öffnet sie um 9:40 Uhr immer noch. Diese Zeitspanne entsteht durch Wiederverwendung. Eine TTL funktioniert wie die Ablaufzeit eines Parkscheins: Sie teilt dem Resolver mit, wie lange er eine gespeicherte Antwort weitergeben darf, bevor er erneut bei der übergeordneten Instanz anfragen muss.
Bei einem gewöhnlichen zwischengespeicherten Datensatz ist die verbleibende Lebensdauer die entscheidende Größe. Der maximale Cache-Timer eines Resolvers kann diese Lebensdauer verkürzen, während ein lokal erzwungenes Minimum sie verlängern kann. Zu den beobachteten Resolver-Höchstwerten gehören 6 Stunden, 12 Stunden, 24 Stunden und 7 Tage, gemäß den Anmerkungen von APNIC von der RIPE 91. Diese Einstellungen steuern die Aktualität von Datensätzen. Sie bestimmen nur dann, wie lange eine Blockierung dauert, wenn das Filterkonzept auf der Aktualisierung der DNS-Antwort basiert, anstatt die aktuelle Richtlinie zu prüfen.
Cache-Einstellungen und ihre Bedeutung für eine neue Sperrung
| Cache-Einstellung | Typischer Wert | Auswirkung auf eine neue Sperre oder Änderung |
|---|---|---|
| TTL von null Sekunden | Keine wiederverwendbare Lebensdauer | Bei normaler TTL-Verarbeitung löst die nächste Anfrage eine Upstream-Abfrage aus |
| Kurze TTL | Sekunden bis Minuten | Record-Änderungen werden kurz nach jeder Aktualisierung sichtbar |
| Maximale Cache-Laufzeit des Resolvers | 6 Stunden | Begrenzt die Speicherung von Records mit längerer TTL |
| Maximale Cache-Laufzeit des Resolvers | 12 Stunden | Kürzt längere Record-TTLs auf einen halben Tag |
| Maximale Cache-Laufzeit des Resolvers | 24 Stunden | Ermöglicht das Bestehen einer Antwort über Nacht, bis zu einem ganzen Tag |
| Maximale Cache-Laufzeit des Resolvers | 7 Tage | Ermöglicht eine einwöchige Speicherung nur dann, wenn die Record-TTL dies ebenfalls zulässt |
Trennen Sie Record-Änderungen von Richtlinienänderungen
Angenommen, die autoritative Adresse einer Website ändert sich eine Minute, nachdem ein Resolver die alte Antwort zwischengespeichert hat. Dieser Resolver kann weiterhin die alte Adresse zurückgeben, bis die effektive Lebensdauer endet. Dies entspricht dem kürzeren Wert aus der Datensatz-TTL und dem eigenen Maximum des Resolvers, angepasst um ein etwaig erzwungenes Minimum. Bei einer Datensatz-TTL von 24 Stunden und einer Obergrenze von 6 Stunden erreichen Nutzer die neue Adresse innerhalb von sechs Stunden. Bei einer Datensatz-TTL von 7 Tagen unter einer Obergrenze von 7 Tagen können sie eine ganze Woche warten.
Die Adresse bleibt nun dieselbe, aber ein Sicherheitsteam stuft die Domain als bösartig ein. Ein Resolver, der die aktuelle Richtlinie vor dem Bereitstellen einer zwischengespeicherten Antwort erneut überprüft, blockiert die Domain bei der nächsten Abfrage. Ein Konzept, das erst bei einer Aktualisierung der Antwort neu auswertet, lässt den Pfad für die verbleibende effektive Lebensdauer offen - was bei einer Begrenzung auf 24 Stunden einen Tag lang ein Sicherheitsrisiko bedeuten kann.
Praktische Regel: Fragen Sie ab, wann der Resolver seine DNS-Antwort aktualisiert und wann er seine Filterentscheidung neu bewertet. Eine Änderung erreicht die Benutzer zum späteren dieser beiden Zeitpunkte.
Testen Sie bei dringenden Änderungen sowohl eine zuvor abgefragte als auch eine nicht im Cache gespeicherte Domäne. Überwachen Sie Cache-Treffer, das vorgelagerte Abfragevolumen und die Bereitstellung von Richtlinien-Updates als separate Kennzahlen. Eine schnelle neue Abfrage sagt nichts über Benutzer aus, die noch eine im Cache gespeicherte Antwort nutzen.
Filterung und Sicherheit am Resolver
Ein Resolver kann Regeln auf die eingehenden Abfragen anwenden, bevor das Gerät eine Verbindung herstellt. Rekursion allein bietet diese Regeln jedoch nicht. Inhaltsklassifizierung, Bedrohungserkennung und DNS-Authentizitätsprüfungen sind separate Funktionen.
Inhaltsfilterung legt Zugriffsregeln fest
Kategoriebasierte DNS-Filterung ermöglicht es einem Netzwerkbesitzer zu entscheiden, welche Ziele Benutzer erreichen dürfen. Eine Familienattraktion könnte Inhalte für Erwachsene im Gäste-WiFi einschränken, während für ein administratives Netzwerk andere Regeln gelten.
Bevor ein Gerät eine Website oder App öffnet, fragt es beim DNS nach dem Ziel, und wir antworten auf Basis der Richtlinie für das Netzwerk, in dem sich das Gerät befindet. Dadurch ist die Identität des Netzwerks wichtig, nicht nur die angeforderte Domäne.
Die Hauptfunktionen bleiben separat, selbst wenn sie von einem einzigen Dienst bereitgestellt werden.
Die Bedrohung Abwehr bewertet das Ziel
Bedrohungskontrollen können Abfragen für bekannte Phishing- und Malware-Domänen verweigern. Unsere Bedrohung Abwehr blockiert zudem Command-and-Control-Rückrufe von infizierten Geräten direkt bei der Abfrage und verhindert so, dass diese Verbindungsversuche über diesen Auflösungspfad gestartet werden.
Das ist eine nützliche Eindämmung, entfernt Schadsoftware jedoch nicht vom Gerät. Endpunktschutz und Firewall-Steuerungen haben weiterhin ihre eigenen Aufgaben.
DNSSEC prüft die Authentizität, nicht die Sicherheit
Die DNSSEC-Validierung nutzt einen konfigurierten Trust-Anchor und eine Kette kryptografischer Signaturen, um signierte DNS-Daten zu authentifizieren. RFC 4033 beschreibt die sichere Validierung und gibt an, dass ein sicherheitsbewusster Resolver die Signaturgültigkeit bei der Auswahl von Cache-Lebensdauern berücksichtigen sollte, wobei Uhrenungenauigkeiten einkalkuliert werden.
Administratoren benötigen daher eine genaue Systemzeit und ein Cache-Handling, das den Validierungsstatus beibehält. Ein Resolver muss rechtmäßig unsignierte Daten von signierten Daten unterscheiden können, die die Validierung nicht bestehen.
- Frühzeitige Kontrolle: Eine Filterung kann einen unerwünschten Aufruf stoppen, bevor eine Verbindung hergestellt wird, jedoch nur für Anfragen, die diesen Resolver verwenden.
- Konsistente Regeln: Geräte, die dieselbe Netzwerkrichtlinie verwenden, werden konsistent behandelt, aber alternative Auflösungspfade erfordern separate Kontrollen.
- Authentizitätsprüfung: DNSSEC hilft beim Erkennen gefälschter signierter Antworten, verschlüsselt jedoch keine Anfragen und stellt nicht fest, ob eine Domain bösartig ist.
Eine korrekt signierte Phishing-Domain ist immer noch eine Phishing-Domain. Die Filterung entscheidet, ob der Zugriff zugelassen werden soll; DNSSEC stellt fest, ob signierte DNS-Informationen authentisch sind.
Ausfälle, veraltete Antworten und häufige Missverständnisse
Ein Gast ruft eine Website auf, während deren autoritativer DNS-Server nicht erreichbar ist, und die Seite lädt trotzdem. Der Resolver verfügt möglicherweise über eine noch gültige Antwort im Cache, sodass er den autoritativen Server für diese Anfrage nicht kontaktieren muss.
Einige Resolver können nach dem regulären Ablauf auch veraltete Antworten bereitstellen, wenn Upstream-Server nicht verfügbar sind. Das ist eine Verfügbarkeitsstrategie und kein Beweis dafür, dass DNS-Datensätze unbegrenzt aktuell bleiben. Die DNS-Erläuterung von Cloudflare beschreibt den grundlegenden Unterschied zwischen dem Resolver, der Informationen abruft, und dem autoritativen Server, der sie bereitstellt.
Zwischengespeicherte Antworten erklären, warum ein autoritativer Ausfall nicht immer sofort zu einem Ausfall beim Surfen führt.
Verfügbarkeit und Schutz erfordern explizite Entscheidungen
Resolver können auch fehlerhafte Ergebnisse zwischenspeichern. Das negative Caching speichert Informationen darüber, dass ein Name nicht existiert, um wiederholte Suchen nach demselben fehlenden Namen zu vermeiden. Nachdem ein Administrator diesen Namen erstellt hat, erhalten einige Clients möglicherweise weiterhin das zwischengespeicherte negative Ergebnis, bis dieses abläuft.
Die Fehlerbehandlung wirft eine separate Frage der Richtlinien auf. Ein Fail-Open-Filterkonzept erlaubt die Auflösung ohne die normalen Richtlinienprüfungen, wenn diese Prüfungen nicht verfügbar sind. Ein Fail-Closed-Konzept verweigert Anfragen, die es nicht genehmigen kann. Dadurch bleibt die Einschränkung aufrecht, jedoch wird möglicherweise der legitime Zugriff unterbrochen.
Fehlschläge bei der DNSSEC-Validierung sind ein weiterer separater Fall. Betreiber sollten ungültige signierte Daten nicht allein deshalb als authentifiziert behandeln, um das Laden einer Seite aufrechtzuerhalten.
Annahmen, die zu betrieblichen Fehlern führen
- Rekursion bedeutet automatisch Blockierung: Rekursion ruft Antworten ab; Administratoren fügen die Blockierung über eine Richtlinienschicht hinzu.
- Ein DNS-Filter steuert jede Verbindung: Fest codierte Zieladressen und einige VPN-Pfade können den geschützten Aufruf vollständig umgehen.
- Das Ändern der Netzwerk-DNS leitet sofort jeden Client um: Bestehende Einstellungen, DHCP-Leases und Resolver-Optionen auf Browser-Ebene können dazu führen, dass Geräte auf einem anderen Pfad verbleiben.
Unterscheiden Sie bei der Untersuchung eines Ausfalls zwischen einer nicht erreichbaren Autorisierungsinstanz, einem abgelaufenen Datensatz, einer negativen Antwort, einem Validierungsfehler und einer Ablehnung durch Richtlinien. Diese können für einen Gast ähnlich aussehen, erfordern jedoch unterschiedliche Maßnahmen.
Die Rekursion liefert Antworten. Richtlinien und Resilienz bestimmen, welche Antworten das Netzwerk unter sich ändernden Bedingungen bereitstellt.
Prüfen Sie, welchen Resolver Ihr Netzwerk nutzt, bevor Sie ihn ändern
Wenn Sie sich fragen, was rekursives DNS ist, weil Sie Änderungen an einem Live-Netzwerk vornehmen möchten, beginnen Sie mit der Erfassung des aktuellen Pfads. Dokumentieren Sie die funktionierende Konfiguration, damit Sie diese wiederherstellen können, falls Tests eine Abhängigkeit von internen Namen oder Anwendungen aufdecken.
Prüfen Sie den Pfad vor dem Rollout
- Ermitteln Sie den konfigurierten DNS-Dienst des Geräts. Verwenden Sie dessen Netzwerkeinstellungen oder ein DNS-Lookup-Tool. Eine Router-Adresse kann einen Weiterleitungsdienst darstellen, verfolgen Sie daher auch dessen Upstream-Ziel.
- Überprüfen Sie DHCP- und Controller-Einstellungen. Bestätigen Sie, welchen Resolver das Netzwerk ankündigt und ob manuell konfigurierte Clients diesem folgen.
- Halten Sie die erforderliche Richtlinie schriftlich fest. Identifizieren Sie Inhaltskategorien, Malware-Kontrollen, Lookup-Protokollierung sowie Unterschiede zwischen Mitarbeiter- und Gastzugriff.
- Wählen Sie ein akzeptables Aktualisierungsverhalten. Legen Sie tolerierbare Verzögerungen bei Datensatz- und Richtlinienaktualisierungen sowie die vorgesehene Reaktion auf Dienstausfälle fest.
- Führen Sie ein Pilotprojekt in einem begrenzten Netzwerk durch. Testen Sie zulässige Websites, blockierte Ziele, interne Ressourcen und die Wiederherstellung, bevor Sie die Änderung ausweiten.
Die Bereitstellung erfolgt über eine DNS-Einstellung pro Netzwerk oder eine DHCP-Änderung auf dem Controller, ohne dass etwas auf den Endgeräten installiert werden muss. Dies deckt Geräte ab, die der DNS-Konfiguration des Netzwerks folgen, garantiert jedoch nicht, dass jede Anwendung diese nutzt.
Testen Sie VPNs und DNS over HTTPS, da diese alternative Auflösungspfade erstellen können. Unser Team zeigt Ihnen vor einem Testlauf, wie das Netzwerk mit VPNs und verschlüsseltem DNS umgeht.
Ein rekursiver Resolver mit Richtlinien ist die richtige Wahl, wenn das Netzwerk eine Filterung vor dem Verbindungsaufbau benötigt und der Eigentümer dessen Cache- und Ausfallverhalten akzeptiert.
Purple Shield bietet schützendes DNS, Inhaltsfilterung, Bedrohungsschutz und Werbeblockierung auf DNS-Ebene für Gäste- und öffentliches WiFi ohne Geräte-Agenten. Besuchen Sie Purple Shield, um den Resolver-Pfad Ihres Netzwerks, die von Ihnen benötigten Richtlinien und das Testen der Durchsetzung vor der Einführung einer DNS-Änderung zu besprechen.