DNS-aanvraagroutes configureren op Sophos Firewall

Met DNS-aanvraagroutes kunt u op de Sophos Firewall bepalen welke DNS-server voor specifieke domeinen of reverse-zones moet worden gebruikt. Dit is vooral nuttig wanneer de firewall openbare DNS-servers gebruikt, maar interne namen via een interne DNS-server moeten worden opgelost.

Typische voorbeelden zijn Active Directory-domeinen, interne applicaties, reverse-lookups of VPN-omgevingen.

Wanneer Sophos DNS Protection met Sophos Firewall wordt gebruikt, worden DNS-aanvraagroutes nog belangrijker. Openbare domeinen gaan dan naar de DNS Protection-dienst, maar interne domeinen blijven naar de lokale DNS-server of domeincontroller gaan. Zonder deze scheiding kunnen interne applicaties, AD-aanmeldingen of reverse-lookups plotseling als netwerkproblemen lijken.

Oriëntatie en ontwerp

DNS Request Routes werken alleen betrouwbaar als duidelijk is welke resolver welke aanvraag ziet. Daarom moet men eerst DNS-ontwerp, client-DNS, interne zones en het routingpad van elkaar scheiden.

DNS-aanvraagroute, DNS-server of DHCP-optie?

DNS-aanvraagroutes worden vaak verward met globale DNS-servers of DHCP-opties. De functies lossen verschillende problemen op.

• Globale DNS-servers: standaardresolutie van de firewall voor internet-DNS, algemene FQDN-resolutie, updates en clouddiensten.
• DNS Request Route: stuurt specifieke domeinen of reverse-zones door naar gedefinieerde DNS-servers. Typisch zijn Active Directory, interne domeinen, locatie-DNS en split DNS.
• DHCP-optie: deelt DNS-servers of zoekdomeinen uit aan clients. Dat is relevant wanneer clients direct een specifieke DNS-server moeten gebruiken.

Een DNS-aanvraagroute wijzigt dus niet automatisch de DNS-configuratie van alle clients. De route bepaalt waar de Sophos Firewall zelf of clients die de firewall als DNS-forwarder gebruiken, specifieke DNS-aanvragen naartoe sturen. Als clients direct een interne DNS-server moeten gebruiken, is een DHCP-optie op Sophos Firewall meer geschikt.

Belangrijk is ook het verschil met een DNS Host Entry: een DNS Host Entry beantwoordt een specifieke hostnaam direct met een IP-adres op de firewall. Een DNS Request Route stuurt daarentegen een domein of zone door naar een andere DNS-server. Voor Active Directory en dynamische interne zones is een Request Route bijna altijd netter dan veel losse Host Entries.

Welk DNS-ontwerp past?

Voordat u een DNS-aanvraagroute aanmaakt, moet duidelijk zijn welke resolver in het betreffende netwerk wordt gebruikt. De route helpt alleen als de Sophos Firewall de aanvraag ook ziet.

• Clients vragen de Sophos Firewall: de firewall stuurt openbare domeinen globaal door en interne domeinen via DNS Request Route. Dat past goed voor kleine en middelgrote locaties, DNS Protection en gast- of clientnetwerken.
• Clients vragen interne DNS-servers direct: Domain Controllers of DNS-servers lossen intern op en sturen extern door. Dat past voor klassieke Active Directory-netwerken met Windows-DNS als centrale resolver.
• VPN-clients vragen de firewall: de firewall gebruikt Request Routes voor interne domeinen. Dat past voor Remote Access met een eenvoudig DNS-pad via de firewall.
• VPN-clients vragen interne DNS-servers direct: DNS loopt via VPN naar de Domain Controller of DNS-server. Dat past voor grotere AD-omgevingen wanneer clients dezelfde DNS-logica als in het LAN moeten gebruiken.

In gemengde omgevingen is een korte DNS-schets zeer nuttig: clientnetwerk, toegewezen DNS-server, zoekdomein, interne DNS-zones, DNS-aanvraagroutes en routeringspad naar de doelserver. Zonder dit overzicht wordt later vaak aan de aanvraagroute gewerkt, hoewel de client de firewall helemaal niet als DNS-resolver gebruikt.

Opdat DNS Request Routes voor clients werken, moet de Sophos Firewall als DNS-server in het querypad liggen. Dat kan direct zijn, wanneer clients het interface-IP van de firewall als DNS-server krijgen, of indirect, wanneer een interne resolver bewust naar de firewall doorstuurt. Wanneer clients direct een Domain Controller vragen, ziet de firewall deze DNS-aanvraag niet als resolver en kan zij die ook niet via een Request Route omleiden.

