DNS Host Entries op Sophos Firewall instellen en testen

Met een DNS Host Entry kan Sophos Firewall een specifieke hostnaam rechtstreeks beantwoorden met een geconfigureerd IP-adres. Dit is geschikt voor enkele vaste interne systemen, zoals een appliance, een beheerdienst of een servernaam die de firewall zelf moet kunnen omzetten.

De vermelding werkt alleen wanneer de DNS-aanvraag daadwerkelijk bij de firewall aankomt. Als een client een domain controller, openbare resolver of DNS over HTTPS gebruikt, ziet de firewall die aanvraag niet als DNS-resolver. Een DNS Host Entry vervangt bovendien geen regelobject, routing, NAT of firewallregel.

⚠️ Publish on WAN blijft uitgeschakeld voor interne vermeldingen. Openbare publicatie vereist een bewust autoritatief DNS-ontwerp, passende NS-records, nauw begrensde Device Access en een negatieve recursietest. Alleen DNS-toegang via ACL vanuit WAN is geen reden om de DNS-service openbaar aan te bieden.

DNS Host Entry in acht stappen

1. Bevestigen dat de naam statisch is en dat geen volledige interne DNS-zone moet worden doorgestuurd.
2. Controleren of de betrokken clients Sophos Firewall daadwerkelijk als DNS-server gebruiken.
3. FQDN, doeladres, IP-versie, TTL en een optioneel PTR-record documenteren.
4. Onder Network > DNS > DNS host entry > Add de naam en het adres invoeren.
5. Publish on WAN voor een interne vermelding uitgeschakeld laten.
6. Onder Network > DNS > Test name lookup de resolverweergave van de firewall controleren.
7. Vanaf de client expliciet het firewall-IP bevragen en forward- en indien nodig reverse-resolutie testen.
8. Pas daarna de werkelijke applicatie testen en de vermelding met de afhankelijkheden documenteren.

Wanneer een DNS Host Entry geschikt is

Een DNS Host Entry is geschikt voor één stabiele naam waarvan het antwoord rechtstreeks op de firewall wordt beheerd. Typische voorbeelden zijn:

• een interne appliance zonder eigen DNS-record;
• een vaste beheer-FQDN voor LDAP, RADIUS of een andere dienst;
• één hostnaam voor een gecontroleerde migratie;
• een openbare dienst met bewust geplande inbound DNS load balancing over meerdere WAN-adressen.

Voor een volledig domein, Active Directory of dynamisch beheerde interne zones is een DNS Request Route overzichtelijker. Die stuurt de zone door naar de verantwoordelijke DNS-server in plaats van elke naam afzonderlijk op de firewall te beheren.

Ook een IP Host of FQDN Host dient een ander doel. Deze objecten worden gebruikt in firewall- en NAT-regels; ze beantwoorden geen DNS-aanvraag van een client. IP Hosts, Services en Groups correct gebruiken legt de objecttypen uit.

Een Dynamic DNS-configuratie werkt daarentegen een naam bij een externe provider bij wanneer een WAN-adres verandert. De volledige procedure staat in Dynamic DNS op Sophos Firewall configureren.

SFOS ondersteunt de recordtypen A, AAAA en PTR voor DNS Host Entries. De functie is daarmee geen volledige autoritatieve DNS-server voor CNAME, MX, TXT of SRV. Per DNS Host Entry zijn maximaal acht adressen mogelijk; de firewall ondersteunt in totaal maximaal 1024 DNS Host Entries.

Voorbeeld en te vervangen waarden

Het voorbeeld brengt één interne applicatieserver in kaart:

• Hostnaam: app01.corp.example
• IPv4-adres: 192.0.2.20
• Clientnetwerk: 10.20.30.0/24
• Firewall-IP als DNS-server: 10.20.30.1
• Testclient: 10.20.30.50
• TTL: 300 seconden
• Publish on WAN: uitgeschakeld
• Reverse DNS: optioneel ingeschakeld

