DNS-aanvraagroutes configureren op Sophos Firewall

Met DNS-aanvraagroutes kunt u op de Sophos Firewall bepalen welke DNS-server voor specifieke domeinen of netwerken 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 hebben alleen zin als het gewenste DNS-gedrag en de verantwoordelijke DNS-servers duidelijk zijn gedefinieerd.

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 Internet-DNS, algemene FQDN-resolutie, updates en clouddiensten.
• DNS-aanvraagroute: Specifiek domein of reverse-zone naar gedefinieerde DNS-server sturen Active Directory, interne domeinen, locatie-DNS, split DNS.
• DHCP-optie: DNS-server of zoekdomein aan clients distribueren Clients moeten direct een specifieke DNS-server 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.

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: Firewall stuurt openbare domeinen globaal door en interne domeinen via DNS-aanvraagroute Kleine en middelgrote locaties, DNS Protection, gast-/clientnetwerken.
• Clients vragen interne DNS-servers direct: Domeincontroller of DNS-server lossen intern op en sturen extern door Klassieke Active Directory-netwerken met Windows-DNS als centrale resolver.
• VPN-clients vragen de firewall: Firewall gebruikt aanvraagroutes voor interne domeinen Remote Access met eenvoudige DNS-route via de firewall.
• VPN-clients vragen interne DNS-servers direct: DNS loopt via VPN naar de domeincontroller of DNS-server 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.

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
• 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.

DNS Request Route configureren

De route bepaalt welke DNS-servers voor een specifieke domein- of reverse-zone worden bevraagd.

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

Stappen:

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

Daarna vraagt de firewall voor dit domein de opgegeven DNS-server.

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.

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.

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.

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

DNS-wijzigingen moeten altijd vanaf de firewall en vanaf echte clients worden gecontroleerd.

Tests en validatie

Na de configuratie moet u de naamresolutie testen:

• Kan de firewall de interne naam oplossen?
• 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.

Bedrijfscontrole

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

Praktische documentatie:

• Domein of reverse-zone: ad.firma.local
• Doelservers: 10.10.10.10, 10.10.10.11
• Doel: Active Directory DNS voor hoofdkantoor.
• Betrokken netwerken: LAN, Admin-VPN, locatie Zürich.
• Afhankelijkheden: Site-to-Site VPN, domeincontroller, firewallregel DNS.
• Test: server01.ad.firma.local lost op naar verwachte interne IP.

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.

• Negatieve test: bijvoorbeeld example.com blijft het bedoelde standaardpad gebruiken.

Troubleshooting

Als het verwachte resultaat ontbreekt, controleer dan stap voor stap logging, rule matching en policygedrag.

Typische fouten

• Interne naam lost niet op: Verkeerde domein, bijvoorbeeld firma.local in plaats van ad.firma.local Domein in de aanvraagroute en zoekdomein van de client controleren.
• VPN-client lost interne namen niet op: Client gebruikt 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 Ping, Packet Capture en Route Lookup controleren.
• Reverse lookup werkt niet: PTR-zone of PTR-records ontbreken Reverse lookup-zone op de interne DNS-server controleren.
• Individuele locaties geven verkeerde antwoorden: Verkeerde doelserver of verouderde zonedata Volgorde van de doelservers en DNS-replicatie controleren.
• Openbare namen worden plotseling intern beantwoord: Aanvraagroute is te breed Specifieker domein gebruiken en wildcard-denken vermijden.

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

FAQ