DNS-aanvraagroutes configureren op Sophos Firewall

Een DNS Request Route stuurt query’s voor een bepaald domein of een bepaalde reversezone door naar geselecteerde DNS-servers. Een veelvoorkomend voorbeeld is ad.example.com: de firewall resolveert publieke namen via de gebruikelijke DNS-resolvers, maar stuurt query’s voor deze interne zone naar de domeincontrollers.

De route is alleen van toepassing als Sophos Firewall de query als DNS-server verwerkt. Vraagt een client de interne DNS-server rechtstreeks om een antwoord, dan is de forwarding van die server bepalend en niet de Request Route van de firewall.

De doelzone hoeft niet intern te zijn: een Request Route kan ook geselecteerde publieke domeinen doorsturen naar een DNS-resolver in het eigen netwerk. Dat is zinvol als deze DNS-resolver bewust verantwoordelijk is voor die domeinen. Lokale verwerking kan het aantal externe DNS-query’s verminderen; een bepaalde snelheidswinst of extra vertrouwelijkheid is echter alleen mogelijk als de doelresolver de query’s dienovereenkomstig verwerkt en ze niet zelf ongewijzigd doorstuurt naar het internet.

Het DNS-pad bepalen voordat u iets wijzigt

Drie configuraties die op elkaar lijken, hebben elk een andere functie:

• De client vraagt de firewall: DHCP of het VPN-profiel verstrekt het IP-adres van de firewallinterface als DNS-server. Voor toegang tot de lokale DNS-service moet DNS voor de clientzone zijn toegestaan onder Administration > Device access > Local service ACL. Reguliere firewallregels regelen deze toegang tot de firewall zelf niet.
• De client vraagt rechtstreeks een interne DNS-server: de interne DNS-resolver beantwoordt query’s voor lokale zones en stuurt andere query’s door. Verkeer tussen verschillende zones kan een reguliere firewallregel vereisen; dit clientpad maakt geen gebruik van een Request Route op de firewall.
• De firewall vraagt een interne doelserver: een Request Route kiest de doelserver op basis van het opgevraagde domein. De routering naar en bereikbaarheid van de doelserver moeten in orde zijn.

Een DNS Host Entry beantwoordt daarentegen één naam rechtstreeks op de firewall. Voor enkele statische records beschrijft DNS Host Entries instellen op Sophos Firewall de volledige procedure. Een Request Route is geschikter voor een complete zone die op een DNS-server wordt beheerd. DHCP-opties bepalen op hun beurt welke DNS-server en welk zoekdomein een client ontvangt; zie DHCP-opties configureren op Sophos Firewall.

⚠️ Een Request Route wordt geselecteerd op domeinnaam, niet op het bronnetwerk van de client. Als locaties verschillende antwoorden nodig hebben, moeten de betrokken DNS-resolvers of afzonderlijke DNS-paden daarvoor zorgen. Eén route levert geen bronafhankelijke DNS-weergave op.

Voorbeeld en vereisten

In dit voorbeeld wordt een interne AD-zone doorgestuurd naar twee DNS-resolvers:

• interne zone: ad.example.com
• primaire doelserver: 10.10.10.10
• tweede doelserver: 10.10.10.11
• clientnetwerk: 10.20.30.0/24
• IP-adres van de firewall als DNS-resolver voor de client: 10.20.30.1
• positieve test: dc01.ad.example.com
• negatieve test: example.net

example.com en example.net zijn documentatiedomeinen. Vervang in de productieconfiguratie de zone en de server- en interfaceadressen door uw eigen waarden. Beide doelservers moeten verantwoordelijk zijn voor dezelfde zone en dezelfde zonegegevens aanbieden. Een lange lijst met verschillende DNS-resolvers is geen deugdelijke vorm van redundantie.

Controleer voordat u de route aanmaakt de volgende punten:

1. De firewall is als DNS-resolver geconfigureerd onder Network > DNS: in SFOS 22 onder DNS configuration, in SFOS 23 via DNS Protection of DNS server settings. Het globale resolverpad voor de geïnstalleerde versie wordt verderop uitgelegd.
2. De doelservers zijn bereikbaar via het beoogde lokale of VPN-routingpad.
3. De clients waarvoor de route moet gelden, gebruiken daadwerkelijk het IP-adres van de firewall als DNS-server.
4. Onder Administration > Device access is DNS alleen voor de benodigde clientzones toegestaan. Als niet de volledige zone toegang mag krijgen, is een beperktere Local Service ACL Exception aan te raden.
5. De interne zone bestaat op de doelservers en bevat een bekend testrecord.
6. Het bestaande DNS-pad en de bestaande Request Routes zijn vastgelegd zodat de wijziging kan worden teruggedraaid.

