Konfiguracja i testowanie DNS Host Entries na Sophos Firewall

DNS Host Entry pozwala Sophos Firewall odpowiadać bezpośrednio na określoną nazwę hosta za pomocą skonfigurowanego adresu IP. Rozwiązanie pasuje do niewielkiej liczby stałych systemów wewnętrznych, takich jak appliance, usługa zarządzająca albo nazwa serwera, którą musi rozwiązywać sam firewall.

Pasująca odpowiedź lokalna eliminuje dodatkowe zapytanie do autorytatywnego DNS dla tego żądania i może przyspieszyć rozwiązywanie nazwy. Nie gwarantuje określonego czasu odpowiedzi ani nie pomaga klientowi, którego zapytanie omija resolver firewalla.

Pola Host Entry są udokumentowane dla SFOS 22.0 i 23.0; nie dowodzi to przeprowadzenia testów na konkretnym buildzie. SFOS 23 rozróżnia nieszyfrowany DNS, DNS over HTTPS (DoH) i DNS Protection przy rozwiązywaniu nazw zewnętrznych. Artykuł o DNS Request Routes wyjaśnia globalny wybór resolvera, pobieranie DNS przez DHCP/PPPoE oraz różnicę między tradycyjnym DNS Protection a zintegrowaną ścieżką SFOS 23. Dla pojedynczej nazwy lokalnej nie trzeba przebudowywać globalnej konfiguracji.

Wpis działa tylko wtedy, gdy zapytanie DNS rzeczywiście dociera do firewalla. Jeśli klient używa kontrolera domeny, publicznego resolvera albo DNS over HTTPS, firewall nie widzi tego zapytania jako resolver DNS. DNS Host Entry nie zastępuje również obiektu reguły, routingu, NAT ani reguły firewall.

⚠️ Publish on WAN pozostaje wyłączone dla wpisów wewnętrznych. Publikacja publiczna wymaga świadomie zaprojektowanego autorytatywnego DNS, odpowiednich rekordów NS, ściśle ograniczonego Device Access oraz negatywnego testu rekursji. Samo zezwolenie DNS ACL z WAN nie jest powodem do publicznego udostępnienia usługi DNS.

DNS Host Entry w ośmiu krokach

1. Potwierdzić, że nazwa jest statyczna i nie trzeba przekazywać całej wewnętrznej strefy DNS.
2. Sprawdzić, czy zainteresowane urządzenia klienckie rzeczywiście używają Sophos Firewall jako serwera DNS.
3. Udokumentować FQDN, adres docelowy, wersję IP, TTL i opcjonalny rekord PTR.
4. Wprowadzić nazwę i adres w Network > DNS > DNS host entry > Add.
5. Dla wpisu wewnętrznego pozostawić Publish on WAN wyłączone.
6. Sprawdzić widok firewalla w Network > DNS > Test name lookup (SFOS 22) / Test name resolution (SFOS 23).
7. Z klienta jawnie odpytać adres IP firewalla i przetestować rozwiązywanie do przodu oraz, jeśli jest potrzebne, odwrotne.
8. Dopiero potem przetestować właściwą aplikację i udokumentować wpis wraz z zależnościami.

Kiedy DNS Host Entry jest właściwym wyborem

DNS Host Entry pasuje do jednej stabilnej nazwy, dla której odpowiedź ma być utrzymywana bezpośrednio na firewallu. Typowe przykłady to:

• wewnętrzny appliance bez własnego rekordu DNS;
• stały FQDN zarządzający dla LDAP, RADIUS lub innej usługi;
• pojedyncza nazwa hosta na potrzeby kontrolowanej migracji;
• usługa publiczna ze świadomie zaplanowanym inbound DNS load balancing przez wiele adresów WAN.

Dla całej domeny, Active Directory lub dynamicznie utrzymywanych stref wewnętrznych lepszym rozwiązaniem jest DNS Request Route. Przekazuje ona strefę do właściwego serwera DNS zamiast utrzymywać każdą nazwę osobno na firewallu.

Również IP Host lub FQDN Host służy do innego celu. Obiekty te są używane w regułach firewall i NAT; nie odpowiadają na zapytania DNS klientów. Typy obiektów opisuje Prawidłowe używanie IP Hosts, Services i Groups.

