Konfigurowanie tras zapytań DNS na Sophos Firewall

Funkcja DNS Request Route przekazuje zapytania dotyczące określonej domeny lub strefy wyszukiwania wstecznego do wybranych serwerów DNS. Typowym przykładem jest ad.example.com: firewall rozwiązuje nazwy publiczne za pośrednictwem standardowych resolverów DNS, natomiast zapytania o tę strefę wewnętrzną wysyła do kontrolerów domeny.

Trasa ma zastosowanie tylko wtedy, gdy Sophos Firewall przetwarza zapytanie jako serwer DNS. Jeżeli klient odpytuje bezpośrednio wewnętrzny serwer DNS, o dalszym przekazywaniu decyduje ten serwer, a nie Request Route na firewallu.

Strefa docelowa nie musi być wewnętrzna: Request Route może również kierować zapytania o wybrane domeny publiczne do resolvera DNS we własnej sieci. Ma to sens, jeśli resolver ten celowo odpowiada za te domeny. Lokalne przetwarzanie może ograniczyć liczbę zewnętrznych zapytań DNS; określone przyspieszenie lub dodatkowa poufność są jednak zapewnione tylko wtedy, gdy resolver docelowy odpowiednio przetwarza zapytania, a nie przekazuje ich dalej bez zmian do Internetu.

Ustalenie ścieżki DNS przed wprowadzeniem zmian

Trzy pozornie podobne konfiguracje służą do różnych celów:

• Klient odpytuje firewall: DHCP lub profil VPN przekazuje adres IP interfejsu firewalla jako serwer DNS. Aby klient mógł korzystać z lokalnej usługi DNS, dla jego strefy trzeba zezwolić na DNS w Administration > Device access > Local service ACL. Zwykłe reguły firewalla nie sterują dostępem do usługi działającej na samym firewallu.
• Klient odpytuje bezpośrednio wewnętrzny serwer DNS: wewnętrzny resolver DNS odpowiada za strefy lokalne, a pozostałe zapytania przekazuje dalej. Jeśli ruch przebiega między różnymi strefami, może być potrzebna zwykła reguła firewalla; taka ścieżka klienta nie korzysta z Request Route na firewallu.
• Firewall odpytuje wewnętrzny serwer docelowy: Request Route wybiera serwer docelowy na podstawie nazwy domeny w zapytaniu. Routing i łączność z tym serwerem muszą działać prawidłowo.

Z kolei DNS Host Entry pozwala firewallowi bezpośrednio odpowiedzieć na zapytanie o pojedynczą nazwę. Pełną procedurę dla niewielkiej liczby statycznych wpisów opisano w artykule Konfigurowanie wpisów hostów DNS na Sophos Firewall. Request Route lepiej sprawdza się w przypadku całej strefy utrzymywanej na serwerze DNS. Opcje DHCP określają natomiast, jaki serwer DNS i jaką domenę wyszukiwania otrzyma klient; zobacz Konfigurowanie opcji DHCP na Sophos Firewall.

⚠️ Request Route jest wybierana na podstawie nazwy domeny, a nie sieci źródłowej klienta. Jeżeli poszczególne lokalizacje mają otrzymywać różne odpowiedzi, muszą to zapewniać używane resolvery DNS lub odrębne ścieżki DNS. Jedna trasa nie tworzy widoku DNS zależnego od źródła zapytania.

Przykład i wymagania wstępne

W tym przykładzie wewnętrzna strefa AD jest przekazywana do dwóch resolverów DNS:

• strefa wewnętrzna: ad.example.com
• podstawowy serwer docelowy: 10.10.10.10
• drugi serwer docelowy: 10.10.10.11
• sieć klientów: 10.20.30.0/24
• adres IP firewalla jako resolver DNS klienta: 10.20.30.1
• test pozytywny: dc01.ad.example.com
• test negatywny: example.net

example.com i example.net to domeny przeznaczone do celów dokumentacyjnych. W konfiguracji produkcyjnej należy zastąpić strefę oraz adresy serwerów i interfejsu własnymi wartościami. Oba serwery docelowe powinny obsługiwać tę samą strefę i zawierać ten sam zestaw jej danych. Długa lista różnych resolverów DNS nie stanowi właściwie zaprojektowanej nadmiarowości.

Przed utworzeniem trasy należy sprawdzić następujące elementy:

1. Firewall jest skonfigurowany jako resolver DNS w Network > DNS > DNS configuration.
2. Serwery docelowe są osiągalne zamierzoną trasą lokalną lub VPN.
3. Klienci, których ma dotyczyć trasa, faktycznie używają adresu IP firewalla jako serwera DNS.
4. W Administration > Device access dostęp do DNS jest włączony tylko dla wymaganych stref klientów. Jeżeli dostęp nie powinien obejmować całej strefy, warto utworzyć bardziej restrykcyjny wyjątek Local Service ACL Exception.
5. Strefa wewnętrzna istnieje na serwerach docelowych i zawiera znany rekord testowy.
6. Dotychczasowa ścieżka DNS i istniejące Request Routes są udokumentowane na potrzeby wycofania zmiany.

Tworzenie DNS Request Route

1. Otwórz Network > DNS w WebAdmin.
2. Przejdź do sekcji DNS request route.
3. Wybierz Add.
4. W polu Host/Domain name wpisz ad.example.com.
5. W polu Target servers wybierz 10.10.10.10 i 10.10.10.11. Jeśli obiekty serwerów nie istnieją, utwórz je jako IP Hosts za pomocą opcji Create.
6. Sprawdź kolejność: SFOS odpytuje wybrane hosty w podanej kolejności.
7. Zapisz konfigurację przyciskiem Save.

Sophos pozwala przypisać do jednej Request Route najwyżej osiem docelowych adresów IP. Większa liczba serwerów zwiększa dostępność tylko wtedy, gdy wszystkie poprawnie odpowiadają za tę samą strefę i są osiągalne niezależnymi, rzeczywiście działającymi ścieżkami.

Gdy zapytanie pasuje do Request Route, a firewall nie znajduje właściwej odpowiedzi w pamięci podręcznej, SFOS wysyła je do przypisanych Target Servers. W przypadku tej domeny nie przełącza się na globalne forwardery ani serwery główne DNS. Jeżeli wszystkie serwery docelowe są nieosiągalne lub nieprawidłowo skonfigurowane dla danej strefy, rozwiązywanie nazwy zakończy się niepowodzeniem, zamiast niepostrzeżenie skorzystać z publicznego resolvera DNS.

Nowy wpis powinien być następnie widoczny w DNS request route wraz z oczekiwaną domeną i serwerami docelowymi.

Właściwa ocena wielu serwerów docelowych

Udokumentowana kolejność stanowi mechanizm zapewniania dostępności, a nie sposób uzgadniania sprzecznych danych DNS. W przypadku globalnych statycznych resolverów DNS SFOS uznaje NXDOMAIN za prawidłową odpowiedź i nie odpytuje kolejnego serwera. Dokumentacja SFOS 22 nie potwierdza jednoznacznie takiego zachowania dla serwerów docelowych Request Route. Nie należy więc polegać na drugim serwerze zawierającym inne dane strefy ani gwarantować określonego przełączenia awaryjnego po odpowiedzi NXDOMAIN.

W ramach testów odbiorczych należy osobno odpytać oba serwery docelowe z uprawnionego systemu testowego. Muszą one zwracać taką samą odpowiedź w teście pozytywnym; również celowo nieistniejąca nazwa powinna dać ten sam wynik na obu serwerach. Pozwala to wykryć problemy z replikacją lub autorytatywnością strefy, zanim firewall będzie musiał przełączyć się między serwerami.

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

Te bezpośrednie zapytania sprawdzają dane strefy i odpowiedź serwera, a nie Request Route. Należy je wykonywać wyłącznie z sieci, która zgodnie z projektem DNS może komunikować się z oboma resolverami DNS. Następnie zapytanie za pośrednictwem 10.20.30.1 potwierdza, że firewall również przekazuje strefę do właściwych serwerów.

Przekazywanie zapytań wyszukiwania wstecznego

W przypadku zapytań PTR w polu Host/Domain name należy podać strefę wyszukiwania wstecznego, a nie adres sieci. Dla sieci 172.16.16.0/24 standardowa strefa odwrotna IPv4 ma postać:

16.16.172.in-addr.arpa

Dla sieci 172.16.0.0/16 jest to:

16.172.in-addr.arpa