Een DNS Request Route aanmaken

1. Open Network > DNS in WebAdmin.
2. Ga naar het gedeelte DNS request route.
3. Selecteer Add.
4. Vul bij Host/Domain name ad.example.com in.
5. Selecteer bij Target servers 10.10.10.10 en 10.10.10.11. Ontbreken de serverobjecten, maak ze dan via Create aan als IP Hosts.
6. Controleer de volgorde: SFOS bevraagt de geselecteerde hosts in de opgegeven volgorde.
7. Sla de configuratie op met Save.

Sophos staat per Request Route maximaal acht IP-adressen van doelservers toe. Meer servers verhogen de beschikbaarheid alleen als ze dezelfde zone correct beantwoorden en via onafhankelijke, daadwerkelijk werkende paden bereikbaar zijn.

Wanneer een Request Route overeenkomt en de firewall geen passend antwoord in de cache vindt, stuurt SFOS de query naar de bijbehorende Target Servers. Voor dat domein valt SFOS niet terug op de globale forwarders of rootservers. Zijn alle doelservers onbereikbaar of onjuist geconfigureerd voor de zone, dan mislukt de naamomzetting dus in plaats van ongemerkt een publieke DNS-resolver te gebruiken.

Vervolgens moet onder DNS request route de nieuwe vermelding met het verwachte domein en de doelservers zichtbaar zijn.

Meerdere doelservers correct beoordelen

De vastgelegde volgorde is een beschikbaarheidsmechanisme, geen methode om tegenstrijdige DNS-gegevens met elkaar in overeenstemming te brengen. Bij globale statische DNS-resolvers beschouwt SFOS NXDOMAIN als een geldig antwoord en wordt de volgende server daarna niet bevraagd. De helpinformatie van SFOS 22 bevestigt dit gedrag niet expliciet voor de doelservers van een Request Route. Vertrouw daarom niet op een tweede server met afwijkende zonegegevens en doe geen stellige toezegging over failover na NXDOMAIN.

Bevraag voor de acceptatietest beide doelservers afzonderlijk vanaf een geautoriseerd testsysteem. Ze moeten de positieve test op dezelfde manier beantwoorden; ook een bewust niet-bestaande naam moet op beide servers hetzelfde resultaat opleveren. Zo ontdekt u replicatie- of autoriteitsproblemen met de zone voordat de firewall tussen de servers moet schakelen.

nslookup dc01.ad.example.com 10.10.10.10
nslookup dc01.ad.example.com 10.10.10.11
nslookup does-not-exist.ad.example.com 10.10.10.10
nslookup does-not-exist.ad.example.com 10.10.10.11

Deze rechtstreekse query’s testen de zonegegevens en het antwoord van de server, niet de Request Route. Voer ze alleen uit vanaf een netwerk dat volgens het DNS-ontwerp toegang tot beide DNS-resolvers mag hebben. Daarna bevestigt een query via 10.20.30.1 dat ook de firewall de zone naar de bedoelde servers doorstuurt.

Reverse lookups doorsturen

Vul voor PTR-query’s de reversezone in bij Host/Domain name, niet een netwerk. Voor 172.16.16.0/24 is de gebruikelijke IPv4-reversezone:

16.16.172.in-addr.arpa

Voor 172.16.0.0/16 is dat:

16.172.in-addr.arpa

Een CIDR-notatie zoals 172.16.16.0/24 hoort niet in het domeinveld. Doorslaggevend is de zone die daadwerkelijk op de interne DNS-server is geconfigureerd. De Request Route maakt geen PTR-records aan; ontbreken de zone of de records op de doelserver, dan blijft de reversequery mislukken. IPv4-netwerken die niet op een octetgrens liggen en IPv6-reversezones vereisen een eigen DNS-delegatieontwerp. Improviseer dit niet door alleen het prefix om te keren.

Reverse DNS helpt logs en services om een adres aan een naam te koppelen. Het herstelt echter geen mislukte forward lookup van een FQDN en vormt daarom een afzonderlijke test.

Het globale resolverpad begrijpen

