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 paden en velden in deze handleiding komen overeen met SFOS 22.0 MR2 Build 546. In oudere releases kunnen labels enigszins afwijken.

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. Voor inbound load balancing van één naam zijn maximaal acht adressen mogelijk; de firewall ondersteunt in totaal maximaal 1024 DNS Host Entries.

Paden en bereik van DNS-resolutie

Voor aanvragen die de firewall zelf afhandelt, gelden de volgende configuraties:

• Komt de aangevraagde naam overeen met een DNS host entry, dan antwoordt de firewall met het daarin opgeslagen adres.
• Komt een DNS request route overeen, dan bevraagt de firewall na een mislukte cachelookup de opgegeven Target servers in de ingestelde volgorde. Voor die naam valt hij niet terug op forwarders of rootservers.
• Zonder overeenkomende lokale vermelding of Request Route gebruikt hij de servers onder DNS configuration. Statische servers worden op volgorde bevraagd totdat een antwoord binnenkomt. NXDOMAIN is al een geldig antwoord; de volgende server wordt dan niet bevraagd.

De SFOS 22-help beschrijft de overeenkomst met Host Entries en Request Routes afzonderlijk, maar vermeldt niet wat er gebeurt wanneer dezelfde naam met beide overeenkomt. Vermijd die overlap: houd een Host Entry buiten een doorgestuurde zone of verwijder de dubbele lokale vermelding. Vraag daarna expliciet het firewall-IP om het bedoelde antwoord te bevestigen.

Deze resolutiepaden gelden alleen wanneer de firewall de resolver van de aanvraag is. Een client die rechtstreeks een domain controller, openbare resolver of DNS over HTTPS gebruikt, omzeilt deze vermeldingen. Onder Administration > Device access moet DNS bovendien voor de bronzone of via een passende Local Service ACL Exception zijn toegestaan; een normale firewallregel regelt de toegang tot deze lokale dienst niet.

Geconfigureerde DNS-servers hebben bij algemene DNS-resolutie via het interface-IP van de firewall voorrang op rootservers. Dit garandeert niet dat elke mislukte aanvraag via rootservers wordt opgelost. Aanvragen die met een Request Route overeenkomen, blijven bij de vastgelegde Target Servers.

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

Gebruik eerst onder Network > DNS de optie Test name lookup om te controleren of de firewall voor app01.corp.example het verwachte adres teruggeeft. Diagnostics > Tools > Name lookup bevraagt daarentegen een geselecteerde DNS server IP; Lookup using all configured servers vergelijkt de geconfigureerde DNS-servers en hun responstijden. Gebruik deze tool alleen als upstreamvergelijking, niet als bewijs dat de lokale Host Entry of een Request Route overeenkwam. 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.

Voor overdracht aan support of een vergelijking voor en na de wijziging kan onder Diagnostics > Tools > Troubleshooting logs ook dnsd.log worden gedownload. Een Consolidated troubleshooting report (CTR) bevat daarnaast status- en loggegevens. Omdat deze bestanden configuratie- en omgevingsgegevens kunnen bevatten, mogen ze alleen via een veilig supportkanaal worden gedeeld.

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.

Voor twee WAN-adressen wordt dezelfde naam in één Host Entry beheerd: voer bijvoorbeeld www.example.com in bij Host/Domain name en 192.0.2.10 als eerste IP address, voeg vervolgens binnen het formulier met Add een tweede adres toe en voer daar 198.51.100.10 in. Dit zijn documentatieadressen die door de werkelijke WAN-adressen moeten worden vervangen. Schakel Publish on WAN alleen voor beide bedoelde adressen in als aan de voorwaarden in de volgende sectie is voldaan, en sla daarna op met Save. Twee verschillende hostnamen zouden geen lastverdeling voor dezelfde dienst bieden.

In het gedocumenteerde Multi-WAN-verloop volgt de externe resolver de NS-delegatie en bevraagt hij de firewall via een actieve WAN-link. De firewall geeft het WAN-adres terug van de interface waarop die aanvraag binnenkwam; de resolver geeft dit adres door aan de client. De daaropvolgende applicatietoegang is een afzonderlijke gegevensstroom. Bevraag bij de validatie daarom beide WAN-paden afzonderlijk en vergelijk de teruggegeven adressen; stuur na een linkuitval een nieuwe DNS-aanvraag. Hierdoor verdwijnen reeds gecachte antwoorden niet vóór het verlopen van hun TTL.

