DNS Request Routes auf Sophos Firewall konfigurieren

Eine DNS Request Route leitet Abfragen für eine bestimmte Domain oder Reverse-Zone an ausgewählte DNS-Server weiter. Ein typischer Fall ist ad.example.com: Öffentliche Namen löst die Firewall über ihre normalen Resolver auf, Anfragen für diese interne Zone sendet sie an die Domain Controller.

Die Route wirkt nur, wenn die Sophos Firewall die Anfrage als DNS-Server verarbeitet. Fragt ein Client den internen DNS-Server direkt, ist dessen Weiterleitung zuständig und nicht die Request Route der Firewall.

Die Zielzone muss nicht intern sein: Eine Request Route kann auch ausgewählte öffentliche Domains an einen Resolver im eigenen Netz leiten. Das ist sinnvoll, wenn dieser Resolver für diese Domains bewusst zuständig ist. Lokale Verarbeitung kann externe DNS-Anfragen reduzieren; eine bestimmte Beschleunigung oder zusätzliche Vertraulichkeit ist aber nur gegeben, wenn der Zielresolver die Anfragen entsprechend verarbeitet und nicht seinerseits unverändert ins Internet weiterleitet.

Den DNS-Pfad vor der Änderung bestimmen

Drei ähnlich wirkende Konfigurationen lösen unterschiedliche Aufgaben:

• Client fragt die Firewall: DHCP oder das VPN-Profil verteilt die Interface-IP der Firewall als DNS-Server. Für den Zugriff auf den lokalen DNS-Dienst muss die Clientzone unter Administration > Device access > Local service ACL für DNS erlaubt sein. Normale Firewallregeln steuern diesen Zugriff auf die Firewall nicht.
• Client fragt einen internen DNS-Server direkt: Der interne Resolver beantwortet lokale Zonen und leitet andere Anfragen weiter. Zwischen verschiedenen Zonen kann dafür eine normale Firewallregel nötig sein; eine Request Route auf der Firewall wird von diesem Clientpfad nicht verwendet.
• Firewall fragt einen internen Zielserver: Eine Request Route wählt den Zielserver anhand der abgefragten Domain. Routing und Erreichbarkeit des Zielservers müssen stimmen.

Eine DNS Host Entry beantwortet dagegen einen einzelnen Namen direkt auf der Firewall. Für wenige statische Einträge zeigt DNS Host Entries auf Sophos Firewall einrichten den vollständigen Ablauf. Eine Request Route passt besser zu einer ganzen, auf einem DNS-Server gepflegten Zone. DHCP-Optionen legen wiederum fest, welchen DNS-Server und welche Suchdomain ein Client erhält; dazu gehört DHCP-Optionen auf Sophos Firewall konfigurieren.

⚠️ Eine Request Route wird nach dem Domainnamen ausgewählt, nicht nach dem Quellnetz des Clients. Unterschiedliche Antworten für verschiedene Standorte müssen die beteiligten Resolver oder getrennte DNS-Pfade bereitstellen. Eine einzelne Route erzeugt keine quellabhängige DNS-Sicht.

Beispiel und Voraussetzungen

Dieses Beispiel leitet eine interne AD-Zone an zwei Resolver weiter:

• interne Zone: ad.example.com
• primärer Zielserver: 10.10.10.10
• zweiter Zielserver: 10.10.10.11
• Clientnetz: 10.20.30.0/24
• Firewall-IP als Client-Resolver: 10.20.30.1
• Positivtest: dc01.ad.example.com
• Negativtest: example.net

example.com und example.net sind Dokumentationsdomains. In der produktiven Konfiguration werden Zone, Server- und Interface-Adressen durch die eigenen Werte ersetzt. Beide Zielserver sollten für dieselbe Zone zuständig sein und denselben Zonenstand liefern. Eine lange Liste unterschiedlicher Resolver ist keine saubere Redundanz.

Vor dem Anlegen müssen folgende Punkte geklärt sein:

