DNS Host Entries auf Sophos Firewall einrichten und testen

Eine DNS Host Entry lässt die Sophos Firewall einen bestimmten Hostnamen direkt mit einer konfigurierten IP-Adresse beantworten. Das passt für wenige feste interne Systeme, etwa eine Appliance, einen Managementdienst oder einen Servernamen, den die Firewall selbst auflösen muss.

Der Eintrag wirkt nur, wenn die DNS-Anfrage tatsächlich bei der Firewall ankommt. Verwendet ein Client einen Domain Controller, einen öffentlichen Resolver oder DNS over HTTPS, sieht die Firewall diese Anfrage nicht als DNS-Resolver. Eine DNS Host Entry ersetzt ausserdem weder ein Regelobjekt noch Routing, NAT oder eine Firewallregel.

⚠️ Publish on WAN bleibt bei internen Einträgen ausgeschaltet. Eine öffentliche Veröffentlichung benötigt ein bewusstes autoritatives DNS-Design, passende NS-Einträge, eine enge Device-Access-Freigabe und einen negativen Rekursionstest. Eine DNS-ACL-Freigabe aus WAN allein ist kein Grund, den DNS-Dienst öffentlich bereitzustellen.

DNS Host Entry in acht Schritten

1. Bestätigen, dass der Name statisch ist und keine ganze interne DNS-Zone weitergeleitet werden muss.
2. Prüfen, ob die betroffenen Clients wirklich die Sophos Firewall als DNS-Server verwenden.
3. FQDN, Zieladresse, IP-Version, TTL und einen optionalen PTR-Eintrag dokumentieren.
4. Unter Network > DNS > DNS host entry > Add den Namen und die Adresse eintragen.
5. Publish on WAN für einen internen Eintrag ausgeschaltet lassen.
6. Unter Network > DNS > Test name lookup die Sicht der Firewall prüfen.
7. Vom Client explizit die Firewall-IP abfragen und Forward- sowie optional Reverse-Auflösung testen.
8. Erst danach die eigentliche Applikation testen und den Eintrag samt Abhängigkeiten dokumentieren.

Wann eine DNS Host Entry passt

Eine DNS Host Entry passt zu einem einzelnen, stabilen Namen, dessen Antwort direkt auf der Firewall gepflegt werden soll. Typische Beispiele sind:

• eine interne Appliance ohne eigenen DNS-Eintrag;
• ein fester Management-FQDN für LDAP, RADIUS oder einen anderen Dienst;
• ein einzelner Hostname für eine kontrollierte Migration;
• ein öffentlicher Dienst mit bewusst geplantem inbound DNS Load Balancing über mehrere WAN-Adressen.

Für eine ganze Domain, Active Directory oder dynamisch gepflegte interne Zonen ist eine DNS Request Route sauberer. Sie leitet die Zone an den zuständigen DNS-Server weiter, statt jeden Namen auf der Firewall einzeln zu pflegen.

Auch ein IP Host oder FQDN Host löst eine andere Aufgabe. Diese Objekte werden in Firewall- und NAT-Regeln verwendet; sie beantworten keine DNS-Anfrage eines Clients. Die Objekttypen erklärt IP-Hosts, Services und Gruppen richtig verwenden.

Eine Dynamic DNS-Konfiguration aktualisiert dagegen einen Namen bei einem externen Anbieter, wenn sich eine WAN-Adresse ändert. Der vollständige Ablauf steht unter Dynamic DNS auf Sophos Firewall konfigurieren.

SFOS unterstützt bei DNS Host Entries die Recordtypen A, AAAA und PTR. Die Funktion ist damit kein vollständiger autoritativer DNS-Server für CNAME, MX, TXT oder SRV. Pro DNS Host Entry sind höchstens acht Adressen möglich; insgesamt unterstützt die Firewall höchstens 1024 DNS Host Entries.

Beispiel und austauschbare Werte

Das Beispiel bildet einen einzelnen internen Applikationsserver ab:

• Hostname: app01.corp.example
• IPv4-Adresse: 192.0.2.20
• Clientnetz: 10.20.30.0/24
• Firewall-IP als DNS-Server: 10.20.30.1
• Testclient: 10.20.30.50
• TTL: 300 Sekunden
• Publish on WAN: ausgeschaltet
• Reverse DNS: optional aktiviert

