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.

Die Pfade und Felder in dieser Anleitung entsprechen SFOS 22.0 MR2 Build 546. In älteren Releases können Bezeichnungen leicht abweichen.

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. Für das Inbound Load Balancing eines Namens sind höchstens acht Adressen möglich; insgesamt unterstützt die Firewall höchstens 1024 DNS Host Entries.

DNS-Auflösungspfade und Geltungsbereich

Für Anfragen, die die Firewall selbst bearbeitet, kommen folgende Konfigurationen infrage:

• Passt der angefragte Name zu einer DNS host entry, beantwortet die Firewall ihn mit der dort hinterlegten Adresse.
• Passt eine DNS request route, fragt die Firewall nach einem erfolglosen Cache-Lookup die dort eingetragenen Target servers in ihrer Reihenfolge ab. Sie fällt für diesen Namen nicht auf Forwarder oder Root-Server zurück.
• Ohne passenden lokalen Eintrag oder Request Route verwendet sie die unter DNS configuration festgelegten Server. Statische Server werden der Reihe nach abgefragt, bis eine Antwort eintrifft. NXDOMAIN ist bereits eine gültige Antwort; dann wird der nächste Server nicht gefragt.

Die SFOS-22-Hilfe beschreibt die Auswertung von Host Entries und Request Routes getrennt, legt das Verhalten bei einer Überschneidung für denselben Namen aber nicht fest. Solche Überschneidungen werden deshalb vermieden: Eine Host Entry liegt ausserhalb einer weitergeleiteten Zone oder der doppelte lokale Eintrag wird entfernt. Anschliessend bestätigt eine explizite Abfrage an die Firewall-IP die beabsichtigte Antwort.

Diese Auflösungspfade gelten nur, wenn die Firewall Resolver der Anfrage ist. Ein Client, der direkt einen Domain Controller, öffentlichen Resolver oder DNS over HTTPS verwendet, umgeht diese Einträge. Unter Administration > Device access muss DNS ausserdem für die Quellzone beziehungsweise eine passende Local Service ACL Exception erlaubt sein; eine normale Firewallregel steuert den Zugriff auf diesen lokalen Dienst nicht.

Konfigurierte DNS-Server haben bei der allgemeinen DNS-Auflösung über die Interface-IP der Firewall Vorrang vor Root-Servern. Daraus folgt keine Garantie, dass jede erfolglose Anfrage über Root-Server aufgelöst wird. Für eine passende Request Route bleiben die Anfragen bei den festgelegten Target Servers.

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 mit Test name lookup geprüft, ob die Firewall für app01.corp.example die erwartete Adresse zurückgibt. Diagnostics > Tools > Name lookup fragt dagegen eine ausgewählte DNS server IP ab; Lookup using all configured servers vergleicht die konfigurierten DNS-Server und ihre Antwortzeiten. Dieses Werkzeug dient nur zum Upstream-Vergleich und belegt nicht, dass die lokale Host Entry oder eine Request Route gegriffen hat. 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.

Für die Übergabe an den Support oder einen Vergleich vor und nach der Änderung kann unter Diagnostics > Tools > Troubleshooting logs zusätzlich dnsd.log heruntergeladen werden. Ein Consolidated troubleshooting report (CTR) enthält darüber hinaus Status- und Logdaten. Da diese Dateien Konfigurations- und Umgebungsdetails enthalten können, werden sie nur über einen sicheren Supportkanal weitergegeben.

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.

Für zwei WAN-Adressen wird derselbe Name in einer Host Entry gepflegt: Unter Host/Domain name beispielsweise www.example.com und als erste IP address 192.0.2.10 eintragen, innerhalb der Maske mit Add eine zweite Adresse ergänzen und dort 198.51.100.10 eintragen. Die beiden Adressen sind Dokumentationswerte und werden durch die tatsächlichen WAN-Adressen ersetzt. Nur wenn die Voraussetzungen im folgenden Abschnitt zu Publish on WAN erfüllt sind, wird die Option für beide vorgesehenen Adressen aktiviert; danach mit Save speichern. Zwei unterschiedliche Hostnamen wären keine Lastverteilung für denselben Dienst.

Im dokumentierten Multi-WAN-Ablauf folgt der externe Resolver der NS-Delegation und fragt die Firewall über einen aktiven WAN-Link. Die Firewall liefert dabei die WAN-Adresse der Schnittstelle zurück, über die diese Anfrage angekommen ist; der Resolver gibt diese Adresse an den Client weiter. Der anschliessende Applikationszugriff ist ein eigener Datenfluss. Für die Abnahme werden deshalb beide WAN-Pfade separat abgefragt und mit den zurückgegebenen Adressen verglichen; nach einem Linkausfall wird eine neue DNS-Abfrage benötigt. Bereits gecachte Antworten verschwinden dadurch nicht vor Ablauf ihrer TTL.