Wanneer zijn DNS-aanvraagroutes nodig?

DNS-aanvraagroutes zijn nuttig wanneer:

• interne hostnamen zoals server01.firma.local moeten worden opgelost
• reverse-lookups voor interne IP-netwerken moeten werken
• VPN-gebruikers interne namen moeten gebruiken
• meerdere locaties hun eigen DNS-zones hebben
• de firewall zelf interne systemen via FQDN moet bereiken
• openbare DNS-servers geen interne namen kennen

Zonder DNS-aanvraagroute vraagt de firewall de globaal geconfigureerde DNS-server. Als daar het interne domein niet bekend is, mislukt de resolutie.

Dit verschil is vooral belangrijk bij Remote Access. Als VPN-clients de firewall als DNS-server gebruiken, kan een DNS-aanvraagroute ervoor zorgen dat interne domeinen toch bij de juiste domeincontroller of DNS-server terechtkomen. Als VPN-clients daarentegen direct interne DNS-servers ontvangen, moet ook worden gecontroleerd of routering, firewallregels en DNS-suffixen op de client correct zijn.

Vereisten

• Toegang tot de WebAdmin van de Sophos Firewall
• Sophos Firewall is onder Network > DNS > DNS configuration correct geconfigureerd als DNS-resolver of DNS-forwarder
• Interne DNS-server is bereikbaar
• Domein of netwerk is bekend
• Firewallregels staan DNS-verkeer naar de doelserver toe
• Bij locatieverbinding: routering naar de DNS-server werkt
• De betreffende client gebruikt ofwel de firewall als DNS-server of ontvangt bewust een andere DNS-server

⚠️ DNS-problemen lijken vaak op routerings-, VPN- of applicatieproblemen. Voor grotere wijzigingen moet worden gecontroleerd of de doelserver via IP bereikbaar is en of alleen de naamresolutie mislukt.

Onder Network > DNS > DNS configuration moet daarnaast worden gecontroleerd hoe de firewall haar normale DNS-aanvragen oplost. Wanneer DNS Protection wordt gebruikt, staan daar de DNS-Protection-IP-adressen. Wanneer klassieke forwarders of interne resolvers worden gebruikt, moeten deze servers bereikbaar zijn. Via Test name lookup kan men direct in de DNS-configuratie controleren of de firewall een naam of IP-adres principieel kan oplossen.

DNS Request Route configureren

De configuratie is technisch eenvoudig, maar wordt snel onoverzichtelijk wanneer domeinen, reverse-zones, VPN-clients en meerdere locaties samenkomen.

DNS-aanvraagroute voor een domein maken

Een domeinroute zorgt ervoor dat aanvragen voor een specifiek domein naar een gedefinieerde DNS-server worden gestuurd.

Voorbeeld:

• Host/domeinnaam: firma.local
• DNS-server: 10.10.10.10

Werkwijze:

1. Aanmelden bij de Sophos Firewall.
2. Network > DNS openen.
3. Naar het gedeelte DNS request route gaan.
4. Add selecteren.
5. Bij Host/domain name het interne domein invoeren, bijvoorbeeld firma.local.
6. Bij Target servers de interne DNS-server selecteren of via Create als host aanmaken.
7. Opslaan.

De waarde in Host/domain name moet eruitzien als een FQDN of zonenaam, niet als een URL, wildcardregel of vrije beschrijving. De Sophos API behandelt deze waarde als een FQDN-veld met maximaal 255 tekens. Voor normale domeinroutes is bijvoorbeeld firma.local genoeg; voor reverse-lookups gebruikt men de passende in-addr.arpa-zone.

Wanneer er geen DNS-cachehit op de firewall is, wordt de passende aanvraag voor dit domein niet naar de normale forwarders of rootservers gestuurd, maar naar de Target Servers van de Request Route. Dat is de bedoeling: interne zones mogen niet per ongeluk extern worden opgevraagd. Het betekent echter ook dat een verkeerd gekozen Target Server de aanvraag technisch netjes kan beantwoorden, maar inhoudelijk toch fout kan zijn.

Meerdere doelservers gebruiken

Onder Target servers kunt u meer dan één DNS-server toevoegen. Dit is nuttig als er meerdere interne DNS-servers zijn of als DNS via een locatieverbinding redundant bereikbaar moet zijn.