Konfiguracja Dynamic DNS aktualizuje natomiast nazwę u zewnętrznego dostawcy, gdy zmienia się adres WAN. Pełną procedurę przedstawia Konfiguracja Dynamic DNS na Sophos Firewall.

SFOS obsługuje dla DNS Host Entries typy rekordów A, AAAA i PTR. Funkcja nie jest więc pełnym autorytatywnym serwerem DNS dla CNAME, MX, TXT ani SRV. Dla inbound load balancing jednej nazwy można użyć maksymalnie ośmiu adresów; firewall obsługuje łącznie najwyżej 1024 DNS Host Entries.

Ścieżki i zakres rozwiązywania DNS

Dla zapytań obsługiwanych przez sam firewall stosowane są następujące konfiguracje:

• Jeśli żądana nazwa pasuje do DNS host entry, firewall odpowiada zapisanym w niej adresem.
• Jeśli pasuje DNS request route, po nieudanym sprawdzeniu cache firewall odpytuje jej Target servers w skonfigurowanej kolejności. Dla tej nazwy nie wraca do forwarderów ani serwerów głównych.
• Bez pasującego wpisu lokalnego lub Request Route używa serwerów określonych w DNS configuration. Serwery statyczne są odpytywane kolejno do chwili otrzymania odpowiedzi. NXDOMAIN jest już prawidłową odpowiedzią, więc następny serwer nie jest odpytywany.

Pomoc SFOS 22 opisuje osobno dopasowywanie Host Entries i Request Routes, ale nie określa wyniku, gdy ta sama nazwa pasuje do obu. Należy unikać takiego nakładania się konfiguracji: Host Entry musi znajdować się poza przekazywaną strefą albo trzeba usunąć zduplikowany wpis lokalny. Następnie należy jawnie odpytać adres IP firewalla, aby potwierdzić zamierzoną odpowiedź.

Te ścieżki rozwiązywania obowiązują tylko wtedy, gdy firewall jest resolverem zapytania. Klient używający bezpośrednio kontrolera domeny, publicznego resolvera lub DNS over HTTPS omija te wpisy. W Administration > Device access trzeba również zezwolić na DNS dla strefy źródłowej lub przez odpowiednią Local Service ACL Exception; zwykła reguła firewall nie steruje dostępem do tej usługi lokalnej.

Skonfigurowane serwery DNS mają pierwszeństwo przed serwerami głównymi przy ogólnym rozwiązywaniu DNS przez adres IP interfejsu firewalla. Nie gwarantuje to, że każde nieudane zapytanie zostanie rozwiązane przez serwery główne. Zapytania pasujące do Request Route pozostają kierowane do zdefiniowanych Target Servers.

Przykład i wartości do zastąpienia

Przykład odwzorowuje pojedynczy wewnętrzny serwer aplikacyjny:

• Nazwa hosta: app01.corp.example
• Adres IPv4: 192.0.2.20
• Sieć klientów: 10.20.30.0/24
• Adres IP firewalla jako serwera DNS: 10.20.30.1
• Klient testowy: 10.20.30.50
• TTL: 300 sekund
• Publish on WAN: wyłączone
• Reverse DNS: opcjonalnie włączone

Strefa .example oraz sieć 192.0.2.0/24 są zarezerwowane do celów dokumentacyjnych. W środowisku produkcyjnym FQDN, adres, sieć klientów i adres resolvera należy zastąpić rzeczywistymi wartościami. Nazwa powinna odpowiadać wewnętrznej strategii nazewnictwa i nie może przypadkowo przesłaniać istniejącej strefy autorytatywnej.

TTL wynoszący 300 sekund jest kontrolowaną wartością przykładową do testów i migracji, a nie uniwersalnym zaleceniem. Krótki TTL przyspiesza planowane zmiany, ale generuje więcej zapytań DNS. Długi TTL ogranicza liczbę zapytań, ale po zmianie dłużej utrzymuje stare odpowiedzi w pamięci podręcznej.

Dodawanie DNS Host Entry

W Network > DNS przewinąć do DNS host entry i wybrać Add:

1. W Host/Domain name wpisać app01.corp.example.
2. Jako Entry type wybrać adres IP.
3. W IP address wpisać 192.0.2.20.
4. W Time-to-live wpisać 300.
5. Przy pojedynczym adresie nie traktować Weight jako narzędzia równoważenia obciążenia.
6. Pozostawić Publish on WAN wyłączone.
7. Włączyć Add reverse DNS lookup for this host entry tylko wtedy, gdy firewall ma również zwracać odpowiedź PTR dla tego adresu.
8. Zapisać przez Save.