1. Die Firewall ist unter Network > DNS > DNS configuration als Resolver konfiguriert.
2. Die Zielserver sind über den vorgesehenen lokalen oder VPN-Routingpfad erreichbar.
3. Clients, für die die Route wirken soll, verwenden tatsächlich die Firewall-IP als DNS-Server.
4. Unter Administration > Device access ist DNS nur für die benötigten Clientzonen freigegeben. Eine engere Local Service ACL Exception ist sinnvoll, wenn nicht die ganze Zone zugreifen soll.
5. Die interne Zone existiert auf den Zielservern und enthält einen bekannten Testeintrag.
6. Der bisherige DNS-Pfad und die vorhandenen Request Routes sind für einen Rückbau dokumentiert.

DNS Request Route anlegen

1. Im WebAdmin Network > DNS öffnen.
2. Zum Abschnitt DNS request route wechseln.
3. Add auswählen.
4. Unter Host/Domain name ad.example.com eintragen.
5. Unter Target servers 10.10.10.10 und 10.10.10.11 auswählen. Fehlen die Serverobjekte, werden sie über Create als IP Hosts angelegt.
6. Die Reihenfolge kontrollieren: SFOS fragt die ausgewählten Hosts in der angegebenen Reihenfolge an.
7. Mit Save speichern.

Sophos erlaubt pro Request Route höchstens acht Ziel-IP-Adressen. Mehr Server verbessern die Verfügbarkeit nur, wenn sie dieselbe Zone korrekt beantworten und über unabhängige, tatsächlich funktionierende Pfade erreichbar sind.

Trifft eine Request Route und findet die Firewall keine passende Antwort im Cache, sendet SFOS die Anfrage an deren Target Servers. Es fällt für diese Domain nicht auf die globalen Forwarder oder Root-Server zurück. Sind alle Zielserver unerreichbar oder für die Zone falsch konfiguriert, schlägt die Auflösung daher fehl, statt unbemerkt einen öffentlichen Resolver zu verwenden.

Unter DNS request route muss der neue Eintrag anschliessend mit der erwarteten Domain und den Zielservern erscheinen.

Mehrere Zielserver richtig beurteilen

Die dokumentierte Reihenfolge ist ein Erreichbarkeitsmechanismus, kein Abgleich widersprüchlicher DNS-Daten. Bei den globalen statischen Resolvern behandelt SFOS NXDOMAIN als gültige Antwort und fragt danach nicht den nächsten Server. Die SFOS-22-Hilfe bestätigt dieses Verhalten nicht ausdrücklich für die Zielserver einer Request Route. Man sollte daher weder auf einen zweiten, abweichenden Zonenstand vertrauen noch ein bestimmtes Failover nach NXDOMAIN versprechen.

Für die Abnahme werden beide Zielserver einzeln von einem berechtigten Testsystem geprüft. Sie müssen den Positivtest gleich beantworten; ein bewusst nicht vorhandener Name sollte auf beiden Servern dasselbe Ergebnis liefern. So findet man Replikations- oder Zuständigkeitsfehler, bevor die Firewall zwischen den Servern wechseln muss.

nslookup dc01.ad.example.com 10.10.10.10
nslookup dc01.ad.example.com 10.10.10.11
nslookup does-not-exist.ad.example.com 10.10.10.10
nslookup does-not-exist.ad.example.com 10.10.10.11

Die direkten Abfragen testen Zonenstand und Serverantwort, nicht die Request Route. Sie werden nur aus einem Netz ausgeführt, das laut DNS-Design auf beide Resolver zugreifen darf. Danach bestätigt die Abfrage über 10.20.30.1, dass auch die Firewall die Zone an die vorgesehenen Server leitet.

Reverse-Lookups weiterleiten

Für PTR-Abfragen trägt man die Reverse-Zone statt eines Netzes in Host/Domain name ein. Für 172.16.16.0/24 lautet die klassische IPv4-Reverse-Zone:

16.16.172.in-addr.arpa

Für 172.16.0.0/16 lautet sie:

16.172.in-addr.arpa