Notacji CIDR, takiej jak 172.16.16.0/24, nie należy wpisywać w polu domeny. Decydujące znaczenie ma strefa faktycznie skonfigurowana na wewnętrznym serwerze DNS. Request Route nie tworzy rekordów PTR; jeżeli na serwerze docelowym brakuje strefy lub rekordów, wyszukiwanie wsteczne się nie powiedzie. Sieci IPv4, których maska nie kończy się na granicy oktetu, oraz strefy odwrotne IPv6 wymagają osobnego projektu delegowania DNS. Nie należy ich konfigurować przez samo odwrócenie prefiksu.

Odwrotny DNS pomaga dziennikom i usługom powiązać adres z nazwą. Nie naprawia jednak nieudanego wyszukiwania bezpośredniego FQDN, dlatego stanowi oddzielny przypadek testowy.

Zrozumienie globalnej ścieżki resolvera

W Network > DNS > DNS configuration określa się sposób rozwiązywania przez firewall zapytań, do których nie pasuje żadna Host Entry ani Request Route. W zależności od interfejsu SFOS może pobierać adresy resolverów za pomocą Obtain DNS from DHCP lub Obtain DNS from PPPoE. Opcja Static DNS umożliwia jawne ustawienie DNS 1, DNS 2 i opcjonalnie DNS 3.

⚠️ Jeśli opcja Obtain DNS from DHCP jest aktywna, a ostatni odpowiadający jej interfejs DHCP zostanie wyłączony lub przestawiony na inny tryb przypisywania, SFOS przełączy się na Static DNS. Po ponownym włączeniu interfejsu poprzednie ustawienie nie zostanie przywrócone automatycznie. Po zmianach interfejsów lub łączy WAN należy zatem sprawdzić wybór DNS.

Przy ustawieniu Static DNS firewall odpytuje serwery w skonfigurowanej kolejności. Po przekroczeniu limitu czasu przechodzi do kolejnego serwera, ale nie robi tego po prawidłowej odpowiedzi NXDOMAIN. Odpowiedzi pozostają w pamięci podręcznej zgodnie z wartością TTL. Drugi resolver DNS stanowi zatem zabezpieczenie na wypadek braku łączności, a nie alternatywne źródło prawdy o DNS.

Dokumentacja SFOS 22 opisuje cztery opcje wyboru globalnych serwerów DNS. W przypadku dwóch opcji ze stałym priorytetem muszą być skonfigurowane zarówno serwery DNS IPv4, jak i IPv6:

• Choose a server based on incoming requests record type wybiera serwer DNS na podstawie typu rekordu A lub AAAA, którego dotyczy zapytanie.
• Choose IPv6 DNS server over IPv4 daje pierwszeństwo serwerowi DNS IPv6 przed serwerem DNS IPv4.
• Choose IPv4 DNS server over IPv6 daje pierwszeństwo serwerowi DNS IPv4 przed serwerem DNS IPv6.
• Choose IPv6 if request originator address is IPv6, else IPv4 używa serwera DNS IPv6 w przypadku zapytania z adresu źródłowego IPv6, a serwera DNS IPv4 w przypadku zapytania z adresu źródłowego IPv4.

Typ rekordu i rodzina adresu źródłowego to różne kryteria: zapytanie o rekord AAAA nie jest automatycznie zapytaniem z adresu źródłowego IPv6. Wybór jest zatem dokonywany zgodnie z zamierzoną ścieżką resolvera, a nie wyłącznie na podstawie oczekiwanego adresu w odpowiedzi DNS. Wybrane resolvery muszą być osiągalne przez odpowiednią rodzinę adresów. Te globalne opcje nie zmieniają wyboru serwerów Target servers w Request Route na podstawie domeny.

Po wybraniu Apply funkcja Test name lookup sprawdza nazwę hosta lub adres IP z perspektywy firewalla. Wewnętrzna nazwa testowa może przy tym skorzystać z pasującej Request Route. Test nie potwierdza jednak, jaki resolver DNS ustawiono na kliencie ani jak przebiega jego rzeczywista ścieżka DNS.

Jeśli podczas planowanego odzyskiwania WebAdmin jest niedostępny, interfejs CLI wyświetla globalne serwery DNS IPv4 i IPv6 w 1. Network Configuration > DNS Configuration. Ta pozycja menu nie zmienia Request Routes. Przed wprowadzeniem danych należy zapisać wszystkie wyświetlane wartości; naciśnięcie Enter bez podania nowej wartości powoduje pominięcie zmiany. Przy zmianach zdalnych trzeba zachować niezależną ścieżkę zarządzania.