In SFOS 22 bepaalt u onder Network > DNS > DNS configuration hoe de firewall query’s afhandelt waarvoor geen Host Entry of Request Route van toepassing is. Afhankelijk van de interface kan SFOS DNS-resolvers verkrijgen via Obtain DNS from DHCP of Obtain DNS from PPPoE. Met Static DNS stelt u DNS 1, DNS 2 en eventueel DNS 3 expliciet in.

⚠️ In SFOS 22: Als Obtain DNS from DHCP actief is en de laatste bijbehorende DHCP-interface wordt uitgeschakeld of op een andere toewijzingsmodus wordt gezet, schakelt SFOS over op Static DNS. Wanneer de interface opnieuw wordt ingeschakeld, keert de instelling niet automatisch terug. Controleer daarom de DNS-selectie na wijzigingen aan WAN of interfaces.

Bij Static DNS bevraagt de firewall de servers in de geconfigureerde volgorde. Na een time-out schakelt de firewall over naar de volgende server, maar niet na een geldig NXDOMAIN-antwoord. Antwoorden blijven conform hun TTL in de cache. Een tweede DNS-resolver biedt dus een uitwijkmogelijkheid bij onbereikbaarheid, geen alternatieve DNS-waarheid.

Voor de globale DNS-servers documenteert SFOS 22 vier keuzemogelijkheden. Voor de twee vaste prioriteiten moeten zowel IPv4- als IPv6-DNS-servers zijn geconfigureerd:

• Choose a server based on incoming requests record type kiest de DNS-server op basis van het opgevraagde recordtype A of AAAA.
• Choose IPv6 DNS server over IPv4 geeft de IPv6-DNS-server voorrang boven de IPv4-DNS-server.
• Choose IPv4 DNS server over IPv6 geeft de IPv4-DNS-server voorrang boven de IPv6-DNS-server.
• Choose IPv6 if request originator address is IPv6, else IPv4 gebruikt bij een query vanaf een IPv6-bronadres de IPv6-DNS-server en bij een query vanaf een IPv4-bronadres de IPv4-DNS-server.

Het recordtype en de adresfamilie van het bronadres zijn verschillende criteria: een AAAA-query is niet automatisch een query vanaf een IPv6-bronadres. De keuze wordt daarom gemaakt op basis van het beoogde resolverpad, niet alleen op basis van het gewenste adres in het DNS-antwoord. De gekozen resolvers moeten via de betreffende adresfamilie bereikbaar zijn. Deze globale opties veranderen niets aan de domeingebaseerde selectie van de Target servers van een Request Route.

In SFOS 23 staat de globale serverconfiguratie onder Network > DNS > DNS server settings. Deze is beschikbaar als DNS Protection is uitgeschakeld, of als DNS Protection is ingeschakeld en Fall back to DNS server is geselecteerd. Dit is een bewuste beheer- en beveiligingskeuze, geen vereiste voor een diagnostische test. Als onversleutelde DNS bij het beoogde ontwerp hoort, selecteert u Unencrypted DNS onder DNS protocol. Onder Use IPv4 to forward DNS queries of Use IPv6 to forward DNS queries zijn de opties DHCP server, PPPoE server en Custom DNS servers beschikbaar. Voor eigen resolvers kiest u Custom DNS servers en vult u het goedgekeurde adres in bij Server IP address 1; Server IP address 2 en Server IP address 3 zijn optionele reserves. Ook hier gelden de servervolgorde, time-outs, geldige NXDOMAIN-antwoorden en caching volgens de TTL. Als alle geconfigureerde servers onbereikbaar zijn, beschrijft SFOS 23 voor dit globale onversleutelde pad recursieve resolutie via globale rootservers; dit is niet het fallbackgedrag van een overeenkomende Request Route. Schakel een bestaand DoH- of DNS Protection-pad niet alleen voor een test om naar onversleutelde DNS; de inrichting en fallbackkeuze staan in het DNS Protection-artikel.

Gebruik in SFOS 22 na Apply de optie Test name lookup om een hostnaam of IP-adres vanuit het perspectief van de firewall te controleren. Open in SFOS 23 onder Network > DNS de optie Test name resolution, vul de waarde in bij Hostname or IP address en selecteer Test connection. Het resultaat toont de gebruikte DNS-server en het protocol, de resolutiestatus en de antwoordtijden. Behoud de bestaande DNS-configuratie voor de test. Een interne testnaam kan een passende Request Route gebruiken, maar geen van beide tests bevestigt de resolver die op de client is ingesteld of het daadwerkelijke DNS-pad van die client.