Eine CIDR-Angabe wie 172.16.16.0/24 gehört nicht in das Domainfeld. Entscheidend ist die Zone, die auf dem internen DNS-Server tatsächlich eingerichtet ist. Die Request Route erzeugt keine PTR-Records; fehlen Zone oder Records auf dem Zielserver, bleibt die Reverse-Abfrage erfolglos. Nicht oktettbündige IPv4-Netze und IPv6-Reverse-Zonen benötigen ein eigenes DNS-Delegationsdesign und sollten nicht durch blosses Umkehren des Präfixes improvisiert werden.

Reverse DNS hilft Logs und Diensten, eine Adresse einem Namen zuzuordnen. Es repariert aber keine fehlgeschlagene Forward-Auflösung eines FQDN und ist deshalb ein eigener Testfall.

Globalen Resolverpfad einordnen

Unter Network > DNS > DNS configuration legt man fest, wie die Firewall Anfragen auflöst, für die keine Host Entry und keine Request Route greift. Je nach Interface kann SFOS Resolver über Obtain DNS from DHCP oder Obtain DNS from PPPoE beziehen. Mit Static DNS werden DNS 1, DNS 2 und optional DNS 3 ausdrücklich gesetzt.

⚠️ Ist Obtain DNS from DHCP aktiv und wird das letzte passende DHCP-Interface ausgeschaltet oder auf einen anderen Zuweisungsmodus geändert, wechselt SFOS auf Static DNS. Wird das Interface wieder aktiviert, kehrt die Einstellung nicht automatisch zurück. Nach WAN- und Interface-Änderungen muss die DNS-Auswahl deshalb kontrolliert werden.

Bei Static DNS fragt die Firewall die Server in der eingetragenen Reihenfolge. Sie wechselt bei einem Timeout zum nächsten Server, aber nicht nach einer gültigen NXDOMAIN-Antwort. Antworten bleiben gemäss ihrer TTL im Cache. Ein zweiter Resolver ist damit eine Erreichbarkeitsreserve, keine alternative DNS-Wahrheit.

Für die globalen DNS-Server dokumentiert SFOS 22 vier Auswahlmöglichkeiten. Bei den beiden festen Prioritäten müssen IPv4- und IPv6-DNS-Server konfiguriert sein:

• Choose a server based on incoming requests record type wählt den DNS-Server anhand des angefragten Record-Typs A oder AAAA.
• Choose IPv6 DNS server over IPv4 gibt dem IPv6-DNS-Server Vorrang vor dem IPv4-DNS-Server.
• Choose IPv4 DNS server over IPv6 gibt dem IPv4-DNS-Server Vorrang vor dem IPv6-DNS-Server.
• Choose IPv6 if request originator address is IPv6, else IPv4 verwendet bei einer Anfrage von einer IPv6-Quelladresse den IPv6-DNS-Server und bei einer IPv4-Quelladresse den IPv4-DNS-Server.

Record-Typ und Quelladressfamilie sind unterschiedliche Kriterien: Eine AAAA-Abfrage ist nicht automatisch eine Anfrage von einer IPv6-Quelladresse. Die Auswahl wird deshalb nach dem vorgesehenen Resolverpfad getroffen, nicht allein nach der gewünschten Adresse in der DNS-Antwort. Die gewählten Resolver müssen über die jeweilige Adressfamilie erreichbar sein. Diese globalen Optionen ändern nicht die domainbasierte Auswahl der Target servers einer Request Route.

Nach Apply prüft Test name lookup einen Hostnamen oder eine IP-Adresse aus Sicht der Firewall. Ein interner Testname kann dabei eine passende Request Route verwenden. Der Test bestätigt jedoch weder den am Client eingetragenen Resolver noch dessen tatsächlichen DNS-Pfad.

Wenn WebAdmin bei einer geplanten Recovery nicht verfügbar ist, zeigt die interaktive CLI unter 1. Network Configuration > DNS Configuration die globalen IPv4- und IPv6-DNS-Server. Dieser Menüpunkt ändert keine Request Routes. Vor einer Eingabe werden alle angezeigten Werte gesichert; Enter ohne neuen Wert überspringt die Änderung. Für eine Remote-Änderung bleibt ein unabhängiger Managementpfad offen.

