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.

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.
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. Jeden DNS Host Entry może zawierać maksymalnie osiem adresów; firewall obsługuje łącznie najwyżej 1024 DNS Host Entries.

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 > Test name lookup sprawdzić, czy firewall zwraca oczekiwany adres dla app01.corp.example. 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.

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

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

Wartości Weight określają proporcję, w jakiej odpowiedzi są rozdzielane między wymienione łącza. Zachowanie należy sprawdzić za pomocą powtarzanych zapytań DNS i rzeczywistych połączeń aplikacyjnych. Sam rozkład odpowiedzi 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.

Weighted DNS oraz konfiguracja DNAT utworzona przez Server Access Assistant nie powinny być planowane jednocześnie jako wspólny mechanizm dla tego samego DNS Host Entry. Publikacja wymaga 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.

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.

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