Als WebAdmin tijdens gepland herstel niet beschikbaar is, toont de interactieve CLI onder 1. Network Configuration > DNS Configuration de globale IPv4- en IPv6-DNS-servers. Dit menuonderdeel wijzigt geen Request Routes. Leg eerst alle weergegeven waarden vast en druk vervolgens op Enter om verder te gaan. Typ bij Set IPv4 DNS (y/n) y en druk op Enter om de globale IPv4-DNS-servers te gaan wijzigen; gebruik uitsluitend resolveradressen die voor deze omgeving zijn goedgekeurd. Als u niets wilt wijzigen, drukt u bij deze vraag op Enter om de standaardwaarde No (Enter) te accepteren en de wijziging over te slaan. Druk daarna op Enter om terug te keren naar het Main menu. Houd bij een wijziging op afstand een onafhankelijk beheerpad beschikbaar.

DNS Protection combineren met interne zones

Kies eerst de versie: gebruik vanaf SFOS 23.0 het geïntegreerde DoH-pad met DNS Protection onder Network > DNS en de toewijzing van de Filtering Policy aan het firewallobject. Het hieronder gelinkte DNS Protection-artikel beschrijft de inrichting, fallbackkeuze, pilot en het terugdraaien. De volgende stappen voor Location/DDNS en Static DNS gelden uitsluitend voor Traditional DNS op SFOS 22 en ouder; voer deze niet daarnaast uit bij het geïntegreerde SFOS 23-pad. Interne Request Routes en de controles van het clientpad en NAT blijven relevant.

Bij Sophos DNS Protection met Sophos Firewall gaan publieke query’s naar DNS Protection, terwijl Request Routes interne zones naar lokale DNS-resolvers sturen. Registreer de firewall daarvoor eerst als Location in Sophos Fusion (voorheen Sophos Central). Bij meerdere publieke WAN-adressen moeten alle gebruikte adressen of het juiste bereik zijn geregistreerd; gebruik bij een dynamisch WAN-adres de geregistreerde DDNS-hostnaam.

Volgens de officiële Sophos-configuratie stelt u de twee DNS Protection-adressen onder Network > DNS > DNS configuration in als DNS 1 en DNS 2, laat u DNS 3 leeg, verwijdert u IPv6-DNS-servers en selecteert u Choose IPv4 DNS server over IPv6. Een derde DNS-resolver of een onbedoelde IPv6-resolver kan ervoor zorgen dat query’s DNS Protection omzeilen.

Voor DHCP beschrijft Sophos een specifiek pad: onder Network > DHCP > Server > Edit blijft Use device’s DNS settings uitgeschakeld. Vul bij Primary DNS het IP-adres van de firewall op de DHCP-interface in en bij Secondary DNS een publiek DNS Protection-adres. Clients kunnen meerdere DNS-resolvers verschillend gebruiken; controleer daarom of interne query’s werkelijk via de firewall lopen. Rechtstreekse clientquery’s naar DNS Protection maken geen gebruik van de lokale Request Routes van de firewall.

Sophos beschrijft daarnaast een DNAT-regel die reguliere uitgaande DNS-query’s van interne netwerken omleidt naar het interne IP-adres van de firewall. Deze omleiding is een afzonderlijke beveiligingsbeslissing: DNS over HTTPS en DNS over TLS worden niet automatisch onderschept en bijzondere apparaten kunnen er hinder van ondervinden. Voer de regel alleen in voor duidelijk omschreven bronnetwerken, zonder WAN als Inbound Interface, en met een gedocumenteerd uitzonderings- en terugdraaiplan.

Firewall en client afzonderlijk testen

Het perspectief van de DNS-resolver op de firewall

Test onder Network > DNS eerst dc01.ad.example.com en daarna example.net: in SFOS 22 met Test name lookup, in SFOS 23 met Test name resolution > Hostname or IP address > Test connection. De interne naam moet het verwachte interne adres opleveren; de publieke naam moet nog steeds via het bedoelde standaardpad worden geresolveerd. Vergelijk in SFOS 23 ook de weergegeven DNS-server, het protocol, de resolutiestatus en de antwoordtijden met het beoogde pad. Een geslaagde resolutie alleen bewijst noch de clientconfiguratie noch het daadwerkelijke clientpad.