Łączenie DNS Protection ze strefami wewnętrznymi

Najpierw wybierz wersję: od SFOS 23.0 używaj zintegrowanej ścieżki DoH z DNS Protection w Network > DNS i przypisaniem Filtering Policy do obiektu firewalla. Konfigurację, decyzję o fallbacku, pilotaż i wycofanie opisuje artykuł o DNS Protection, do którego odsyłamy poniżej. Następująca dalej sekwencja Location/DDNS i Static DNS dotyczy wyłącznie Traditional DNS na SFOS 22 i starszych; nie wykonuje się jej dodatkowo w zintegrowanej ścieżce SFOS 23. Wewnętrzne Request Routes oraz kontrole ścieżki klienta i NAT pozostają istotne.

W konfiguracji Sophos DNS Protection z Sophos Firewall zapytania publiczne trafiają do DNS Protection, a Request Routes kierują strefy wewnętrzne do lokalnych resolverów DNS. Najpierw należy zarejestrować firewall jako Location w Sophos Fusion (dawniej Sophos Central). Jeśli używanych jest kilka publicznych adresów WAN, trzeba zarejestrować wszystkie te adresy lub właściwy zakres; przy dynamicznym adresie WAN używa się zarejestrowanej nazwy hosta DDNS.

Zgodnie z oficjalną konfiguracją Sophos dwa adresy DNS Protection należy ustawić jako DNS 1 i DNS 2 w Network > DNS > DNS configuration, pozostawić puste pole DNS 3, usunąć serwery DNS IPv6 i wybrać Choose IPv4 DNS server over IPv6. Trzeci resolver DNS lub niezamierzony resolver IPv6 może spowodować ominięcie DNS Protection przez zapytania.

W przypadku DHCP Sophos zaleca szczególną konfigurację: w Network > DHCP > Server > Edit opcja Use device’s DNS settings pozostaje wyłączona. W polu Primary DNS należy podać adres IP firewalla w interfejsie DHCP, a w polu Secondary DNS — publiczny adres DNS Protection. Klienci mogą w różny sposób korzystać z wielu resolverów DNS, dlatego trzeba sprawdzić, czy zapytania wewnętrzne rzeczywiście przechodzą przez firewall. Zapytania wysyłane przez klienta bezpośrednio do DNS Protection nie korzystają z lokalnych Request Routes firewalla.

Sophos opisuje również regułę DNAT, która przekierowuje standardowe wychodzące zapytania DNS z sieci wewnętrznych na wewnętrzny adres IP firewalla. Takie przekierowanie jest osobną decyzją dotyczącą bezpieczeństwa: nie przechwytuje automatycznie DNS over HTTPS ani DNS over TLS i może wpływać na urządzenia specjalnego przeznaczenia. Należy je wdrażać wyłącznie dla jednoznacznie wskazanych sieci źródłowych, bez WAN jako Inbound Interface, oraz z udokumentowanym planem wyjątków i wycofania.

Osobne testowanie firewalla i klienta

Perspektywa resolvera DNS na firewallu

W Network > DNS > Test name lookup należy kolejno sprawdzić dc01.ad.example.com i example.net. Nazwa wewnętrzna musi zwrócić oczekiwany adres wewnętrzny, a nazwa publiczna powinna nadal być rozwiązywana zamierzoną ścieżką domyślną.

W 4. Device Console tę samą perspektywę można sprawdzić oficjalnie udokumentowanym poleceniem:

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

Testy te pokazują wynik z perspektywy resolvera DNS na firewallu. Nie dowodzą jeszcze, że klient odpytuje firewall.

Porównywanie poszczególnych resolverów DNS w Diagnostics

W Diagnostics > Tools SFOS 22 udostępnia Name lookup z polami IP address or hostname i DNS server IP. FQDN służy do sprawdzania wyszukiwania bezpośredniego, a adres IPv4 lub IPv6 — wyszukiwania wstecznego. Można wybrać konkretny skonfigurowany serwer lub użyć Lookup using all configured servers, aby porównać odpowiedzi i czasy odpowiedzi wszystkich skonfigurowanych resolverów DNS. Sam krótki czas odpowiedzi nie uzasadnia zmiany kolejności serwerów; najpierw trzeba sprawdzić, czy odpowiedzi są właściwe dla zamierzonej strefy.