Die Zone .example sowie 192.0.2.0/24 sind für Dokumentation reserviert. In einer produktiven Umgebung werden FQDN, Adresse, Clientnetz und Resolver-IP durch die tatsächlichen Werte ersetzt. Der Name sollte zur internen Namensstrategie passen und darf keine bestehende autoritative Zone unbeabsichtigt überschreiben.

Die TTL von 300 Sekunden ist ein kontrollierter Beispielwert für Test und Migration, keine universelle Vorgabe. Eine kurze TTL beschleunigt geplante Änderungen, erzeugt aber mehr DNS-Anfragen. Eine lange TTL reduziert Anfragen, lässt alte Antworten nach einer Änderung jedoch länger in Caches bestehen.

DNS Host Entry anlegen

Unter Network > DNS zum Abschnitt DNS host entry scrollen und Add wählen:

1. Unter Host/Domain name app01.corp.example eintragen.
2. Als Entry type eine IP-Adresse verwenden.
3. Unter IP address 192.0.2.20 eintragen.
4. Unter Time-to-live 300 eintragen.
5. Weight bei einer einzelnen Adresse nicht als Lastverteilungswerkzeug behandeln.
6. Publish on WAN ausgeschaltet lassen.
7. Add reverse DNS lookup for this host entry nur aktivieren, wenn die Firewall für diese Adresse auch eine PTR-Antwort liefern soll.
8. Mit Save speichern.

Bei einer IPv4-Adresse erzeugt die Firewall eine A-Antwort, bei einer IPv6-Adresse eine AAAA-Antwort. Der optionale Reverse Lookup bildet die Adresse als PTR wieder auf den Namen ab. Er erstellt jedoch keinen PTR-Record auf einem Domain Controller oder einem externen DNS-Server.

Wenn mehrere Hostnamen auf dieselbe IP-Adresse zeigen, darf nur einer davon als Reverse-Ziel dienen. Vor dem Aktivieren sollte deshalb klar sein, welcher Name als kanonische PTR-Antwort erwartet wird.

Interface statt fester Adresse verwenden

Als Entry Type kann statt einer festen IP auch ein Interface gewählt werden. Das passt, wenn die Antwort bewusst an die aktuelle Adresse dieses Interfaces gebunden sein soll, beispielsweise in einem geplanten öffentlichen Multi-WAN-Design.

Eine Interface-Auswahl ersetzt keine Prüfung des tatsächlichen WAN-Pfads. Nach einer Adressänderung, einem Linkwechsel oder HA-Failover müssen DNS-Antwort, erreichbarer Dienst und Rückweg mit einer neuen Verbindung erneut getestet werden.

Auflösung auf Firewall und Client testen

Zuerst wird unter Network > DNS > Test name lookup geprüft, ob die Firewall für app01.corp.example die erwartete Adresse zurückgibt. Wenn Reverse DNS aktiviert ist, wird zusätzlich 192.0.2.20 abgefragt.

Dieser Test bestätigt nur die Resolver-Sicht der Firewall. Danach muss der betroffene Client ausdrücklich die Firewall-IP 10.20.30.1 abfragen.

Windows:

nslookup app01.corp.example 10.20.30.1
nslookup 192.0.2.20 10.20.30.1

Linux oder macOS:

dig @10.20.30.1 app01.corp.example A
dig @10.20.30.1 -x 192.0.2.20

Die Antwort muss den erwarteten Record, die richtige Adresse und bei Reverse Lookup den vorgesehenen Namen enthalten. Anschliessend wird die Applikation über den FQDN getestet. Eine korrekte DNS-Antwort beweist noch nicht, dass Routing, Firewallregel, NAT, TLS-Zertifikat und Dienst funktionieren.

Wenn unklar ist, ob die Anfrage die Firewall erreicht, hilft unter Diagnostics > Packet capture ein enger Filter wie:

host 10.20.30.50 and port 53

Dabei müssen Anfrage und Antwort auf dem erwarteten Interface sichtbar sein. Packet Capture auf Sophos Firewall erklärt die sichere Aufzeichnung und Auswertung im Detail.

Mehrere Adressen und Gewichtung bewusst einsetzen