Mogelijke doelservers:

• Interne DNS-servers in het lokale netwerk
• DNS-servers aan de andere kant van een VPN-verbinding
• DNS-servers op een andere locatie
• Openbare DNS-servers, als een specifiek domein bewust extern moet worden opgelost

De volgorde is relevant. De firewall vraagt de geselecteerde hosts in de volgorde op waarin ze in de lijst staan. Per DNS-aanvraagroute kunnen maximaal acht IP-adressen worden opgeslagen. Meer doelservers betekenen echter niet automatisch betere redundantie, als de servers verschillende zonegegevens, verschillende doorverwijzingen of verschillende bereikbaarheid via VPN hebben.

Bij meerdere doelservers moet niet alleen redundantie worden ingevoerd, maar ook de verantwoordelijkheid worden gecontroleerd. Als de eerste DNS-server de zone wel kent, maar verouderde records levert, zal de aanvraagroute technisch werken en toch verkeerde antwoorden geven.

Een NXDOMAIN is vanuit DNS-perspectief een geldig antwoord. Wanneer de eerste bereikbare DNS-server zegt dat een naam niet bestaat, vraagt de firewall niet automatisch de volgende server in de hoop op een ander antwoord. Daarom moeten Target Servers voor dezelfde Request Route dezelfde zonestand en dezelfde forwarders hebben.

Split DNS voor VPN en locaties

Split DNS betekent dat dezelfde naam afhankelijk van de locatie of het netwerk anders wordt opgelost. Een intern portaal kan intern bijvoorbeeld naar een privé-IP verwijzen, terwijl dezelfde naam extern naar een openbaar adres verwijst of helemaal niet wordt opgelost.

Op de Sophos Firewall zijn hiervoor drie punten cruciaal:

1. De juiste DNS-aanvraagroute voor het interne domein.
2. Een firewallregel die DNS van de firewall of van de client naar de interne DNS-server toestaat.
3. Een routeringspad naar de DNS-server, vooral bij Site-to-Site VPN, SSL VPN of Sophos Connect.

Voor Remote Access-omgevingen moet u ook controleren welke DNS-servers en zoekdomeinen de client ontvangt. Bij Sophos Connect past Sophos Connect op Sophos Firewall configureren. Bij klassieke SSL-VPN-setups past Sophos Firewall SSL VPN Remote Access instellen.

Bij DNS Protection komt daar een extra ontwerpvraag bij: Sophos adviseert netwerkapparaten zo te configureren dat zij de firewall als DNS-resolver gebruiken. Daarvoor wordt in de DHCP-servers van de firewall normaal gesproken het interface-IP van de firewall als DNS-server uitgedeeld. Wanneer apparaten toch externe resolvers gebruiken, kan men een gerichte NAT-regel voor uitgaand DNS-verkeer naar de firewall plannen. Dat moet bewust gebeuren en niet algemeen, omdat harde DNS-omleidingen troubleshooting, BYOD-apparaten, DoH/DoT en speciale apparaten kunnen beïnvloeden.

Als de firewall zelf DNS Protection als forwarder gebruikt, moeten de uit Sophos Central gekopieerde DNS Protection-IP-adressen onder Network > DNS > DNS configuration als primaire en secundaire DNS-server worden ingevoerd. Een afwijkende derde DNS-server of een onbedoeld IPv6-DNS-pad kan ertoe leiden dat aanvragen DNS Protection omzeilen. Daarom moeten DNS Request Routes, DHCP-DNS-opties, IPv6-DNS-instellingen en optionele DNS-NAT-regels als één gezamenlijk ontwerp worden gecontroleerd.

Reverse DNS voor interne netwerken

Een reverse-DNS-aanvraagroute stuurt PTR-aanvragen voor een intern IP-netwerk naar de DNS-server die de juiste reverse lookup-zone kent. Dit helpt wanneer logs, rapporten of diensten van een IP-adres weer een hostnaam moeten maken.

Voorbeeld:

• Netwerk: 172.16.16.0/24
• DNS-server: 172.16.16.10
• Reverse-zone: 16.16.172.in-addr.arpa

Voor reverse-lookups maakt u ook een DNS-aanvraagroute onder Network > DNS > DNS request route. Bij Host/domain name voert u echter niet de normale domeinnaam in, maar de reverse-zone.

Voorbeeld voor 172.16.16.0/24:

16.16.172.in-addr.arpa

De volgorde van de octetten is daarbij omgekeerd. Uit het netwerk 172.16.16.0/24 wordt dus 16.16.172.in-addr.arpa. Belangrijk: in Host/domain name wordt geen CIDR-notatie zoals 172.16.16.0/24 ingevuld, maar een DNS-zone. De waarde moet er dus uitzien als een domein- of reverse-zonenaam, niet als een vrije beschrijving.

Voor grotere netwerken kan de reverse-zone breder zijn. Voorbeeld: Voor 172.16.0.0/16 zou het 16.172.in-addr.arpa zijn. Doorslaggevend is hoe de reverse lookup-zone op de interne DNS-server is aangemaakt.

Als er op de interne DNS-server geen PTR-zone of PTR-records bestaan, helpt de aanvraagroute ook niet. De firewall kan de aanvraag alleen naar de juiste DNS-server sturen, maar genereert geen reverse-DNS-records op de DNS-server.

Bij IPv6-omgevingen met providerprefix moet DNS ook vroeg worden meegenomen. Hoe clients hun IPv6-adres ontvangen en welke rol routeradvertenties en DHCPv6 spelen, staat in IPv6 Prefix Delegation op Sophos Firewall configureren.

Tests en beheer

Na de configuratie moet men IP-bereikbaarheid, DNS-resolutie en client-DNS gescheiden testen. Zo ziet men sneller of het probleem werkelijk bij de Request Route ligt.

Tests en validatie

Na de configuratie moet u de naamresolutie testen:

• Kan de firewall de interne naam oplossen?
• Werkt Network > DNS > Test name lookup voor een interne en een openbare naam?
• Werkt de resolutie vanuit VPN- of gebruikerszones?
• Is de DNS-server bereikbaar via ping of TCP/UDP 53?
• Zijn er vermeldingen in het DNS- of firewall-logboek?

Als de resolutie niet werkt, moet u eerst controleren:

• Is de domeinnaam correct gespeld?
• Gebruikt de client echt de Sophos Firewall of de juiste DNS-server?
• Blokkeert een firewallregel DNS?
• Ontbreekt er een route naar de DNS-server?
• Beantwoordt de DNS-server aanvragen van de firewall?

Een zinvolle test scheidt IP-bereikbaarheid en DNS-resolutie:

1. Doelsysteem testen via IP, bijvoorbeeld ping, TCP-poort of applicatie.
2. DNS-server zelf via IP bereiken.
3. Namen oplossen via de verwachte DNS-bron.
4. Daarna pas de applicatie via de naam testen.

Als de toegang via IP werkt, maar via naam niet, ligt de focus op DNS-aanvraagroute, DNS-suffix, client-DNS of reverse lookup. Als de toegang via IP al mislukt, moet u eerst routering, firewallregel, NAT of VPN controleren. Voor deze afbakening helpen Firewall-regel testen met Log Viewer, Policy Test en Packet Capture en Sophos Firewall-regel grijpt niet: oorzaken controleren.

Testcommando’s voor firewall en clients

Op de Sophos Firewall kan de Device Console helpen om DNS vanuit het perspectief van de firewall te testen:

dnslookup server01.firma.local
dnslookup example.com

Op clients moet u daarnaast controleren welke resolver echt wordt gebruikt.

Windows:

ipconfig /all
nslookup server01.firma.local
nslookup server01.firma.local <firewall-ip>
Resolve-DnsName server01.firma.local

macOS:

scutil --dns
dig server01.firma.local
dig @<firewall-ip> server01.firma.local

Linux:

resolvectl status
dig server01.firma.local
dig @<firewall-ip> server01.firma.local

<firewall-ip> staat daarbij voor het interne interface-adres van de Sophos Firewall in het betreffende netwerk. Als de aanvraag tegen de firewall werkt, maar de normale clientaanvraag niet, ligt het probleem meestal bij DHCP, VPN-profiel, DNS-suffix, lokale resolver of browser-/systeem-DNS-gedrag. Als ook de aanvraag tegen de firewall mislukt, zijn aanvraagroute, doelserver, routering of firewallregel de volgende controlepunten.

Bij clients met moderne browsers of endpoint-agenten moet men daarnaast controleren of DNS-over-HTTPS of een lokale security-agent de normale DNS-aanvraag omzeilt. Dan ziet de firewall mogelijk geen klassieke DNS-request op UDP/TCP 53, hoewel de netwerkconfiguratie correct lijkt.