Dla adresu IPv4 firewall zwraca odpowiedź A, a dla adresu IPv6 odpowiedź AAAA. Opcjonalny reverse lookup mapuje adres z powrotem na nazwę jako PTR. Nie tworzy jednak rekordu PTR na kontrolerze domeny ani na zewnętrznym serwerze DNS.

Jeżeli wiele nazw hostów wskazuje na ten sam adres IP, tylko jedna z nich może być celem odwrotnego mapowania. Przed włączeniem tej opcji trzeba więc ustalić, która nazwa ma być kanoniczną odpowiedzią PTR.

Użycie interfejsu zamiast stałego adresu

Jako Entry Type zamiast stałego adresu IP można wybrać interfejs. Jest to właściwe, gdy odpowiedź ma świadomie podążać za aktualnym adresem tego interfejsu, na przykład w planowanej publicznej architekturze Multi-WAN.

Wybór interfejsu nie zastępuje kontroli rzeczywistej ścieżki WAN. Po zmianie adresu, przełączeniu łącza lub failover HA trzeba ponownie przetestować odpowiedź DNS, dostępność usługi i ścieżkę powrotną za pomocą nowego połączenia.

Testowanie rozwiązywania na firewallu i kliencie

Najpierw w Network > DNS użyć Test name lookup (SFOS 22) / Test name resolution (SFOS 23), aby sprawdzić, czy firewall zwraca oczekiwany adres dla app01.corp.example. Diagnostics > Tools > Name lookup (SFOS 22) odpytuje natomiast wybrany DNS server IP, a Lookup using all configured servers porównuje skonfigurowane serwery DNS i ich czasy odpowiedzi. Tego narzędzia należy używać tylko do porównania serwerów upstream, a nie jako dowodu, że dopasowano lokalny Host Entry lub Request Route. Jeżeli Reverse DNS jest włączone, należy również odpytać 192.0.2.20.

Ten test potwierdza tylko widok resolvera firewalla. Następnie zainteresowany klient musi jawnie odpytać adres IP firewalla 10.20.30.1.

W SFOS 23 sekcja diagnostyczna to DNS lookup, z polami Hostname or IP address, DNS server IP address oraz opcją All configured servers. Custom DNS server i Custom DoH server odpytują wskazany adres IP serwera; DNS Protection jest dostępny tylko po włączeniu w Network > DNS. Dla wewnętrznej nazwy testowej wybrać wyłącznie zatwierdzony wewnętrzny resolver, aby nie ujawnić nazwy publicznej usłudze DNS lub DoH. Te opcje diagnostyczne nie dowodzą dopasowania lokalnego wpisu; nadal konieczne jest jawne zapytanie z klienta opisane poniżej.

W teście SFOS 23 w Network > DNS > Test name resolution wprowadzić FQDN lub adres w Hostname or IP address i wybrać Test connection. Wynik pokazuje użyty serwer DNS, protokół, status rozwiązywania nazwy oraz czasy odpowiedzi; porównać te dane z zamierzoną ścieżką resolvera. Test z klienta pozostaje oddzielnym krokiem:

Windows:

nslookup app01.corp.example 10.20.30.1
nslookup 192.0.2.20 10.20.30.1

Linux lub macOS:

dig @10.20.30.1 app01.corp.example A
dig @10.20.30.1 -x 192.0.2.20

Odpowiedź musi zawierać oczekiwany rekord, właściwy adres oraz, w przypadku reverse lookup, przewidzianą nazwę. Następnie należy przetestować aplikację przez FQDN. Poprawna odpowiedź DNS nie dowodzi jeszcze, że działają routing, reguła firewall, NAT, certyfikat TLS i usługa.

Jeśli nie wiadomo, czy zapytanie dociera do firewalla, w Diagnostics > Packet capture można użyć wąskiego filtra, na przykład:

host 10.20.30.50 and port 53

Zapytanie i odpowiedź muszą być widoczne na oczekiwanym interfejsie. Packet Capture na Sophos Firewall szczegółowo opisuje bezpieczne przechwytywanie i analizę.