De zone .example en 192.0.2.0/24 zijn gereserveerd voor documentatie. In een productieomgeving worden FQDN, adres, clientnetwerk en resolver-IP vervangen door de werkelijke waarden. De naam moet aansluiten bij de interne naamgevingsstrategie en mag niet onbedoeld een bestaande autoritatieve zone overschrijven.

De TTL van 300 seconden is een gecontroleerde voorbeeldwaarde voor tests en migraties, geen universele aanbeveling. Een korte TTL versnelt geplande wijzigingen, maar veroorzaakt meer DNS-aanvragen. Een lange TTL vermindert aanvragen, maar laat oude antwoorden na een wijziging langer in caches staan.

DNS Host Entry toevoegen

Ga onder Network > DNS naar DNS host entry en selecteer Add:

1. Voer bij Host/Domain name app01.corp.example in.
2. Gebruik een IP-adres als Entry type.
3. Voer bij IP address 192.0.2.20 in.
4. Voer bij Time-to-live 300 in.
5. Behandel Weight bij één adres niet als load-balancingfunctie.
6. Laat Publish on WAN uitgeschakeld.
7. Schakel Add reverse DNS lookup for this host entry alleen in wanneer de firewall voor dit adres ook een PTR-antwoord moet geven.
8. Sla op met Save.

Bij een IPv4-adres geeft de firewall een A-antwoord, bij een IPv6-adres een AAAA-antwoord. De optionele reverse lookup koppelt het adres als PTR terug aan de naam. Er wordt echter geen PTR-record op een domain controller of externe DNS-server aangemaakt.

Als meerdere hostnamen naar hetzelfde IP-adres verwijzen, kan slechts één daarvan het reverse-doel zijn. Voor het inschakelen moet daarom duidelijk zijn welke naam als canoniek PTR-antwoord wordt verwacht.

Een interface in plaats van een vast adres gebruiken

Als Entry Type kan in plaats van een vast IP-adres ook een interface worden geselecteerd. Dit is geschikt wanneer het antwoord bewust het actuele adres van die interface moet volgen, bijvoorbeeld in een gepland openbaar Multi-WAN-ontwerp.

De selectie van een interface vervangt de controle van het werkelijke WAN-pad niet. Na een adreswijziging, linkwissel of HA-failover moeten het DNS-antwoord, de bereikbare dienst en het retourpad opnieuw met een nieuwe verbinding worden getest.

Resolutie op firewall en client testen

Controleer eerst onder Network > DNS > Test name lookup of de firewall voor app01.corp.example het verwachte adres teruggeeft. Als Reverse DNS is ingeschakeld, wordt ook 192.0.2.20 bevraagd.

Deze test bevestigt alleen de resolverweergave van de firewall. Daarna moet de betrokken client expliciet het firewall-IP 10.20.30.1 bevragen.

Windows:

nslookup app01.corp.example 10.20.30.1
nslookup 192.0.2.20 10.20.30.1

Linux of macOS:

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

Het antwoord moet het verwachte record, het juiste adres en bij reverse lookup de bedoelde naam bevatten. Test daarna de applicatie via de FQDN. Een correct DNS-antwoord bewijst nog niet dat routing, firewallregel, NAT, TLS-certificaat en dienst werken.

Als onduidelijk is of de aanvraag de firewall bereikt, helpt onder Diagnostics > Packet capture een nauw filter, zoals:

host 10.20.30.50 and port 53

De aanvraag en het antwoord moeten op de verwachte interface zichtbaar zijn. Packet Capture op Sophos Firewall legt veilige opname en analyse gedetailleerd uit.

Meerdere adressen en gewichten bewust gebruiken

Een DNS Host Entry kan maximaal acht adressen bevatten. Dit is bedoeld voor inbound DNS load balancing of failover over meerdere WAN-links, niet voor een willekeurige verzameling interne servers.