In 4. Device Console krijgt u hetzelfde perspectief met de officieel gedocumenteerde opdracht:

dnslookup host dc01.ad.example.com
dnslookup host example.net

Deze tests tonen het perspectief van de DNS-resolver op de firewall. Ze bewijzen nog niet dat een client de firewall bevraagt.

Afzonderlijke DNS-resolvers vergelijken onder Diagnostics

Onder Diagnostics > Tools biedt SFOS 22 Name lookup met IP address or hostname en DNS server IP. Met een FQDN test u de forward lookup, met een IPv4- of IPv6-adres de reverse lookup. Selecteer gericht een geconfigureerde server of vergelijk met Lookup using all configured servers de antwoorden en antwoordtijden van alle geconfigureerde DNS-resolvers. Een korte antwoordtijd alleen rechtvaardigt geen wijziging van de servervolgorde; eerst moeten de antwoorden passen bij de beoogde zone.

In SFOS 23 heet het gedeelte DNS lookup en heten de velden Hostname or IP address en DNS server IP address. Naast een beschikbare server en All configured servers zijn ook Custom DNS server en Custom DoH server beschikbaar; bij beide voert u het IP-adres van de gewenste server in. DNS Protection is alleen selecteerbaar als DNS Protection onder Network > DNS is ingeschakeld. Dit is een diagnostische optie, geen aansporing om de bestaande DNS-configuratie voor een test aan te passen.

Gebruik voor interne testnamen uitsluitend goedgekeurde interne DNS-resolvers, zodat de namen niet bij een publieke DNS- of DoH-service terechtkomen. Een gerichte query naar een DNS-resolver bevestigt het antwoord van die resolver, niet het daadwerkelijke pad via de Request Route of het clientpad. De acceptatietest via het IP-adres van de firewall en Packet Capture blijft daarom nodig.

Het clientpad aantonen

Controleer op een testclient eerst de ingestelde DNS-server en bevraag vervolgens expliciet het IP-adres van de firewall, 10.20.30.1.

Windows:

ipconfig /all
nslookup dc01.ad.example.com 10.20.30.1
nslookup example.net 10.20.30.1

macOS of Linux:

dig @10.20.30.1 dc01.ad.example.com A
dig @10.20.30.1 example.net A

Voer daarna dezelfde query’s uit zonder expliciet een server op te geven. Wijken de resultaten af, dan gebruikt de client een ander resolverpad, bijvoorbeeld door een statische instelling, een VPN-profiel, DNS over HTTPS of een lokale beveiligingsagent. Een zoekdomein is alleen van belang voor korte, niet-volledig gekwalificeerde namen; de bovenstaande FQDN’s hebben het niet nodig.

Packet Capture voor het werkelijke pad

Beperk onder Diagnostics > Packet capture het verkeer met een filter op de testclient, de doelservers en poort 53. Packet Capture op Sophos Firewall beschrijft de precieze werkwijze.

(host 10.20.30.50 or host 10.10.10.10 or host 10.10.10.11) and port 53

Controleer de binnenkomende clientquery, de door de firewall gegenereerde query naar de juiste Target Server en de bijbehorende antwoorden. Met Packet Capture maakt u zo onderscheid tussen ontbrekende clienttoegang en een routerings- of doelserverprobleem. Omdat de capturebuffer beperkt is, stelt u een nauw filter in en activeert u de opname uitsluitend tijdens de test.

Bij DNS Protection vormt de officiële koppeling Check your configuration onder My Products > DNS Protection > Installers een aanvullende controle. De welkomstpagina bevestigt het DNS Protection-pad; test de interne zone, het clientpad en de Request Route desondanks afzonderlijk.

Problemen per symptoom afbakenen

De firewall resolveert intern, maar de client niet

• Controleer of de client daadwerkelijk het IP-adres van de firewall als DNS-server gebruikt.
• Controleer onder Administration > Device access of DNS voor de clientzone of via een geschikte Local Service ACL Exception is toegestaan.
• Stuur de query expliciet naar het IP-adres van de firewall en bevestig het pad met Packet Capture.
• Controleer DHCP-, VPN- en lokale resolverinstellingen en alternatieve paden zoals DoH en DoT.

De firewall bereikt de Target Server niet