Na potrzeby zgłoszenia do pomocy technicznej lub porównania stanu przed i po zmianie można również pobrać dnsd.log w Diagnostics > Tools > Troubleshooting logs. Consolidated troubleshooting report (CTR) zawiera dodatkowo dane o stanie i logi. Ponieważ pliki te mogą obejmować szczegóły konfiguracji i środowiska, należy je udostępniać wyłącznie przez bezpieczny kanał pomocy technicznej.

Świadome użycie wielu adresów i wag

DNS Host Entry może zawierać do ośmiu adresów. Funkcja jest przeznaczona do inbound DNS load balancing lub failover przez wiele łączy WAN, a nie do przypadkowej kolekcji serwerów wewnętrznych.

⚠️ Nie łączyć wag i DNAT bez wyjaśnienia projektu: Pomoc Host Entry opisuje Weight w odniesieniu do WAN link manager, natomiast przebieg Multi-WAN wiąże odpowiedź z interfejsem WAN, na który przychodzi zapytanie. Pomoc DNAT zabrania też reguły DNAT razem z weighted load balancing dla tego samego DNS Host Entry. Te informacje nie dowodzą konkretnej proporcji odpowiedzi DNS ani działania połączonego projektu DNAT. Jeśli usługa publiczna zależy od tej kombinacji, przed publikacją WAN należy się zatrzymać i wyjaśnić konkretny projekt dla zainstalowanej wersji; nie zakładać, że inne wagi stanowią obejście.

Dla dwóch adresów WAN utrzymuje się tę samą nazwę w jednym Host Entry: wprowadzić na przykład www.example.com w Host/Domain name i 192.0.2.10 jako pierwszy IP address, a następnie użyć Add w formularzu, aby dodać drugi adres, i wpisać 198.51.100.10. Są to adresy dokumentacyjne, które należy zastąpić rzeczywistymi adresami WAN. Włączyć Publish on WAN dla obu przewidzianych adresów tylko po spełnieniu wymagań z następnej sekcji, a następnie zapisać przez Save. Dwie różne nazwy hostów nie zapewniałyby równoważenia obciążenia tej samej usługi.

W udokumentowanym przebiegu Multi-WAN zewnętrzny resolver podąża za delegacją NS i odpytuje firewall przez aktywne łącze WAN. Firewall zwraca adres WAN interfejsu, na którym odebrano to zapytanie, a resolver przekazuje ten adres klientowi. Późniejszy dostęp do aplikacji stanowi osobny przepływ danych. Podczas weryfikacji należy więc osobno odpytać obie ścieżki WAN i porównać zwrócone adresy; po awarii łącza trzeba wykonać nowe zapytanie DNS. Nie usuwa to odpowiedzi już zapisanych w cache przed wygaśnięciem ich TTL.

Weight to względna waga łącza w porównaniu z pozostałymi łączami w WAN link manager. Nie jest to Health Check aplikacji. Podczas weryfikacji nowe zewnętrzne zapytania DNS powinny zwracać wyłącznie aktywne adresy WAN; następnie dla każdego zwróconego adresu trzeba przetestować nowe połączenie z aplikacją. Sama odpowiedź DNS nie potwierdza ani dostępności publikowanej usługi, ani prawidłowej ścieżki DNAT i powrotnej.

Wiele adresów nie staje się automatycznie ogólnym Health Check dla aplikacji wewnętrznych. W publicznym projekcie Sophos dokumentuje failover dla nieosiągalnego lub uszkodzonego interfejsu. Nie gwarantuje to, że osiągalny interfejs WAN prawidłowo dostarczy również usługę aplikacyjną znajdującą się za nim.

Według Sophos reguły DNAT i weighted load balancing nie można jednocześnie skonfigurować dla tego samego DNS Host Entry. Publikacja wymaga więc spójnego projektu obejmującego odpowiedź DNS, adres WAN, DNAT, regułę firewall, TLS i ścieżkę powrotną. Publikowanie serwera przez DNAT opisuje osobno ścieżkę danych.

Publish on WAN tylko dla projektów autorytatywnych

Samo Publish on WAN nie wystarcza do publicznej odpowiedzi. Aby Sophos Firewall odpowiadał jako Name Server dla publikowanej usługi, strefa autorytatywna musi być delegowana do nazw serwerów DNS, których rekordy A/AAAA lub glue wskazują na przewidziane adresy WAN.

Wymagane są również następujące elementy:

1. Domena publiczna i odpowiedzialna strefa DNS są jednoznacznie udokumentowane.
2. Delegacja NS oraz powiązane rekordy adresowe lub glue prowadzą do przewidzianych adresów WAN.
3. W Administration > Device access DNS jest dozwolony tylko przez wymaganą strefę WAN lub ściśle ograniczoną Local Service ACL Exception.
4. Publish on WAN jest włączone wyłącznie dla przewidzianych adresów.
5. Publikowana nazwa jest pozytywnie testowana z zewnętrznego resolvera.
6. Nazwy nieautorytatywne i zapytania rekursywne są negatywnie testowane z zewnątrz.
7. DNAT, reguła firewall, certyfikat i ścieżka powrotna właściwej usługi są weryfikowane osobno.

Dodatkowy wyjątek DNS ACL nie zawęża już aktywnego szerokiego zezwolenia strefy WAN. DNS pozostaje wyłączony dla WAN w macierzy i jest dozwolony przez precyzyjny wyjątek albo szersze zezwolenie zostaje udokumentowane jako świadoma ekspozycja. Device Access i Local Service ACL wyjaśnia bezpieczne dla dostępu administracyjnego postępowanie z tą warstwą.

Jeżeli nie można jednoznacznie zweryfikować delegacji, zakresu odpowiedzi lub ochrony przed użyciem rekursywnym, nie należy włączać Publish on WAN. Dla zwykłych publicznych stref DNS dedykowana autorytatywna usługa DNS jest zazwyczaj bardziej przejrzystym rozwiązaniem.

Zawężanie błędów według objawu

Firewall rozwiązuje nazwę, ale klient nie

• Sprawdzić, który serwer DNS jest rzeczywiście skonfigurowany na kliencie. DHCP może rozsyłać adres IP firewalla; procedurę opisuje Konfiguracja DHCP Server na Sophos Firewall.
• Sprawdzić DNS over HTTPS, ustawienia klienta VPN i statyczne resolvery na kliencie jako alternatywne ścieżki.
• W Administration > Device access sprawdzić, czy DNS jest dozwolony ze strefy klienta.
• Za pomocą Packet Capture potwierdzić, czy zapytanie i odpowiedź przechodzą przez firewall.
• Nie zmieniać routingu ani NAT, dopóki klient w ogóle nie odpytuje firewalla.

Klient nadal otrzymuje stary adres

• Sprawdzić aktualny wpis pod kątem literówek, zduplikowanych nazw hostów i wielu adresów.
• Uwzględnić nadal obowiązujący stary TTL oraz lokalne pamięci podręczne, cache przeglądarki i aplikacji.
• Wysłać nowe jawne zapytanie do adresu IP firewalla zamiast tylko ponownie ładować aplikację.
• Przed planowaną migracją odpowiednio wcześnie obniżyć TTL i poczekać na pełne wygaśnięcie poprzedniego TTL.

Wyczyszczenie cache może naprawić pojedynczego klienta testowego, ale nie zmienia odpowiedzi w innych resolverach ani pamięciach podręcznych aplikacji. Nie zastępuje więc kontrolowanego czasu oczekiwania ani testu przez faktycznie używany łańcuch DNS.

Nazwa zbyt długo pozostaje w cache jako localhost

Dla domen, które rozwiązują się na localhost, Sophos Firewall nie korzysta po prostu z TTL rekordu DNS. Zapora ponawia zapytania o takie nazwy zgodnie z interwałem localhost-ttl. Wartość domyślna wynosi 655360 sekund, a dozwolony zakres od 60 do 655360 sekund. Gdy rekord zostanie zmieniony z localhost na inny host, zapora może więc zachować starą odpowiedź dłużej niż zwykły klient.

Najpierw bezpośrednim zapytaniem do autorytatywnego lub przewidzianego resolvera należy potwierdzić, że rekord nie wskazuje już na localhost. Następnie odczytać bieżącą wartość SFOS w Device Console:

show dns

⚠️ Przed zmianą interwału zachować wartość początkową odczytaną za pomocą show dns i pozostawić niezależny dostęp administracyjny. Zmiana jest globalna, a nie ograniczona do tego Host Entry. Mniejsza wartość powoduje częstsze zapytania DNS i nie czyści pamięci podręcznej natychmiast.

Tylko gdy potwierdzono dokładnie ten przypadek, można tymczasowo zmniejszyć globalny interwał. 300 sekund jest tu przykładem do kontrolowanego testu migracji, a nie ogólnym zaleceniem:

set dns localhost-ttl 300

Po zmianie sprawdzić show dns i ponownie przetestować rozwiązywanie nazw z perspektywy zapory i rzeczywistego klienta. Ustawienie domyślne produktu przywrócić w ten sposób tylko wtedy, gdy było używane wcześniej:

set dns localhost-ttl default

Jeśli poprzedni interwał był niestandardowy, użyć zamiast tego set dns localhost-ttl <previous-seconds>, zastępując <previous-seconds> zapisaną liczbą; nie wpisywać dosłownie symbolu zastępczego. Następnie sprawdzić przywróconą wartość przez show dns i rozwiązywanie nazw nowym zapytaniem. Jeśli wartość początkowa jest nieznana, default nie stanowi zweryfikowanego rollbacku.

Brakuje reverse lookup lub pojawia się nieprawidłowa nazwa

• Sprawdzić, czy Add reverse DNS lookup for this host entry jest włączone.
• Upewnić się, że wiele nazw nie przypisuje sobie tego samego adresu jako celu PTR.
• Wysłać zapytanie odwrotne jawnie do adresu IP firewalla.
• Dla wewnętrznej strefy odwrotnej na kontrolerze domeny użyć odpowiedniej DNS Request Route zamiast lokalnego wpisu PTR.

Zapytanie publiczne nie otrzymuje odpowiedzi

• Z zewnątrz sprawdzić delegację NS i osiągalność adresów WAN.
• Sprawdzić Publish on WAN dla każdego przewidzianego adresu.
• Sprawdzić Device Access, Local Service ACL, filtry upstream oraz port 53 UDP i TCP.
• Zarejestrować Packet Capture podczas jednego konkretnego zapytania zewnętrznego.
• Nie włączać szerokiego zezwolenia DNS jako próby rozwiązania problemu.

DNS jest poprawny, ale aplikacja pozostaje nieosiągalna

DNS dostarcza tylko adres docelowy. Następnie działają routing, reguła firewall, NAT, TLS i właściwa usługa. Test powinien więc kolejno sprawdzić adres IP, port i protokół aplikacyjny. W przypadku problemów z regułą i ścieżką pomocny jest artykuł Testowanie reguły firewall za pomocą Log Viewer, Policy Test i Packet Capture.

XML API: nazwa obiektu i nazwa DNS od SFOS 23

W automatyzacji Name i HostName są różnymi polami: Name oznacza skonfigurowany obiekt, a HostName — nazwę DNS do rozwiązania. Dokumentacja SFOS 23 wymaga obu pól podczas dodawania i edytowania. Name to pojedyncza wartość STRING o maksymalnej długości 64 znaków; UTF-8 jest dozwolony, przecinek nie. HostName pozostaje polem typu DOMAINNAMELOOKUP o maksymalnej długości 253 znaków. Na przykład Name = app01-intern i HostName = app01.corp.example mogą mieć różne wartości; jest to przypisanie wartości do pól, a nie wykonywalny XML.

Przy usuwaniu dokumentacja SFOS 22 wskazuje HostName jako klucz, natomiast SFOS 23 — Name. Nie należy więc ponawiać starych żądań SFOS 22 bez zmian ani automatycznie używać nazwy DNS jako nazwy obiektu. Przed wywołaniem usuwania należy sprawdzić zainstalowaną wersję, odczytać konkretny obiekt i porównać nazwę obiektu, nazwę DNS, adresy oraz zależności z udokumentowanym celem. Jeśli tożsamość obiektu jest niejednoznaczna, należy przerwać operację. Następnie trzeba sprawdzić odpowiedź API wraz ze statusem i ponownie odczytać dokładnie wskazany obiekt docelowy: brakować może wyłącznie zamierzonego obiektu; inne wpisy muszą pozostać niezmienione. Sam sukces na poziomie transportu nie potwierdza pomyślnego usunięcia. Nie podajemy tu struktury żądania usuwania ani nie twierdzimy, że przeprowadzono test produktu.