De Weight-waarden bepalen de verhouding waarin antwoorden over de vermelde links worden verdeeld. Controleer dit gedrag met herhaalde DNS-aanvragen en echte applicatieverbindingen. De verdeling van DNS-antwoorden bevestigt op zichzelf noch de beschikbaarheid van de gepubliceerde dienst noch een correct DNAT- en retourpad.

Meerdere adressen vormen niet automatisch een algemene Health Check voor interne applicaties. Voor een openbaar ontwerp documenteert Sophos failover bij een onbereikbare of uitgevallen interface. Dit garandeert niet dat een bereikbare WAN-interface ook de applicatiedienst erachter correct levert.

Weighted DNS en de door Server Access Assistant gegenereerde DNAT-configuratie mogen niet gelijktijdig als één gezamenlijk mechanisme voor dezelfde DNS Host Entry worden gepland. Publicatie vereist een consistent ontwerp van DNS-antwoord, WAN-adres, DNAT, firewallregel, TLS en retourpad. Een server via DNAT publiceren legt het gegevenspad afzonderlijk uit.

Publish on WAN alleen voor autoritatieve ontwerpen gebruiken

Alleen Publish on WAN is niet voldoende voor een openbaar antwoord. Om Sophos Firewall als Name Server voor een gepubliceerde dienst te laten antwoorden, moet de autoritatieve zone gedelegeerd zijn aan nameservernamen waarvan de A-/AAAA- of glue-records naar de bedoelde WAN-adressen verwijzen.

Daarnaast zijn de volgende punten vereist:

1. Het openbare domein en de verantwoordelijke DNS-zone zijn eenduidig gedocumenteerd.
2. De NS-delegatie en bijbehorende adres- of glue-records leiden naar de bedoelde WAN-adressen.
3. Onder Administration > Device access is DNS alleen via de noodzakelijke WAN-zone of een nauw begrensde Local Service ACL Exception toegestaan.
4. Publish on WAN is alleen voor de bedoelde adressen ingeschakeld.
5. De gepubliceerde naam wordt vanaf een externe resolver positief getest.
6. Niet-autoritatieve namen en recursieve aanvragen worden van buitenaf negatief getest.
7. DNAT, firewallregel, certificaat en retourpad van de werkelijke dienst worden afzonderlijk gevalideerd.

Een extra DNS ACL-uitzondering beperkt een reeds actieve brede WAN-zonetoestemming niet. DNS blijft in de matrix voor WAN uitgeschakeld en wordt via een gerichte uitzondering toegestaan, of de bredere toestemming wordt als bewuste blootstelling gedocumenteerd. Device Access en Local Service ACL legt uit hoe deze laag zonder beheerlockout wordt aangepast.

Als de delegatie, het antwoordbereik of de bescherming tegen recursief gebruik niet duidelijk kan worden gecontroleerd, wordt Publish on WAN niet ingeschakeld. Voor gewone openbare DNS-zones is een daarvoor bedoelde autoritatieve DNS-service meestal de duidelijkere oplossing.

Fouten per symptoom afbakenen

Firewall lost op, maar client niet

• Controleer welke DNS-server daadwerkelijk op de client is ingesteld. DHCP kan daarvoor het firewall-IP uitdelen; de procedure staat in DHCP Server op Sophos Firewall configureren.
• Controleer DNS over HTTPS, VPN-clientinstellingen en statische resolvers op de client als alternatieve paden.
• Controleer onder Administration > Device access of DNS vanuit de clientzone is toegestaan.
• Bevestig met Packet Capture of aanvraag en antwoord via de firewall lopen.
• Wijzig routing of NAT niet zolang de client de firewall helemaal niet bevraagt.

De client ontvangt nog steeds het oude adres