DNS Protection mit internen Zonen kombinieren

Version zuerst wählen: Ab SFOS 23.0 den integrierten DoH-Pfad mit DNS Protection unter Network > DNS und der Filtering-Policy-Zuweisung zum Firewall-Objekt verwenden. Einrichtung, Fallback-Entscheid, Pilot und Rückweg beschreibt der unten verlinkte DNS-Protection-Artikel. Die folgende Location-/DDNS- und Static-DNS-Sequenz gilt ausschliesslich für Traditional DNS auf SFOS 22 und älter; beim integrierten SFOS-23-Pfad wird sie nicht zusätzlich ausgeführt. Interne Request Routes und die Clientpfad-/NAT-Prüfungen bleiben relevant.

Bei Sophos DNS Protection mit Sophos Firewall gehen öffentliche Anfragen an DNS Protection, während Request Routes interne Zonen an lokale Resolver senden. Dafür wird die Firewall zuerst als Location in Sophos Fusion (ehemals Sophos Central) registriert. Bei mehreren öffentlichen WAN-Adressen müssen alle verwendeten Adressen beziehungsweise der passende Bereich erfasst sein; bei einer dynamischen WAN-Adresse wird der registrierte DDNS-Hostname verwendet.

Die offizielle Sophos-Konfiguration setzt unter Network > DNS > DNS configuration die beiden DNS-Protection-Adressen als DNS 1 und DNS 2, lässt DNS 3 leer, entfernt IPv6-DNS-Server und wählt Choose IPv4 DNS server over IPv6. Ein dritter oder ein unbeabsichtigter IPv6-Resolver kann Anfragen an DNS Protection vorbeiführen.

Für DHCP nennt Sophos einen besonderen Pfad: Unter Network > DHCP > Server > Edit bleibt Use device’s DNS settings ausgeschaltet. Als Primary DNS wird die Firewall-IP des DHCP-Interfaces eingetragen, als Secondary DNS eine öffentliche DNS-Protection-Adresse. Da Clients die Verwendung mehrerer Resolver unterschiedlich handhaben können, muss geprüft werden, ob interne Anfragen wirklich über die Firewall laufen. Direkte Clientabfragen an DNS Protection verwenden die lokalen Request Routes der Firewall nicht.

Sophos beschreibt zusätzlich eine DNAT-Regel, die klassische ausgehende DNS-Anfragen interner Netze zur internen Firewall-IP umleitet. Diese Umleitung ist eine separate Sicherheitsentscheidung: Sie erfasst nicht automatisch DNS over HTTPS oder DNS over TLS und kann Sondergeräte beeinflussen. Sie wird nur mit klar benannten Quellnetzen, ohne WAN als Inbound Interface und mit einem dokumentierten Ausnahme- und Rückbauplan eingeführt.

Firewall und Client getrennt testen

Resolver-Sicht der Firewall

Unter Network > DNS > Test name lookup werden nacheinander dc01.ad.example.com und example.net geprüft. Der interne Name muss die erwartete interne Adresse liefern, der öffentliche Name weiterhin über den vorgesehenen Standardpfad auflösen.

In 4. Device Console ist derselbe Blick mit dem offiziell dokumentierten Befehl möglich:

dnslookup host dc01.ad.example.com
dnslookup host example.net

Diese Tests zeigen die Resolver-Sicht der Firewall. Sie beweisen noch nicht, dass ein Client die Firewall fragt.

Einzelne Resolver unter Diagnostics vergleichen

Unter Diagnostics > Tools bietet SFOS 22 Name lookup mit IP address or hostname und DNS server IP. Ein FQDN prüft die Forward-Auflösung, eine IPv4- oder IPv6-Adresse die Reverse-Auflösung. Einen konfigurierten Server gezielt auswählen oder mit Lookup using all configured servers Antworten und Antwortzeiten aller konfigurierten Resolver vergleichen. Eine kurze Antwortzeit allein rechtfertigt keine Änderung der Serverreihenfolge; zuerst müssen die Antworten zur vorgesehenen Zone passen.