Nierozstrzygnięta sprzeczność dotycząca Reverse DNS: w obu wersjach przykład API dla AddReverseDNSLookUp pokazuje Enable/Disable, ale tabela parametrów dopuszcza wyłącznie Enable, a jednocześnie podaje Disable jako wartość domyślną. Nie można na tej podstawie wyprowadzić bezpiecznego żądania z Disable ani z pominięciem pola. Do czasu wyjaśnienia przez producenta nie należy stosować takiej receptury API; zamiast tego trzeba świadomie ustawić Reverse DNS w opisanej wyżej procedurze WebAdmin i osobno sprawdzić PTR. Instrukcja dotycząca UI nie potwierdza semantyki wartości wyliczeniowych API.

Do walidacji pól XML w SFOS 22 i 23 odnoszą się również następujące udokumentowane ograniczenia; nie gwarantują one ustawień domyślnych WebAdmin:

• Maksymalnie osiem elementów Address w AddressList. IPFamily, EntryType, IPAddress, TTL, Weight i PublishOnWAN są udokumentowane jako obowiązkowe dla Add/Edit; ich wartości w tabeli są tablicami, a duplikaty nie są ignorowane.
• IPFamily: IPv4 lub IPv6; EntryType: Manual lub InterfaceIP. Dla InterfaceIP przykład XML wymaga nazwy interfejsu w IPAddress, a nie stałego adresu IP.
• IPAddress ma typ STRING; tabela wyklucza klasy MULTICAST, RESERVED, UNSPECIFIED, BROADCAST i LINKLOCAL. Nie kopiować więc adresów dokumentacyjnych z tego artykułu do produkcyjnego wywołania API bez walidacji.
• TTL to INTEGER od 1 do 604800 sekund, maksymalnie sześć cyfr; tabela podaje 3600 jako wartość domyślną. Mimo to jawnie ustawić to obowiązkowe pole. Weight to INTEGER od 0 do 255, maksymalnie trzy cyfry; ten zakres nie dowodzi konkretnego działania wagi 0.
• PublishOnWAN dopuszcza Enable lub Disable. Nie przenosić tych jednoznacznych wartości przez analogię na opisaną wyżej sprzeczną definicję AddReverseDNSLookUp.

Tabele statusów rozróżniają Add, Edit i Delete, ale nie wyjaśniają wszystkich wymienionych kodów błędów. W razie błędu zachować pełną odpowiedź API i bieżący stan obiektu przed ponowieniem wywołania modyfikującego; nie wyciągać wniosków o sukcesie ani przyczynie wyłącznie z transportu HTTP.

Zmiany, HA i rollback

Przed zmianą należy udokumentować nazwę, bieżącą odpowiedź, TTL, reverse lookup, używane resolvery klientów oraz zależne usługi. Przy wielu adresach stan początkowy obejmuje również wagi, przypisanie WAN, delegację NS, DNAT i ścieżkę powrotną.

W klastrze HA po planowanym failover należy wykonać nowe zapytanie DNS. Przy publikacji publicznej trzeba również przetestować obie ścieżki WAN oraz nowy przepływ aplikacyjny. Artykuł nie zakłada synchronizacji cache DNS ani nieprzerwanej aktywnej sesji.

Rollback przebiega następująco:

1. Przed planowaną migracją obniżyć TTL i poczekać na wygaśnięcie poprzedniego TTL.
2. Udokumentować zależne aplikacje i publiczną ścieżkę DNS.
3. Przywrócić adres, interfejs lub Host Entry do potwierdzonego stanu początkowego.
4. Usunąć tymczasowy wyjątek Device Access i niepotrzebną już publikację WAN.
5. Ponownie wykonać jawne zapytanie z firewalla i klienta.
6. Ponownie przetestować forward lookup, opcjonalny PTR, osiągalność oraz właściwą aplikację.

Lista kontrolna

• Sophos Firewall widzi zapytanie DNS od zainteresowanego klienta.
• Pojedyncza nazwa statyczna pasuje lepiej niż DNS Request Route.
• FQDN, wersja IP, adres i TTL są udokumentowane.
• Publish on WAN pozostaje wyłączone dla wpisów wewnętrznych.
• Wpis PTR jest włączony tylko dla kanonicznej nazwy adresu.
• Firewall i klient zwracają tę samą oczekiwaną odpowiedź.
• Dostęp DNS jest ograniczony w Device Access do wymaganych źródeł.
• Przy wielu adresach przetestowano wagi, stan łączy i ścieżkę aplikacji.
• Przy publikacji WAN udokumentowano delegację NS, adresy serwerów DNS i negatywny test rekursji.
• Rollback i czas oczekiwania na cache są znane przed zmianą.

Często zadawane pytania