W SFOS 23 sekcja nosi nazwę DNS lookup, a pola to Hostname or IP address i DNS server IP address. Oprócz wyboru dostępnego serwera i opcji All configured servers dostępne są Custom DNS server i Custom DoH server; w obu przypadkach należy podać adres IP wybranego serwera. Opcję DNS Protection można wybrać tylko wtedy, gdy DNS Protection jest włączony w Network > DNS. Jest to opcja diagnostyczna, a nie zalecenie przebudowy istniejącej konfiguracji DNS na potrzeby testu.

W przypadku wewnętrznych nazw testowych należy korzystać wyłącznie z zatwierdzonych wewnętrznych resolverów DNS, aby nazwy te nie trafiły do publicznej usługi DNS lub DoH. Zapytanie skierowane do konkretnego resolvera DNS potwierdza jego odpowiedź, a nie rzeczywistą ścieżkę Request Route ani ścieżkę klienta. Dlatego nadal konieczne są testy odbiorcze za pośrednictwem adresu IP firewalla oraz Packet Capture.

Potwierdzanie ścieżki klienta

Na kliencie testowym należy najpierw sprawdzić skonfigurowany serwer DNS, a następnie jawnie odpytać adres IP firewalla 10.20.30.1.

Windows:

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

macOS lub Linux:

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

Następnie należy wykonać te same zapytania bez jawnego wskazywania serwera. Jeżeli wyniki są inne, klient korzysta z innej ścieżki resolvera, na przykład z ustawienia statycznego, profilu VPN, DNS over HTTPS lub lokalnego agenta bezpieczeństwa. Domena wyszukiwania ma znaczenie tylko dla krótkich, niekwalifikowanych nazw; użyte powyżej nazwy FQDN jej nie wymagają.

Packet Capture dla rzeczywistej ścieżki

W Diagnostics > Packet capture należy ograniczyć ruch filtrem obejmującym klienta testowego, serwery docelowe i port 53. Dokładną procedurę opisano w artykule Packet Capture na Sophos Firewall.

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

Należy sprawdzić przychodzące zapytanie klienta, zapytanie wygenerowane przez firewall do właściwego Target Server oraz odpowiednie odpowiedzi. Packet Capture pozwala w ten sposób odróżnić brak dostępu klienta od problemu z routingiem lub serwerem docelowym. Ponieważ bufor przechwytywania ma ograniczoną pojemność, filtr powinien być precyzyjny, a rejestrowanie włączone tylko na czas testu.

W przypadku DNS Protection uzupełnieniem testu jest oficjalne łącze Check your configuration w My Products > DNS Protection > Installers. Strona powitalna potwierdza ścieżkę DNS Protection, jednak strefę wewnętrzną, ścieżkę klienta i Request Route nadal trzeba sprawdzić osobno.

Zawężanie problemu na podstawie objawów

Firewall rozwiązuje nazwę wewnętrzną, ale klient nie

• Sprawdź, czy klient rzeczywiście używa adresu IP firewalla jako serwera DNS.
• W Administration > Device access sprawdź, czy DNS jest dozwolony dla strefy klienta lub przez odpowiedni Local Service ACL Exception.
• Wyślij zapytanie jawnie do adresu IP firewalla i potwierdź jego przebieg za pomocą Packet Capture.
• Sprawdź ustawienia DHCP, VPN i lokalnego resolvera DNS, a także ścieżki alternatywne, takie jak DoH i DoT.

Firewall nie może połączyć się z Target Server

• Sprawdź Route Lookup oraz lokalną trasę lub trasę VPN do adresu docelowego.
• Sprawdź dostęp do portu 53 przez UDP i TCP na serwerze docelowym oraz jego własną listę ACL.
• Odpytaj bezpośrednio resolver DNS i sprawdź, czy przyjmuje zapytania z adresu IP firewalla.
• W Packet Capture poszukaj wygenerowanego zapytania, odpowiedzi lub przyczyny odrzucenia pakietu.

Jeśli klienci odpytują bezpośrednio wewnętrzny serwer DNS, obowiązuje zwykła ścieżka tranzytowa między strefami i odpowiednia reguła firewalla. Rozróżnienie obu przypadków ułatwia artykuł Sprawdzanie reguł firewalla za pomocą Log Viewer, Policy Test i Packet Capture.