In SFOS 23 heisst der Bereich DNS lookup, die Felder Hostname or IP address und DNS server IP address. Neben einem verfügbaren Server und All configured servers stehen Custom DNS server und Custom DoH server zur Verfügung; jeweils wird die IP-Adresse des gewünschten Servers eingegeben. DNS Protection ist nur auswählbar, wenn DNS Protection unter Network > DNS eingeschaltet ist. Das ist eine Diagnoseoption, keine Aufforderung, die bestehende DNS-Konfiguration für einen Test umzubauen.

Für interne Testnamen nur freigegebene interne Resolver verwenden, damit die Namen nicht an einen öffentlichen DNS- oder DoH-Dienst gelangen. Eine gezielte Resolverabfrage bestätigt dessen Antwort, nicht den tatsächlichen Request-Route- oder Clientpfad. Die Abnahme über die Firewall-IP und Packet Capture bleibt deshalb nötig.

Clientpfad nachweisen

Auf einem Testclient wird zuerst der eingetragene DNS-Server kontrolliert und danach ausdrücklich die Firewall-IP 10.20.30.1 abgefragt.

Windows:

ipconfig /all
nslookup dc01.ad.example.com 10.20.30.1
nslookup example.net 10.20.30.1

macOS oder Linux:

dig @10.20.30.1 dc01.ad.example.com A
dig @10.20.30.1 example.net A

Danach folgen dieselben Abfragen ohne expliziten Server. Weichen die Ergebnisse ab, verwendet der Client einen anderen Resolverpfad, etwa eine statische Einstellung, ein VPN-Profil, DNS over HTTPS oder einen lokalen Sicherheitsagenten. Eine Suchdomain ist nur für kurze, unqualifizierte Namen relevant; die oben verwendeten FQDNs benötigen sie nicht.

Packet Capture für den tatsächlichen Pfad

Unter Diagnostics > Packet capture grenzt ein Filter auf Testclient, Zielserver und Port 53 den Ablauf ein. Die genaue Bedienung erklärt Packet Capture auf Sophos Firewall.

(host 10.20.30.50 or host 10.10.10.10 or host 10.10.10.11) and port 53

Zu prüfen sind eingehende Clientanfrage, von der Firewall erzeugte Abfrage zum richtigen Target Server und die jeweilige Antwort. Das Capture unterscheidet damit einen fehlenden Clientzugriff von einem Routing- oder Zielserverproblem. Da der Capture-Puffer begrenzt ist, wird der Filter eng gesetzt und die Aufzeichnung nur für den Testlauf aktiviert.

Bei DNS Protection ergänzt der offizielle Check your configuration-Link unter My Products > DNS Protection > Installers die Prüfung. Die Willkommensseite bestätigt den DNS-Protection-Pfad; interne Zone, Clientpfad und Request Route werden trotzdem separat getestet.

Fehler nach Symptom eingrenzen

Firewall löst intern auf, Client aber nicht

• Kontrollieren, ob der Client wirklich die Firewall-IP als DNS-Server verwendet.
• Unter Administration > Device access prüfen, ob DNS für die Clientzone oder über eine passende Local Service ACL Exception erlaubt ist.
• Abfrage ausdrücklich an die Firewall-IP senden und mit Packet Capture bestätigen.
• DHCP-, VPN- und lokale Resolvereinstellungen sowie DoH/DoT als alternative Pfade prüfen.

Firewall erreicht den Target Server nicht

• Route Lookup und den lokalen oder VPN-Pfad zur Zieladresse prüfen.
• UDP und TCP Port 53 bis zum Zielserver sowie dessen eigene ACL kontrollieren.
• Den Resolver direkt abfragen und prüfen, ob er Anfragen von der Firewall-IP akzeptiert.
• Im Packet Capture auf eine erzeugte Anfrage, Antwort oder einen Drop-Grund achten.

Wenn Clients den internen DNS-Server direkt fragen, gilt stattdessen der normale Transitpfad mit Zonen und Firewallregel. Für diese Abgrenzung hilft Firewall-Regeln mit Log Viewer, Policy Test und Packet Capture prüfen.