Weight is het relatieve gewicht van de link ten opzichte van de andere links in WAN link manager. Het is geen Health Check van de applicatie. Bij de validatie mogen nieuwe externe DNS-aanvragen alleen actieve WAN-adressen opleveren; test vervolgens voor elk teruggegeven adres een nieuwe applicatieverbinding. Een DNS-antwoord 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.

Volgens Sophos kunnen een DNAT-regel en weighted load balancing niet gelijktijdig voor dezelfde DNS Host Entry worden geconfigureerd. Publicatie vereist daarom 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.

Een naam blijft te lang als localhost in de cache staan

Voor domeinen die naar localhost worden omgezet, gebruikt Sophos Firewall niet simpelweg de TTL uit het DNS-record. De firewall vraagt deze namen opnieuw op volgens het interval localhost-ttl. De standaardwaarde is 655360 seconden en het toegestane bereik loopt van 60 tot 655360 seconden. Wanneer een record van localhost naar een andere host verandert, kan de firewall het oude antwoord daarom langer vasthouden dan een normale client.

Bevestig eerst met een rechtstreekse query aan de autoritatieve of bedoelde resolver dat het record niet meer naar localhost verwijst. Lees vervolgens de actuele SFOS-waarde in de Device Console:

show dns

Alleen wanneer precies dit geval is bevestigd, mag het globale interval tijdelijk worden verlaagd. 300 seconden is hier een voorbeeld voor een gecontroleerde migratietest, geen algemene aanbeveling:

set dns localhost-ttl 300

Een lagere waarde veroorzaakt vaker DNS-query’s en is geen onmiddellijke cacheflush. Test na de wijziging de naamomzetting opnieuw vanaf de firewall en een echte client. Als de verlaging alleen voor de migratie nodig was, herstel daarna de productstandaard:

set dns localhost-ttl default

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.

XML API: objectnaam en DNS-naam vanaf SFOS 23

Bij automatisering zijn Name en HostName verschillende velden: Name duidt het geconfigureerde object aan, HostName de DNS-naam die moet worden omgezet. De SFOS 23-documentatie vereist beide velden bij het aanmaken en bewerken. Name is één enkele STRING met maximaal 64 tekens; UTF-8 is toegestaan, een komma niet. HostName blijft DOMAINNAMELOOKUP met maximaal 253 tekens. Zo kunnen Name = app01-intern en HostName = app01.corp.example verschillende waarden hebben; dit is een veldtoewijzing, geen uitvoerbare XML.

Bij het verwijderen documenteert SFOS 22 HostName als sleutel, maar SFOS 23 Name. Herhaal oude SFOS 22-aanvragen daarom niet ongewijzigd en gebruik de DNS-naam niet automatisch als objectnaam. Controleer vóór een verwijderaanroep de geïnstalleerde versie, lees het concrete object uit en vergelijk de objectnaam, DNS-naam, adressen en afhankelijkheden met het gedocumenteerde doel. Stop als de identiteit niet eenduidig is. Controleer daarna het API-antwoord inclusief de status en lees het exacte doel opnieuw uit: alleen het bedoelde object mag ontbreken; andere vermeldingen moeten ongewijzigd blijven. Succesvol transport alleen bewijst niet dat het verwijderen is geslaagd. Hier wordt geen verwijder-envelope voorgeschreven en niet beweerd dat een producttest is uitgevoerd.

Onopgelost reverse-DNS-conflict: in beide versies toont het API-voorbeeld voor AddReverseDNSLookUp Enable/Disable, maar de parametertabel staat alleen Enable toe en noemt tegelijk Disable als standaardwaarde. Hieruit wordt geen veilige aanvraag met Disable of met weglating van het veld afgeleid. Gebruik tot opheldering door de fabrikant geen dergelijk API-recept; stel Reverse DNS in plaats daarvan bewust in via de hierboven beschreven WebAdmin-procedure en controleer het PTR-record afzonderlijk. De UI-instructies bevestigen geen API-enumsemantiek.

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

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