• Controleer Route Lookup en het lokale of VPN-pad naar het doeladres.
• Controleer UDP- en TCP-poort 53 naar de doelserver en de ACL van die server.
• Bevraag de DNS-resolver rechtstreeks en controleer of deze query’s vanaf het IP-adres van de firewall accepteert.
• Let in Packet Capture op een gegenereerde query, een antwoord of een reden voor het droppen van het pakket.

Als clients de interne DNS-server rechtstreeks bevragen, is het reguliere transitpad tussen zones met een firewallregel van toepassing. Gebruik voor dit onderscheid Firewallregels controleren met Log Viewer, Policy Test en Packet Capture.

Onjuiste of wisselende antwoorden

• Domein te ruim of onjuist: beperk de Request Route tot de zone die daadwerkelijk verantwoordelijk is.
• Doelservers bevatten verschillende gegevens: controleer DNS-replicatie en zoneautoriteit rechtstreeks op elke server.
• Verouderd antwoord: houd rekening met TTL en caches op de firewall, DNS-resolver en client.
• Alleen korte namen werken niet: controleer het zoekdomein van de client en test de FQDN afzonderlijk.
• Reverse lookup mislukt: controleer de PTR-zone en het PTR-record op de doelserver.
• Alleen VPN-clients hebben problemen: controleer de toegewezen DNS-servers, VPN-routering en toegang tot de lokale DNS-service. De relevante clientvelden staan in Sophos Connect configureren en Externe toegang via SSL VPN instellen.

XML API: een route identificeren aan de hand van de objectnaam

Vanaf SFOS 23 vereist de XML-API-documentatie bij het aanmaken en bewerken van een DNS Request Route zowel Name als DomainName. Name identificeert het geconfigureerde object, DomainName de DNS-zone die moet worden doorgestuurd; bijvoorbeeld Name = ad-intern en DomainName = ad.example.com. Dit zijn veldwaarden, geen uitvoerbare XML. Name is één enkele STRING met maximaal 64 tekens, staat UTF-8 toe en verbiedt komma’s. DomainName blijft FQDN met maximaal 255 tekens; ook de doelservers moeten nog steeds worden opgegeven.

Bij het verwijderen verandert de gedocumenteerde sleutel van DomainName in SFOS 22 naar Name in SFOS 23. Herhaal oude aanvragen niet ongewijzigd en neem de domeinnaam niet automatisch over als objectnaam. Controleer vooraf de geïnstalleerde versie, lees het concrete object uit, vergelijk Name, DomainName, Target Servers en afhankelijkheden met het bedoelde doel en documenteer het terugdraaiplan. Stop bij onduidelijkheid. Controleer achteraf het API-antwoord en de status en lees het exacte doel opnieuw uit: alleen de bedoelde route mag verwijderd zijn; andere routes moeten ongewijzigd blijven. Test vervolgens interne en openbare naamomzetting zoals hierboven beschreven. Hier wordt geen verwijder-envelope of REST-schema verzonnen en niet beweerd dat een producttest is uitgevoerd.

De globale DNS-protocolconfiguratie staat hier los van. Het DNS Protection-artikel legt de onopgeloste SFOS 23-XML-schemaconflicten en het veilige WebAdmin-pad uit; de vier resolveropties die hierboven uitdrukkelijk voor SFOS 22 zijn beschreven, bewijzen geen numerieke SFOS 23-API-toewijzing.

Terugdraaien en beheer

Leg vóór de wijziging de bestaande Request Routes, de globale DNS-selectie, de Device Access-rechten en een positieve en negatieve test vast. Voor een reguliere rollback verwijdert u de nieuw aangemaakte route of herstelt u exact de gedocumenteerde vorige waarden. Zet tijdelijke ACL-uitzonderingen of DNS-omleidingen eveneens terug naar hun oorspronkelijke toestand.

Controleer daarna opnieuw drie zaken:

1. De firewall resolveert een interne en een publieke naam via het beoogde pad.
2. De betrokken client gebruikt de bedoelde DNS-resolver en ontvangt de verwachte antwoorden.
3. Een domein waarop de wijziging niet van toepassing is, wordt niet naar de interne Target Server gestuurd.

Een volledige configuratieback-up is geen praktische rollback voor één object: bij herstel wordt de hele configuratie vervangen en kunnen latere wijzigingen verloren gaan. Voor één Request Route is het terugzetten van de gedocumenteerde objectwijziging daarom de veiligste weg terug.

Veelgestelde vragen