Falsche oder wechselnde Antworten

• Domain zu breit oder falsch: Request Route auf die tatsächlich zuständige Zone begrenzen.
• Zielserver liefern verschiedene Daten: DNS-Replikation und Zonenautorität direkt auf jedem Server prüfen.
• Alte Antwort: TTL und Caches auf Firewall, Resolver und Client berücksichtigen.
• Nur kurze Namen scheitern: Suchdomain des Clients prüfen; den FQDN separat testen.
• Reverse Lookup scheitert: PTR-Zone und PTR-Record auf dem Zielserver prüfen.
• Nur VPN-Clients sind betroffen: Zugewiesene DNS-Server, VPN-Routing und Zugriff auf den lokalen DNS-Dienst prüfen. Die passenden Clientfelder stehen in Sophos Connect konfigurieren beziehungsweise SSL VPN Remote Access einrichten.

XML API: Route anhand des Objektnamens identifizieren

Ab SFOS 23 verlangt die XML-API-Dokumentation beim Anlegen und Bearbeiten einer DNS Request Route sowohl Name als auch DomainName. Name identifiziert das konfigurierte Objekt, DomainName die weiterzuleitende DNS-Zone; beispielsweise Name = ad-intern und DomainName = ad.example.com. Das sind Feldwerte, kein ausführbares XML. Name ist ein einzelner STRING mit maximal 64 Zeichen, erlaubt UTF-8 und verbietet Kommas. DomainName bleibt FQDN mit maximal 255 Zeichen; auch die Zielserver müssen weiter angegeben werden.

Beim Löschen wechselt der dokumentierte Schlüssel von DomainName in SFOS 22 zu Name in SFOS 23. Alte Anfragen nicht unverändert wiederholen und den Domainnamen nicht automatisch als Objektname übernehmen. Vorher die installierte Version prüfen und das konkrete Objekt lesen, Name, DomainName, Target Servers und Abhängigkeiten mit dem beabsichtigten Ziel vergleichen und den Rückweg dokumentieren. Bei Mehrdeutigkeit stoppen. Nachher API-Antwort und Status prüfen und das genaue Ziel erneut lesen: Nur die beabsichtigte Route darf entfernt sein; andere Routen müssen unverändert bleiben. Anschliessend interne und öffentliche Auflösung wie oben testen. Hier wird kein Lösch-Envelope oder REST-Schema erfunden und kein Produkttest behauptet.

Die globale DNS-Protokollkonfiguration ist davon getrennt. Der DNS-Protection-Artikel erklärt die offenen SFOS-23-XML-Schemakonflikte und den sicheren WebAdmin-Pfad; die vier oben ausdrücklich für SFOS 22 beschriebenen Resolveroptionen belegen keine numerische SFOS-23-API-Zuordnung.

XML API: SFOS 22 — Add/Edit; SFOS 23 — Add/Edit; SFOS 22 — Delete; SFOS 23 — Delete.

Rückbau und Betrieb

Vor der Änderung werden bestehende Request Routes, globale DNS-Auswahl, Device-Access-Freigaben und ein Positiv- sowie Negativtest festgehalten. Für den normalen Rückbau wird die neu angelegte Route entfernt oder auf die exakt dokumentierten vorherigen Werte zurückgesetzt. Temporäre ACL-Ausnahmen oder DNS-Umleitungen werden ebenfalls auf ihren Ausgangszustand gebracht.

Danach werden drei Dinge erneut geprüft:

1. Die Firewall löst einen internen und einen öffentlichen Namen über den vorgesehenen Pfad auf.
2. Der betroffene Client verwendet den vorgesehenen Resolver und erhält die erwarteten Antworten.
3. Eine nicht betroffene Domain wird nicht an den internen Target Server gesendet.

Ein vollständiges Konfigurationsbackup ist kein bequemer Einzelobjekt-Rollback: Ein Restore ersetzt die gesamte Konfiguration und kann spätere Änderungen überschreiben. Für eine einzelne Request Route ist die dokumentierte Objektänderung deshalb der sicherere Rückweg.

Häufige Fragen