Weight ist die relative Gewichtung des jeweiligen Links gegenüber den anderen Links im WAN link manager. Sie ist kein Health Check der Anwendung. Bei der Prüfung müssen neue externe DNS-Abfragen nur aktive WAN-Adressen liefern; anschliessend wird für jede gelieferte Adresse eine neue Applikationsverbindung getestet. Eine DNS-Antwort 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.

Eine DNAT-Regel und weighted load balancing dürfen laut Sophos nicht gleichzeitig für dieselbe DNS Host Entry konfiguriert werden. Die Veröffentlichung benötigt deshalb 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.

Ein Name bleibt nach localhost zu lange gecacht

Für Domains, die auf localhost auflösen, verwendet Sophos Firewall nicht einfach die TTL des DNS-Records. Die Firewall fragt solche Namen im Intervall localhost-ttl erneut ab. Der Standardwert beträgt 655360 Sekunden; erlaubt sind 60 bis 655360 Sekunden. Wird ein Record von localhost auf einen anderen Host geändert, kann die Firewall deshalb länger als ein normaler Client bei der alten Antwort bleiben.

Zuerst wird mit einer direkten Abfrage am autoritativen oder vorgesehenen Resolver bestätigt, dass der Record wirklich nicht mehr auf localhost zeigt. Danach in der Device Console den aktuellen SFOS-Wert lesen:

show dns

Nur wenn genau dieser Sonderfall belegt ist, kann man das globale Intervall vorübergehend reduzieren. 300 Sekunden sind hier ein Beispiel für einen kontrollierten Migrationstest, keine allgemeine Empfehlung:

set dns localhost-ttl 300

Ein kleinerer Wert erzeugt häufigere DNS-Abfragen und ist kein sofortiger Cache-Flush. Nach der Änderung wird die Auflösung aus Sicht der Firewall und eines echten Clients erneut geprüft. War die Reduktion nur für die Migration nötig, stellt man anschliessend den Produktstandard wieder her:

set dns localhost-ttl default

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.

XML API: Objektname und DNS-Name ab SFOS 23

Bei der Automatisierung sind Name und HostName unterschiedliche Felder: Name bezeichnet das konfigurierte Objekt, HostName den aufzulösenden DNS-Namen. Die SFOS-23-Dokumentation verlangt beim Anlegen und Bearbeiten beide Felder. Name ist ein einzelner STRING mit maximal 64 Zeichen; UTF-8 ist erlaubt, ein Komma nicht. HostName bleibt DOMAINNAMELOOKUP mit maximal 253 Zeichen. Beispielsweise können Name = app01-intern und HostName = app01.corp.example verschiedene Werte haben; das ist eine Feldzuordnung, kein ausführbares XML.

Beim Löschen dokumentiert SFOS 22 HostName als Schlüssel, SFOS 23 dagegen Name. Alte SFOS-22-Anfragen deshalb nicht unverändert wiederholen und den DNS-Namen nicht automatisch als Objektname einsetzen. Vor einem Löschaufruf die installierte Version prüfen, das konkrete Objekt lesen und Objektname, DNS-Name, Adressen und Abhängigkeiten mit dem dokumentierten Ziel vergleichen. Bei uneindeutiger Identität stoppen. Danach die API-Antwort samt Status prüfen und das genaue Ziel erneut lesen: Nur das beabsichtigte Objekt darf fehlen; andere Einträge müssen unverändert bleiben. Ein Transporterfolg allein belegt keine erfolgreiche Löschung. Hier wird kein Lösch-Envelope vorgegeben und kein Produkttest behauptet.

Offener Reverse-DNS-Konflikt: In beiden Versionen zeigt das API-Beispiel für AddReverseDNSLookUp Enable/Disable, die Parametertabelle erlaubt aber nur Enable und nennt zugleich Disable als Default. Daraus wird keine sichere Disable- oder Weglassungsanfrage abgeleitet. Bis zur Herstellerklärung keine solche API-Rezeptur einsetzen; Reverse DNS stattdessen bewusst im oben beschriebenen WebAdmin-Ablauf setzen und den PTR separat prüfen. Die UI-Anleitung bestätigt keine API-Enum-Semantik.

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

Ä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