Positieve en negatieve test definiëren

Een DNS Request Route is pas goed getest als niet alleen de gewenste interne naam werkt, maar ook een tegenvoorbeeld is gecontroleerd. Anders blijft onduidelijk of de route precies de interne zone raakt of DNS onbedoeld te breed wordt omgeleid.

Een kort testplan is meestal voldoende:

• Positieve test: een interne naam uit de doelzone resolveert naar het verwachte private IP-adres, bijvoorbeeld server01.ad.firma.local.
• Negatieve test: een niet-betrokken publiek domein blijft via het bedoelde standaardpad lopen, bijvoorbeeld globale DNS, DNS Protection of een interne forwarder.
• Clienttest: voer de test uit vanuit de betrokken VLAN, VPN-profiel of locatie, niet alleen direct op de firewall.
• Logcheck: firewall-log, DNS-log of Packet Capture toont dat de aanvraag de verwachte resolver bereikt.
• Regressie: herhaal dezelfde test na wijzigingen aan VPN, DHCP, DNS Protection of site-routing.

Deze kleine negatieve test voorkomt typische neveneffecten: publieke domeinen worden intern beantwoord, DNS Protection wordt omzeild, Split-DNS werkt alleen vanuit sommige netwerken of een VPN-client gebruikt nog steeds een oude resolver.

Bedrijfscontrole

DNS Request Routes moeten zo specifiek mogelijk zijn. Een route voor het exacte interne domein is beter dan een te brede configuratie. Voor grotere omgevingen is een korte documentatie met domein, DNS-server, locatie en doel nuttig, zodat latere wijzigingen traceerbaar blijven.

Praktische documentatie:

• Domein of reverse-zone: bijvoorbeeld ad.firma.local.
• Target Servers: bijvoorbeeld 10.10.10.10 en 10.10.10.11.
• Doel: bijvoorbeeld Active Directory DNS voor de hoofdlocatie.
• Betrokken netwerken: bijvoorbeeld LAN, Admin-VPN en locatie Zürich.
• Afhankelijkheden: bijvoorbeeld Site-to-Site VPN, Domain Controller en firewallregel voor DNS.
• Test: bijvoorbeeld server01.ad.firma.local lost op naar het verwachte interne IP-adres.
• Negatieve test: bijvoorbeeld example.com gebruikt nog steeds het bedoelde standaardpad.

Troubleshooting

Wanneer DNS niet werkt, moet men niet direct de Request Route aanpassen. Vaak gebruikt de client een andere resolver, blokkeert een firewallregel DNS of bestaat de reverse-zone niet op de doelserver.

Typische fouten

• Interne naam lost niet op: Vaak is het domein fout, bijvoorbeeld firma.local in plaats van ad.firma.local. Domein in de Request Route en zoekdomein van de client controleren.
• VPN-client lost interne namen niet op: De client gebruikt mogelijk niet de firewall of de verkeerde DNS-server. VPN-DNS-instellingen, client-DNS en firewallregel controleren.
• Firewall kan DNS-server niet bereiken: Route, VPN of firewallregel ontbreekt waarschijnlijk. Ping, Packet Capture en Route Lookup controleren.
• Firewall lost extern wel op, maar intern niet: DNS Request Route, Target Server en Test name lookup controleren. Daarna Packet Capture richting interne DNS-server gebruiken.
• Reverse lookup werkt niet: PTR-zone of PTR-records ontbreken. Reverse Lookup Zone op de interne DNS-server controleren.
• Afzonderlijke locaties geven verkeerde antwoorden: Verkeerde Target Server of verouderde zonedata zijn waarschijnlijk. Volgorde van de Target Servers en DNS-replicatie controleren.
• Openbare namen worden plotseling intern beantwoord: De Request Route is te breed. Specifieker domein gebruiken en wildcard-denken vermijden.
• Eerste DNS-server antwoordt NXDOMAIN: De firewall behandelt dit antwoord als geldig en vraagt niet automatisch alle verdere Target Servers. Zonestand en servervolgorde controleren.
• DNS Protection werkt niet voor alle clients: Controleren of clients werkelijk de firewall als DNS-resolver gebruiken of dat externe resolvers, DoH/DoT, lokale agents of handmatige DNS-instellingen in de weg zitten.

Bij VPN-omgevingen moet u ook controleren of de VPN-clients de juiste DNS-servers en zoekdomeinen ontvangen.

FAQ