• Controleer de huidige vermelding op typefouten, dubbele hostnamen en meerdere adressen.
• Houd rekening met de nog geldige oude TTL en lokale, browser- of applicatiecaches.
• Stuur een nieuwe expliciete aanvraag naar het firewall-IP in plaats van alleen de applicatie opnieuw te laden.
• Verlaag vóór een geplande migratie de TTL tijdig en laat de vorige TTL volledig verlopen.

Het legen van een cache kan één testclient opschonen, maar verandert geen antwoorden in andere resolvers of applicatiecaches. Het vervangt daarom geen gecontroleerde wachttijd en geen test via de daadwerkelijk gebruikte DNS-keten.

Reverse lookup ontbreekt of toont de verkeerde naam

• Controleer of Add reverse DNS lookup for this host entry is ingeschakeld.
• Zorg dat meerdere namen niet hetzelfde adres als PTR-doel claimen.
• Stuur de reverse-aanvraag expliciet naar het firewall-IP.
• Gebruik bij een interne reverse-zone op een domain controller de passende DNS Request Route in plaats van een lokale PTR-vermelding.

Openbare aanvraag krijgt geen antwoord

• Controleer de NS-delegatie en bereikbaarheid van de WAN-adressen van buitenaf.
• Controleer Publish on WAN voor elk bedoeld adres.
• Controleer Device Access, Local Service ACL, upstreamfilters en UDP- en TCP-poort 53.
• Leg tijdens één specifieke externe aanvraag een Packet Capture vast.
• Schakel geen brede DNS-toestemming in als poging tot oplossing.

DNS klopt, maar de applicatie blijft onbereikbaar

DNS levert alleen het doeladres. Daarna volgen routing, firewallregel, NAT, TLS en de eigenlijke dienst. De test moet daarom achtereenvolgens IP-adres, poort en applicatieprotocol controleren. Bij regel- en padproblemen helpt Een firewallregel testen met Log Viewer, Policy Test en Packet Capture.

Wijzigingen, HA en rollback

Documenteer vóór een wijziging de naam, het huidige antwoord, de TTL, reverse lookup, gebruikte clientresolvers en afhankelijke diensten. Bij meerdere adressen horen ook gewichten, WAN-toewijzing, NS-delegatie, DNAT en retourpad bij de uitgangssituatie.

Voer in een HA-cluster na een geplande failover een nieuwe DNS-aanvraag uit. Bij openbare publicatie worden bovendien beide WAN-paden en een nieuwe applicatiestroom getest. Dit artikel veronderstelt geen gesynchroniseerde DNS-caches en geen ononderbroken actieve verbinding.

Voor de rollback:

1. Verlaag voor een geplande migratie de TTL en wacht tot de vorige TTL is verlopen.
2. Documenteer afhankelijke applicaties en het openbare DNS-pad.
3. Zet adres, interface of Host Entry terug naar de bevestigde uitgangssituatie.
4. Verwijder een tijdelijke Device Access-uitzondering en niet langer benodigde WAN-publicatie.
5. Bevraag opnieuw expliciet vanaf de firewall en de client.
6. Test forward lookup, optionele PTR, bereikbaarheid en de werkelijke applicatie opnieuw.

Checklist

• Sophos Firewall ziet de DNS-aanvraag van de betrokken client.
• Eén statische naam past beter dan een DNS Request Route.
• FQDN, IP-versie, adres en TTL zijn gedocumenteerd.
• Publish on WAN blijft uitgeschakeld voor interne vermeldingen.
• Een PTR-vermelding is alleen voor de canonieke naam van het adres ingeschakeld.
• Firewall en client geven hetzelfde verwachte antwoord.
• DNS-toegang is in Device Access beperkt tot de noodzakelijke bronnen.
• Bij meerdere adressen zijn gewichten, linkstatus en applicatiepad getest.
• Bij WAN-publicatie zijn NS-delegatie, nameserveradressen en een negatieve recursietest gedocumenteerd.
• Rollback en cachewachttijd zijn vóór de wijziging bekend.

Veelgestelde vragen