Was ist DNS-Weiterleitung? Funktionsweise und Relevanz
Was ist DNS-Weiterleitung? Erfahren Sie, wie sich Forwarder von rekursiven Resolvern unterscheiden, wie Caching und Failover funktionieren und welche Rolle die Weiterleitung in modernen Netzwerken spielt.
Published 23. Oktober 2026
DNS-Forwarding ist der Prozess, bei dem ein DNS-Resolver die Anfrage eines Clients an einen anderen DNS-Server, den Forwarder, sendet, anstatt den Namen direkt über die DNS-Hierarchie aufzulösen. Der lokale Resolver kann weiterhin aus seinem Cache antworten und lokale Richtlinien anwenden, während der Upstream-Resolver bei Bedarf die vollständige Suche durchführt. Wenn dieser Upstream-Server jedoch ausfällt, welcher Teil des DNS ist dann defekt?
Dieser Unterschied ist wichtig, wenn Sie ein Netzwerk konfigurieren oder erklären möchten, warum eine Website nicht geladen wird. Ein Forwarding-Resolver leitet Pakete nicht einfach nur weiter: Er kann vertraute Anfragen lokal beantworten, ausgewählte Abfragen an verschiedene Server leiten und steuern, welcher Resolver den DNS-Datenverkehr eines Benutzers sieht.
Inhaltsverzeichnis
- Was DNS-Forwarding tatsächlich bedeutet
- Eine Anfrage vom Client bis zur Antwort verfolgen
- Wie sich Forwarding von Rekursion und autoritativem Dienst unterscheidet
- Konditionelles Forwarding, Split-Horizon und Schleifenvermeidung
- Wie Caching und TTL die Forwarding-Performance beeinflussen
- Wahl zwischen Forwarding, Root-Hints-Rekursion und verschlüsseltem DNS
- Forwarding in Ihrem Netzwerk effektiv einsetzen
Was DNS-Weiterleitung tatsächlich bedeutet
Stellen Sie sich den lokalen Resolver wie einen Empfang in der Poststelle vor. Ein Client fragt eine Website nach Namen an, und der Resolver prüft, ob er die Antwort bereits kennt. Hat er eine gültige Antwort in seinem Cache, gibt er diese zurück. Wenn nicht, sendet er die Anfrage an einen Upstream-DNS-Server, den Forwarder, der die Suche durchführt und eine Antwort zurückgibt.
Diese Anordnung trennt zwei Aufgaben. Der lokale Resolver richtet sich an die Clients des Netzwerks und kann lokale Regeln anwenden. Der Upstream-Resolver übernimmt die Arbeit, Namen aufzulösen, die der lokale Server nicht aus seinem Cache oder seinen lokalen Daten beantworten kann. Die Weiterleitung ist daher eine architektonische Funktion und nicht automatisch ein Sicherheitsprodukt.
DNS entstand im November 1983, als RFC 882 und RFC 883 ein hierarchisches Namenssystem einführten, um das zunehmend unübersichtliche HOSTS.TXT Modell zu ersetzen. Vor DNS verließen sich Administratoren auf manuell gepflegte Zuordnungen von Namen zu Adressen. Im November 1987 ersetzten RFC 1034 und RFC 1035 die ursprünglichen Spezifikationen und wurden zu grundlegenden Standards für die moderne DNS-Architektur, wie die DNS-Zeitleiste dokumentiert.
Wo Ihnen Weiterleitungen begegnen
Heimrouter, Unternehmensnetzwerke, öffentliches WiFi, Schulen und Cloud-Umgebungen können alle Weiterleitungen nutzen. Eine Organisation könnte sie verwenden, um allgemeine Internet-Lookups an einen verwalteten rekursiven Dienst zu senden und gleichzeitig die lokale Kontrolle über Caching, Protokollierung, interne Namen oder Sperrregeln zu behalten.
Das nützliche Denkmodell ist einfach: Der lokale Resolver ist der kontrollierte Empfang; der Upstream-Resolver ist der Spezialist, der die vollständige Suche durchführt. Dieses Modell erleichtert auch die Fehlerdiagnose. Ein Client erreicht den Empfang möglicherweise erfolgreich, selbst wenn der Upstream-Resolver nicht verfügbar ist oder einen Fehler zurückgibt.
Verfolgung einer Abfrage vom Client bis zur Antwort
Ein typischer Lookup beginnt, wenn ein Gerät seinen lokalen Resolver nach einem Namen fragt. Der Resolver prüft zuerst seinen Cache. Wenn die gespeicherte Antwort noch gültig ist, kann er sie zurückgeben, ohne einen vorgelagerten Server zu kontaktieren. Wenn keine nutzbare Antwort im Cache vorhanden ist, leitet der Resolver die Abfrage an einen vorgelagerten rekursiven Resolver weiter.
In der DNS-Terminologie bedeutet Weiterleitung, dass ein Resolver eine Anfrage sendet, bei der das Recursion-Desired-Bit (RD-Bit) gesetzt ist. Dieses Bit signalisiert, dass der empfangende Resolver aufgefordert wird, die Anfrage aufzulösen, anstatt ein Paket lediglich ohne diese Aufforderung weiterzuleiten. Die Glossardefinition von RFC 7719 unterscheidet die Weiterleitung von der blinden Paketweiterleitung.
Bei einem Cache-Miss übernimmt der Upstream-Rekursiv-Resolver die Auflösungsarbeit. Er kann seinen eigenen Cache nutzen oder die DNS-Hierarchie nach der Antwort abfragen. Die Antwort gelangt dann über den Weiterleitungs-Resolver zurück zum Client.
Die zwei möglichen Pfade
- Cache-Hit: Der lokale Resolver gibt eine gültige Antwort aus dem Cache zurück. Der vorgelagerte Server ist an diesem Lookup nicht beteiligt.
- Cache-Miss: Der lokale Resolver sendet die Abfrage nach gelagert, empfängt die Antwort und gibt sie an den Client zurück.
Die Übergabe definiert auch eine nützliche Aufteilung der Zuständigkeiten. Der lokale Resolver kann netzwerkspezifische Kontrollen anwenden, Protokolle führen, Split-DNS-Regeln verwenden oder eine DNSSEC-Validierungsrichtlinie durchsetzen. Der vorgelagerte Resolver führt den rekursiven Lookup aus, wenn der lokale Resolver die Anfrage nicht aus seinem Cache oder aus lokalen Daten beantworten kann.
Hinweis zur Fehlersuche: Wenn der lokale Resolver Anfragen von Clients beantwortet, Abfragen jedoch fehlschlagen, wenn sein Cache die Antwort nicht enthält, prüfen Sie den Weiterleitungspfad und die Upstream-Antwort, bevor Sie davon ausgehen, dass der Fehler beim autoritativen DNS-Dienst liegt.
Unterschiede zwischen Weiterleitung, Rekursion und autoritativem Dienst
DNS-Weiterleitung, Rekursion, Proxying und autoritativer Dienst beschreiben unterschiedliche Rollen. Ein einzelnes System kann mehr als eine Rolle übernehmen, aber die Begriffe sind nicht austauschbar. In einem typischen Weiterleitungs-Setup bedient der lokale Server die Clients und verwaltet einen Cache oder Richtlinien; ein rekursiver Upstream-Resolver führt die Auflösung bei Cache-Misses durch.
| Rolle | Initiator | Führt vollständige Abfrage aus | Hält autoritative Daten | Typisches Fehlersymptom |
|---|---|---|---|---|
| Forwarder | Ein lokaler Resolver sendet ihm eine Anfrage | In der Regel, wenn er als vorgelagerter rekursiver Resolver agiert | Nicht zwingend | Zeitüberschreitung oder Fehler des vorgelagerten Dienstes |
| Rekursiver Resolver | Ein Client oder ein anderer Resolver fordert die Auflösung an | Ja, durch Nutzung des Caches oder Abfrage über die DNS-Hierarchie | Nicht zwingend | Auflösungsfehler, Zeitüberschreitungen oder fehlgeschlagene Abfragen |
| Proxy | Ein Client oder Dienst sendet ihm Datenverkehr | Nicht von Natur aus; Proxying leitet Anfragen gemäß seinem Design weiter | Nein | Die weitergeleitete Anfrage schlägt fehl oder erreicht ihr Ziel nicht |
| Autoritativer Server | Ein Resolver fragt ihn nach einer von ihm verwalteten Domain ab | Nein, er liefert Daten für seine Zone | Ja, für die von ihm verwalteten Zonen | Fehlende, fehlerhafte oder nicht verfügbare Datensätze für diese Zonen |
Der wesentliche Unterschied in der Tabelle ist, wer den vollständigen Lookup durchführt. Ein Weiterleitungs-Resolver leitet eine unbeantwortete Anfrage weiter; ein rekursiver Resolver übernimmt die Auflösung, gegebenenfalls durch Abfrage autoritativer Server. Ein autoritativer Server liefert Datensätze für die von ihm verwaltete Domain, anstatt im Namen eines Clients die Hierarchie zu durchsuchen.
Warum diese Unterscheidung die Fehlersuche verändert
Ein Forwarding Resolver kann ein Upstream-Timeout, SERVFAIL oder eine gecachte Antwort zurückgeben, die nicht mehr angemessen ist, selbst wenn die autoritative DNS-Infrastruktur normal funktioniert. Die Fehlersuche nur auf dem autoritativen Server durchzuführen, kann Sie in einer solchen Situation auf den falschen Weg führen. Überprüfen Sie, welcher Resolver die Anfrage erhalten hat, ob er eine Antwort im Cache hatte und was beim nächsten Hop passiert ist.
Es besteht auch eine Vertrauensabhängigkeit. RFC 7719 erörtert die Resolver-Terminologie, einschließlich der Unterscheidung zwischen Forwardern und rekursiven Resolvern. Forschungen zu Cache-Poisoning-Angriffen unterscheiden diese Rollen, da ein Forwarder von der Integrität des von ihm genutzten Upstream-Resolvers abhängt. Wenn Inhaltskontrollen Teil des Konzepts sind, kann ein Netzwerk auch DNS-Filtering nutzen, um Richtlinien auf Abfragen anzuwenden, bevor Geräte eine Verbindung zu Zielen herstellen.
Konditionale Weiterleitung, Split-Horizon und Schleifenvermeidung
Weiterleitungen müssen nicht jede unbeantwortete Anfrage an denselben Upstream-Server senden. Mit bedingter Weiterleitung sendet ein Resolver Anfragen für ausgewählte Domains an einen bestimmten Server. Beispielsweise kann ein Netzwerk Anfragen nach internen Namen an einen internen DNS-Dienst leiten und andere Anfragen an einen verwalteten rekursiven Resolver senden.
Ein verwandtes Konzept ist Split-Horizon DNS. Es ermöglicht einem Netzwerk, je nach Herkunft der Anfrage unterschiedliche Antworten für denselben Namen zurückzugeben. Jemand innerhalb einer Organisation erhält möglicherweise eine interne Antwort, während ein externer Anfragender eine andere Antwort erhält. Der lokale Resolver wird so zu einem Entscheidungspunkt, um interne Namen auf dem entsprechenden Pfad zu halten.
Die Konfiguration muss eindeutig festlegen, welcher Resolver für welchen Abfragepfad zuständig ist. Eine Regel, die einen internen Namen an den falschen Upstream-Server sendet, kann zu einer externen Antwort, einem Auflösungsfehler oder zu unterschiedlichen Ergebnissen in verschiedenen Teilen des Netzwerks führen.
Vermeidung von Resolver-Schleifen
Eine Weiterleitungsschleife entsteht, wenn ein Resolver eine Abfrage an einen zweiten Resolver sendet, der sie schließlich wieder zurückschickt. Die Abfrage kann zwischen Servern kreisen und zu wiederholten Anfragen, Zeitüberschreitungen und Ressourcenerschöpfung führen. Die Lösung besteht darin, die Weiterleitungspfade zu kartieren und sicherzustellen, dass keine Resolver-Kette auf einen früheren Server zurückweist.
Einige Namen benötigen ebenfalls eine explizite Grenze. RFC 9539 weist auf Namensräume wie home.arpa hin, die nicht über ihren vorgesehenen lokalen Bereich hinaus weitergeleitet werden dürfen. Ein Resolver, der funktioniert, bis ein zweiter Forwarder hinzugefügt wird, hat möglicherweise eine Schleife erzeugt; ein lokaler Name, der öffentlich aufgelöst wird, erfordert möglicherweise eine spezifischere Weiterleitungs- oder Lokale-Zonen-Regel.
Das folgende Video bietet eine weitere visuelle Einführung in die Konzepte der DNS-Weiterleitung.
Wie Caching und TTL die Weiterleistungsleistung beeinflussen
Der Cache eines Forwarders funktioniert wie das Gedächtnis eines hilfreichen Vermittlers: Sobald er eine Antwort vom Upstream abgerufen hat, kann er die nächste identische Frage selbst beantworten. Dieses einzelne Verhalten erklärt den größten Teil der Auswirkungen von Forwarding auf die Leistung. Jeder Cache-Treffer erspart einen Roundtrip zum Upstream-Resolver. Jeder Fehlschlag fügt einen hinzu, noch bevor die eigentliche Suche überhaupt beginnt.
Die Time to Live (TTL) jedes Datensatzes legt die Grenze für diesen Speicher fest. Der autoritative Server veröffentlicht die TTL, und jeder Resolver entlang des Pfads darf die gecachte Antwort nur wiederverwenden, solange sie gültig bleibt. Kurze TTLs halten Antworten aktuell, senden aber mehr Anfragen nach oben. Lange TTLs reduzieren den Upstream-Datenverkehr, können aber dazu führen, dass Clients nach einer Infrastrukturänderung veraltete Adressen behalten.
Caching stapelt sich auch entlang des Pfads. Eine Anfrage kann aus dem Cache des Clients, dem Cache des Forwarders oder dem Cache des Upstream-Resolvers bedient werden, und jede Schicht führt ihren eigenen TTL-Countdown aus. Wenn ein Benutzer eine veraltete Antwort meldet, hängt die Lösung davon ab, welche Schicht sie speichert. Betrachten Sie daher bei der Fehlersuche jeden Cache als separaten Verdächtigen, anstatt einfach das zu leeren, was am nächsten liegt.
Messen Sie mehr als nur die durchschnittliche Latenz
Die durchschnittliche Abfragezeit kann Probleme verbergen, die einige Benutzer oder Anfragen stärker betreffen als andere. Überwachen Sie die Cache-Hit-Rate, die mediane und maximale Abfragelatenz, die Rate vorgelagerter Zeitüberschreitungen sowie das Verhalten beim negativen Caching. Diese Messwerte helfen dabei, einen langsamen vorgelagerten Dienst von einem Forwarder zu unterscheiden, der Cache-Möglichkeiten verpasst oder mit fehlgeschlagenen Abfragen mangelhaft umgeht.
DNSSEC bringt eine weitere Besonderheit mit sich. Ein validierender Resolver ruft zusätzlich zur eigentlichen Antwort Signaturen und Schlüssel ab. Daher sind Cache-Misses bei signierten Namen aufwendiger als bei unsignierten. Im Cache gespeicherte, validierte Antworten überspringen diesen wiederholten Aufwand, wodurch die Hit-Rate auf Validierungspfaden noch wichtiger wird.
Keine einzelne Zahl kann die Abfragezeit in einem bestimmten Netzwerk vorhersagen. Das Ergebnis hängt vom Cache-Status auf jeder Schicht, der Reaktionsfähigkeit des Upstreams, der Validierungsarbeit, dem Transport-Setup und den erneuten Versuchen nach einem nicht reagierenden Forwarder ab. Ein korrekt arbeitender Forwarder leitet Antworten-Codes, Abschneideverhalten, DNSSEC-Datensätze und Flags unverändert weiter, sodass Clients die Antwort sehen, die die autoritative Seite gesendet hat.
Wahl zwischen Weiterleitung, Root-Hints-Rekursion und verschlüsseltem DNS
Weiterleitung und Rekursion über Root-Hints gehen unterschiedliche Kompromisse ein. Bei der Weiterleitung wählt eine Organisation Upstream-Resolver aus, um unbeantwortete Anfragen zu verarbeiten. Das kann den lokalen Betrieb vereinfachen und Richtlinien zentralisieren, macht das Netzwerk jedoch von den gewählten Upstream-Diensten abhängig. Bei der Rekursion über Root-Hints führt ein Resolver die iterative Abfrage selbst durch, was die Abhängigkeit von einem einzelnen rekursiven Upstream-Dienst verringert, aber diesem Resolver mehr Verantwortung für die Auflösung überträgt.
| Architektur-Option | Wo die Auflösung erfolgt | Wichtigster betrieblicher Kompromiss |
|---|---|---|
| Weiterleitung (Forwarding) | Beim ausgewählten Upstream-Rekursiv-Resolver | Zentralisierte Verwaltung, mit einer Upstream-Abhängigkeit |
| Root-Hints Rekursion | Beim lokalen rekursiven Resolver, der die Hierarchie abfragt | Mehr lokale Kontrolle, mit mehr Verantwortung für die direkte Auflösung |
| Client-gesteuertes verschlüsseltes DNS | Beim Resolver, den der Client über eine verschlüsselte Verbindung kontaktiert | Das lokale Netzwerk kann die Domänenabfrage möglicherweise nicht sehen oder steuern |
Verschlüsseltes DNS macht die Wahl weniger eindeutig. DNS over TLS und DNS over QUIC können DNS-Datenverkehr während der Übertragung schützen, aber die entscheidende Frage ist, wo die Verschlüsselung endet. Wenn ein Client Anfragen direkt an einen externen Resolver verschlüsselt, sieht ein lokaler Forwarder möglicherweise keine nutzbare Domänenabfrage. Wenn die Verschlüsselung an einem zugelassenen Enterprise-Resolver endet, kann dieser Resolver weiterhin Netzwerkrichtlinien anwenden und Anfragen nach oben weiterleiten.
Öffentliches WiFi erfordert eine gezielte Richtlinie
Betreiber von öffentlichem WiFi müssen auch Captive Portals berücksichtigen. Geräte benötigen unter Umständen eine Namensauflösung vor der Authentifizierung und Konnektivitätsprüfungen, bevor sich Benutzer anmelden können. Verschlüsseltes DNS kann die Portalerkennung erschweren oder verzögern, sodass Betreiber entscheiden müssen, welche Resolver zugelassen sind, wie der Fallback funktionieren soll und ob Ausnahmen erforderlich sind.
Ein Protective DNS-Dienst kann sich im ausgewählten Auflösungspfad befinden und Abfragen auswerten, bevor Verbindungen hergestellt werden. Purple Shield wurde für Veranstaltungsorte und Gäste-WiFi-Netzwerke entwickelt und bietet kategorienbasierte Inhaltsfilterung, Bedrohungsblockierung auf DNS-Ebene sowie Richtlinien, die pro Netzwerk verwaltet werden können. Es kann als eigenständiger Dienst bereitgestellt oder in Purple Access-Netzwerke integriert werden. Für Teams, die DNS-Kontrollen gegen umfassendere Web-Traffic-Kontrollen abwägen, beschreibt eine Secure Web Gateway Übersicht eine andere Durchsetzungsebene.
Möglichkeiten zur Nutzung der Weiterleitung in Ihrem Netzwerk
Weiterleitung konzentriert einen Teil der DNS-Arbeitslast bei den von einer Organisation ausgewählten Upstream-Diensten. Messungen mit den Datensätzen von DNS-OARC's Day in the Life ergaben, dass etwa 99 % der rekursiven Resolver ein moderates Abfragevolumen erzeugten, während sich etwa 1 % aggressiv verhielten. Diese kleinere Gruppe machte bis zu 98 % des beobachteten DNS-Datenverkehrs im Jahr 2018 und 93 % im Jahr 2019 aus; Forscher schätzten, dass sie etwa 8.300 Resolver im Jahr 2018 und mehr als 14.000 im Jahr 2019 umfasste (Studie zum aggressiven Resolver-Verhalten). Ein lokaler Resolver kann Anfragen an upstream-rekursive Dienste senden, die Antworten zwischenspeichern und wiederverwenden, was jedoch die Abhängigkeit von deren Verfügbarkeit und Verhalten konzentriert.
Prüfen Sie vor der Bereitstellung oder Änderung einer Weiterleitung Folgendes:
- Upstreams sind unabhängig: Konfigurieren Sie mindestens zwei Forwarder, sofern das Design dies zulässt.
- Ausfälle haben eine definierte Reaktion: Legen Sie Timeout- und Wiederholungsverhalten fest und wissen Sie, was Clients erhalten, wenn ein Upstream nicht antwortet.
- Monitoring deckt Symptome ab: Überwachen Sie SERVFAIL-Antworten, Timeouts und Antwortlatzenz.
- Datenschutzerwartungen sind klar: Entscheiden Sie, welcher Upstream-Resolver weitergeleitete Anfragen einsehen kann.
Wenn DNS-Filterung Teil Ihrer Gästenetzwerk-Richtlinie ist, vergleichen Sie diese mit Ihrem umfassenderen WiFi-Inhaltsfilterungsansatz. Überprüfen Sie anschließend, an welchen Resolver Ihr Netzwerk weiterleitet, und bestätigen Sie, dass dessen Richtlinie, Verfügbarkeit und Datenschutzstandards Ihren Vorstellungen entsprechen.
Purple Shield überprüft DNS-Lookups, bevor Geräte eine Verbindung herstellen, und bietet Inhaltsfilterung sowie Bedrohungsblockierung für Veranstaltungsort- und Gäste-WiFi-Netzwerke. Wenn Sie prüfen möchten, wie Weiterleitungen diese Kontrollen unterstützen können, besuchen Sie Purple Shield, um die Bereitstellungsoptionen zu erkunden.