Eine DNS Host Entry kann bis zu acht Adressen enthalten. Das ist für inbound DNS Load Balancing oder Failover über mehrere WAN-Links gedacht, nicht für eine zufällige Sammlung interner Server.

Die Weight-Werte bestimmen das Verhältnis, in dem Antworten über die eingetragenen Links verteilt werden. Dieses Verhalten sollte mit wiederholten DNS-Abfragen und echten Applikationsverbindungen geprüft werden. DNS-Antwortverteilung allein bestätigt weder die Erreichbarkeit des veröffentlichten Dienstes noch den korrekten DNAT- und Rückwegpfad.

Mehrere Adressen werden nicht automatisch zu einem allgemeinen Health Check für interne Anwendungen. Bei einem öffentlichen Design dokumentiert Sophos Failover für eine nicht erreichbare oder ausgefallene Schnittstelle. Daraus folgt keine Garantie, dass eine erreichbare WAN-Schnittstelle auch den dahinterliegenden Applikationsdienst korrekt ausliefert.

Weighted DNS und die vom Server Access Assistant erzeugte DNAT-Konfiguration dürfen für dieselbe DNS Host Entry nicht gleichzeitig als ein gemeinsamer Automatismus geplant werden. Die Veröffentlichung benötigt ein konsistentes Design aus DNS-Antwort, WAN-Adresse, DNAT, Firewallregel, TLS und Rückweg. Server per DNAT veröffentlichen erklärt den Datenpfad getrennt.

Publish on WAN nur für autoritative Designs

Für eine öffentliche Antwort reicht Publish on WAN allein nicht. Damit die Sophos Firewall als Name Server für einen veröffentlichten Dienst antworten kann, muss die autoritative Zone an Nameserver-Namen delegiert sein, deren A-/AAAA- beziehungsweise Glue-Records auf die vorgesehenen WAN-Adressen zeigen.

Zusätzlich sind folgende Punkte erforderlich:

1. Die öffentliche Domain und die verantwortliche DNS-Zone sind eindeutig dokumentiert.
2. Die NS-Delegation und die zugehörigen Adress- beziehungsweise Glue-Records führen zu den vorgesehenen WAN-Adressen.
3. Unter Administration > Device access ist DNS nur über die notwendige WAN-Zone oder eine enge Local Service ACL Exception erlaubt.
4. Publish on WAN ist nur bei den vorgesehenen Adressen aktiviert.
5. Der veröffentlichte Name wird von einem externen Resolver positiv getestet.
6. Nicht autoritative Namen und rekursive Abfragen werden von extern negativ getestet.
7. DNAT, Firewallregel, Zertifikat und Rückweg des eigentlichen Dienstes werden separat abgenommen.

Eine zusätzliche DNS-ACL-Ausnahme verengt eine bereits aktivierte breite WAN-Zonenfreigabe nicht. Entweder bleibt DNS für WAN in der Matrix ausgeschaltet und wird über eine gezielte Ausnahme erlaubt, oder die breitere Freigabe wird als bewusste Exposition dokumentiert. Den lockout-sicheren Umgang mit dieser Ebene erklärt Device Access und Local Service ACL.

Wenn Delegation, Antwortumfang oder Schutz vor rekursiver Nutzung nicht eindeutig geprüft werden können, wird Publish on WAN nicht aktiviert. Für gewöhnliche öffentliche DNS-Zonen ist ein dafür betriebener autoritativer DNS-Dienst meist die klarere Lösung.

Fehler nach Symptom eingrenzen

Firewall löst auf, Client aber nicht

• Am Client prüfen, welcher DNS-Server tatsächlich eingetragen ist. DHCP kann dafür die Firewall-IP verteilen; der Ablauf steht unter DHCP Server auf Sophos Firewall konfigurieren.
• DNS over HTTPS, VPN-Client-Einstellungen und statische Resolver am Client als alternative Pfade prüfen.
• Unter Administration > Device access kontrollieren, ob DNS aus der Clientzone erlaubt ist.
• Mit Packet Capture bestätigen, ob Anfrage und Antwort über die Firewall laufen.
• Nicht an Routing oder NAT ändern, solange der Client die Firewall gar nicht fragt.

Der Client erhält weiterhin die alte Adresse