Nieprawidłowe lub zmienne odpowiedzi

• Domena jest zbyt szeroka lub nieprawidłowa: ogranicz Request Route do strefy, która faktycznie odpowiada za dane nazwy.
• Serwery docelowe zawierają różne dane: sprawdź replikację DNS i autorytatywność strefy bezpośrednio na każdym serwerze.
• Nieaktualna odpowiedź: uwzględnij TTL oraz pamięć podręczną firewalla, resolvera DNS i klienta.
• Nie działają tylko krótkie nazwy: sprawdź domenę wyszukiwania klienta i osobno przetestuj FQDN.
• Nie działa wyszukiwanie wsteczne: sprawdź strefę PTR oraz rekord PTR na serwerze docelowym.
• Problem dotyczy tylko klientów VPN: sprawdź przypisane serwery DNS, routing VPN i dostęp do lokalnej usługi DNS. Odpowiednie pola klienta opisano w artykułach Konfigurowanie Sophos Connect i Konfigurowanie zdalnego dostępu SSL VPN.

XML API: identyfikowanie trasy na podstawie nazwy obiektu

Od SFOS 23 dokumentacja XML API wymaga podczas dodawania i edytowania DNS Request Route zarówno Name, jak i DomainName. Name identyfikuje skonfigurowany obiekt, a DomainName — strefę DNS, której zapytania mają być przekazywane; na przykład Name = ad-intern i DomainName = ad.example.com. Są to wartości pól, a nie wykonywalny XML. Name to pojedyncza wartość STRING o maksymalnej długości 64 znaków; dopuszcza UTF-8 i zabrania przecinków. DomainName pozostaje polem typu FQDN o maksymalnej długości 255 znaków; nadal trzeba również podać serwery docelowe.

Przy usuwaniu udokumentowany klucz zmienia się z DomainName w SFOS 22 na Name w SFOS 23. Nie należy ponawiać starych żądań bez zmian ani automatycznie przyjmować nazwy domeny jako nazwy obiektu. Przed operacją trzeba sprawdzić zainstalowaną wersję i odczytać konkretny obiekt, porównać Name, DomainName, Target Servers oraz zależności z zamierzonym celem i udokumentować sposób wycofania zmiany. W przypadku niejednoznaczności należy przerwać operację. Po operacji trzeba sprawdzić odpowiedź API i status oraz ponownie odczytać dokładnie wskazany obiekt docelowy: usunięta może być wyłącznie zamierzona trasa; inne trasy muszą pozostać niezmienione. Następnie należy przetestować rozwiązywanie nazw wewnętrznych i publicznych zgodnie z opisem powyżej. Nie wymyślamy tu struktury żądania usuwania ani schematu REST i nie twierdzimy, że przeprowadzono test produktu.

Globalna konfiguracja protokołu DNS jest od tego niezależna. Artykuł o DNS Protection wyjaśnia nierozstrzygnięte sprzeczności w schemacie XML SFOS 23 i bezpieczną ścieżkę WebAdmin; cztery opcje resolvera opisane wyżej wyraźnie dla SFOS 22 nie potwierdzają numerycznego przyporządkowania w API SFOS 23.

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

Wycofanie zmian i eksploatacja

Przed wprowadzeniem zmiany należy udokumentować istniejące Request Routes, globalny wybór DNS, uprawnienia Device Access oraz wyniki testu pozytywnego i negatywnego. Standardowe wycofanie polega na usunięciu nowo utworzonej trasy lub przywróceniu dokładnie udokumentowanych poprzednich wartości. Wszystkie tymczasowe wyjątki ACL i przekierowania DNS również należy przywrócić do stanu początkowego.

Następnie trzeba ponownie sprawdzić trzy elementy:

1. Firewall rozwiązuje nazwę wewnętrzną i publiczną właściwymi ścieżkami.
2. Klient objęty zmianą korzysta z zamierzonego resolvera DNS i otrzymuje oczekiwane odpowiedzi.
3. Domena nieobjęta zmianą nie jest wysyłana do wewnętrznego Target Server.

Pełna kopia zapasowa konfiguracji nie jest wygodnym sposobem wycofania pojedynczego obiektu: jej odtworzenie zastępuje całą konfigurację i może nadpisać późniejsze zmiany. W przypadku jednej Request Route bezpieczniej jest cofnąć udokumentowaną zmianę obiektu.

Często zadawane pytania