• Aktuellen Eintrag auf Tippfehler, doppelte Hostnamen und mehrere Adressen prüfen.
• Die noch gültige alte TTL und lokale, Browser- oder Applikations-Caches berücksichtigen.
• Eine neue explizite Abfrage an die Firewall-IP senden, statt nur die Anwendung neu zu laden.
• Vor einer geplanten Migration die TTL rechtzeitig reduzieren und die vorherige TTL vollständig ablaufen lassen.

Ein Cache-Flush kann einen einzelnen Testclient bereinigen, ändert aber keine Antworten in anderen Resolvern oder Applikations-Caches. Er ersetzt deshalb keine kontrollierte Wartezeit und keinen Test über die tatsächlich verwendete DNS-Kette.

Reverse Lookup fehlt oder zeigt den falschen Namen

• Prüfen, ob Add reverse DNS lookup for this host entry aktiv ist.
• Sicherstellen, dass nicht mehrere Namen dieselbe Adresse als PTR-Ziel beanspruchen.
• Die Reverse-Abfrage ausdrücklich an die Firewall-IP senden.
• Bei einer internen Reverse-Zone auf einem Domain Controller statt eines lokalen PTR-Eintrags die passende DNS Request Route verwenden.

Öffentliche Abfrage erhält keine Antwort

• NS-Delegation und Erreichbarkeit der WAN-Adressen von extern prüfen.
• Publish on WAN für jede vorgesehene Adresse kontrollieren.
• Device Access, Local Service ACL, Upstream-Filter und UDP sowie TCP Port 53 prüfen.
• Packet Capture während genau einer externen Abfrage aufzeichnen.
• Keine breite DNS-Freigabe als Versuchslösung aktivieren.

DNS stimmt, die Applikation bleibt unerreichbar

DNS liefert nur die Zieladresse. Danach folgen Routing, Firewallregel, NAT, TLS und der eigentliche Dienst. Der Test sollte deshalb nacheinander IP-Adresse, Port und Applikationsprotokoll prüfen. Für Regel- und Pfadprobleme hilft Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture.

Änderungen, HA und Rollback

Vor einer Änderung werden Name, aktuelle Antwort, TTL, Reverse Lookup, verwendete Client-Resolver und abhängige Dienste dokumentiert. Bei mehreren Adressen gehören zusätzlich Gewichtung, WAN-Zuordnung, NS-Delegation, DNAT und Rückweg in den Ausgangsstand.

In einem HA-Cluster wird nach einem geplanten Failover eine neue DNS-Abfrage durchgeführt. Bei öffentlicher Veröffentlichung werden ausserdem beide WAN-Pfade und ein neuer Applikationsfluss getestet. Der Artikel setzt weder synchronisierte DNS-Caches noch eine unterbrechungsfreie laufende Verbindung voraus.

Für den Rollback gilt:

1. Bei einer geplanten Migration die TTL vorab reduzieren und die bisherige TTL abwarten.
2. Abhängige Applikationen und öffentlichen DNS-Pfad dokumentieren.
3. Adresse, Interface oder Host Entry auf den bestätigten Ausgangsstand zurücksetzen.
4. Eine temporäre Device-Access-Ausnahme und nicht mehr benötigte WAN-Veröffentlichung entfernen.
5. Firewall und Client explizit neu abfragen.
6. Forward Lookup, optionalen PTR, Erreichbarkeit und tatsächliche Applikation erneut testen.

Checkliste

• Die Sophos Firewall sieht die DNS-Anfrage des betroffenen Clients.
• Ein einzelner statischer Name passt besser als eine DNS Request Route.
• FQDN, IP-Version, Adresse und TTL sind dokumentiert.
• Publish on WAN bleibt für interne Einträge ausgeschaltet.
• Ein PTR-Eintrag ist nur für den kanonischen Namen der Adresse aktiviert.
• Firewall und Client liefern dieselbe erwartete Antwort.
• DNS-Zugriff ist in Device Access auf die nötigen Quellen begrenzt.
• Bei mehreren Adressen sind Gewichtung, Linkzustand und Applikationspfad getestet.
• Bei WAN-Veröffentlichung sind NS-Delegation, Nameserver-Adressen und negativer Rekursionstest dokumentiert.
• Rollback und Cache-Wartezeit sind vor der Änderung bekannt.

Häufige Fragen