Konfigurera och testa DNS Host Entries på Sophos Firewall

Med en DNS Host Entry kan Sophos Firewall besvara ett visst värdnamn direkt med en konfigurerad IP-adress. Det passar för ett mindre antal fasta interna system, till exempel en appliance, en hanteringstjänst eller ett servernamn som brandväggen själv måste kunna slå upp.

Posten får bara effekt om DNS-frågan faktiskt når brandväggen. Om en klient använder en domänkontrollant, en publik resolver eller DNS over HTTPS ser brandväggen inte frågan som DNS-resolver. En DNS Host Entry ersätter inte heller ett regelobjekt, routing, NAT eller en brandväggsregel.

⚠️ Publish on WAN förblir avstängt för interna poster. Publik publicering kräver en medveten auktoritativ DNS-design, lämpliga NS-poster, snävt begränsad Device Access och ett negativt rekursionstest. Enbart DNS-behörighet via ACL från WAN är inget skäl att exponera DNS-tjänsten publikt.

DNS Host Entry i åtta steg

1. Bekräfta att namnet är statiskt och att en hel intern DNS-zon inte behöver vidarebefordras.
2. Kontrollera att de berörda klienterna faktiskt använder Sophos Firewall som DNS-server.
3. Dokumentera FQDN, måladress, IP-version, TTL och en valfri PTR-post.
4. Ange namnet och adressen under Network > DNS > DNS host entry > Add.
5. Låt Publish on WAN vara avstängt för en intern post.
6. Kontrollera brandväggens vy under Network > DNS > Test name lookup.
7. Fråga uttryckligen brandväggens IP från klienten och testa framåt- och vid behov bakåtuppslagning.
8. Testa först därefter den faktiska applikationen och dokumentera posten tillsammans med dess beroenden.

När en DNS Host Entry passar

En DNS Host Entry passar för ett enskilt stabilt namn vars svar ska hanteras direkt på brandväggen. Typiska exempel är:

• en intern appliance utan egen DNS-post;
• ett fast FQDN för hantering av LDAP, RADIUS eller en annan tjänst;
• ett enskilt värdnamn för en kontrollerad migrering;
• en publik tjänst med medvetet planerad inbound DNS load balancing över flera WAN-adresser.

För en hel domän, Active Directory eller dynamiskt hanterade interna zoner är en DNS Request Route mer ändamålsenlig. Den vidarebefordrar zonen till den ansvariga DNS-servern i stället för att varje namn hanteras separat på brandväggen.

Även en IP Host eller FQDN Host har ett annat syfte. Dessa objekt används i brandväggs- och NAT-regler; de besvarar inte en klients DNS-fråga. Använd IP Hosts, Services och Groups korrekt förklarar objekttyperna.

En Dynamic DNS-konfiguration uppdaterar däremot ett namn hos en extern leverantör när en WAN-adress ändras. Hela förloppet beskrivs i Konfigurera Dynamic DNS på Sophos Firewall.

SFOS stöder posttyperna A, AAAA och PTR för DNS Host Entries. Funktionen är därför inte en fullständig auktoritativ DNS-server för CNAME, MX, TXT eller SRV. En DNS Host Entry kan innehålla högst åtta adresser och brandväggen stöder totalt högst 1024 DNS Host Entries.

Exempel och värden som ska ersättas

Exemplet visar en enskild intern applikationsserver:

• Värdnamn: app01.corp.example
• IPv4-adress: 192.0.2.20
• Klientnät: 10.20.30.0/24
• Brandväggens IP som DNS-server: 10.20.30.1
• Testklient: 10.20.30.50
• TTL: 300 sekunder
• Publish on WAN: avstängt
• Reverse DNS: valfritt aktiverat

Zonen .example och nätet 192.0.2.0/24 är reserverade för dokumentation. I en produktionsmiljö ersätts FQDN, adress, klientnät och resolver-IP med de faktiska värdena. Namnet ska passa den interna namnstrategin och får inte oavsiktligt åsidosätta en befintlig auktoritativ zon.

TTL-värdet 300 sekunder är ett kontrollerat exempel för test och migrering, inte en universell rekommendation. En kort TTL påskyndar planerade ändringar men genererar fler DNS-frågor. En lång TTL minskar antalet frågor men gör att gamla svar ligger kvar längre i cacheminnen efter en ändring.

Lägg till DNS Host Entry

Gå till Network > DNS, bläddra till DNS host entry och välj Add:

1. Ange app01.corp.example under Host/Domain name.
2. Använd en IP-adress som Entry type.
3. Ange 192.0.2.20 under IP address.
4. Ange 300 under Time-to-live.
5. Behandla inte Weight som ett lastbalanseringsverktyg när det bara finns en adress.
6. Låt Publish on WAN vara avstängt.
7. Aktivera Add reverse DNS lookup for this host entry endast om brandväggen också ska returnera ett PTR-svar för adressen.
8. Spara med Save.

För en IPv4-adress ger brandväggen ett A-svar och för en IPv6-adress ett AAAA-svar. Den valfria bakåtuppslagningen kopplar adressen tillbaka till namnet som PTR. Den skapar dock ingen PTR-post på en domänkontrollant eller extern DNS-server.

Om flera värdnamn pekar på samma IP-adress kan bara ett av dem vara mål för den omvända uppslagningen. Innan alternativet aktiveras måste det därför vara tydligt vilket namn som förväntas som kanoniskt PTR-svar.

Använd ett interface i stället för en fast adress

Som Entry Type kan ett interface väljas i stället för en fast IP-adress. Det passar när svaret medvetet ska följa interfacets aktuella adress, till exempel i en planerad publik Multi-WAN-design.

Valet av ett interface ersätter inte kontrollen av den faktiska WAN-vägen. Efter en adressändring, ett länkbyte eller HA-failover måste DNS-svaret, den nåbara tjänsten och returvägen testas på nytt med en ny anslutning.

Testa uppslagning på brandvägg och klient

Kontrollera först under Network > DNS > Test name lookup att brandväggen returnerar den förväntade adressen för app01.corp.example. Om Reverse DNS är aktiverat ska även 192.0.2.20 frågas.

Testet bekräftar endast brandväggens resolvervy. Därefter måste den berörda klienten uttryckligen fråga brandväggens IP 10.20.30.1.

Windows:

nslookup app01.corp.example 10.20.30.1
nslookup 192.0.2.20 10.20.30.1

Linux eller macOS:

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

Svaret måste innehålla den förväntade posten, rätt adress och vid bakåtuppslagning det avsedda namnet. Därefter testas applikationen via dess FQDN. Ett korrekt DNS-svar bevisar ännu inte att routing, brandväggsregel, NAT, TLS-certifikat och tjänst fungerar.

Om det är oklart om frågan når brandväggen kan ett snävt filter användas under Diagnostics > Packet capture, till exempel:

host 10.20.30.50 and port 53

Frågan och svaret måste synas på förväntat interface. Packet Capture på Sophos Firewall förklarar säker registrering och analys i detalj.

Använd flera adresser och vikter medvetet

En DNS Host Entry kan innehålla upp till åtta adresser. Funktionen är avsedd för inbound DNS load balancing eller failover över flera WAN-länkar, inte för en slumpmässig samling interna servrar.

Värdena för Weight bestämmer förhållandet i vilket svaren fördelas över de angivna länkarna. Beteendet bör kontrolleras med upprepade DNS-frågor och riktiga applikationsanslutningar. Fördelningen av DNS-svar bekräftar i sig varken att den publicerade tjänsten är nåbar eller att DNAT- och returvägen är korrekt.

Flera adresser blir inte automatiskt en allmän Health Check för interna applikationer. I en publik design dokumenterar Sophos failover för ett onåbart eller trasigt interface. Det garanterar inte att ett nåbart WAN-interface även levererar den bakomliggande applikationstjänsten korrekt.

Weighted DNS och DNAT-konfigurationen som skapas av Server Access Assistant får inte planeras samtidigt som en gemensam mekanism för samma DNS Host Entry. Publiceringen kräver en konsekvent design för DNS-svar, WAN-adress, DNAT, brandväggsregel, TLS och returväg. Publicera en server via DNAT förklarar datavägen separat.

Använd Publish on WAN endast för auktoritativa designer

Enbart Publish on WAN räcker inte för ett publikt svar. För att Sophos Firewall ska svara som Name Server för en publicerad tjänst måste den auktoritativa zonen delegeras till namnservernamn vars A-/AAAA- eller glue-poster pekar på de avsedda WAN-adresserna.

Följande krävs dessutom:

1. Den publika domänen och ansvarig DNS-zon är entydigt dokumenterade.
2. NS-delegeringen och tillhörande adress- eller glue-poster leder till de avsedda WAN-adresserna.
3. Under Administration > Device access tillåts DNS endast via nödvändig WAN-zon eller en snäv Local Service ACL Exception.
4. Publish on WAN är bara aktiverat för de avsedda adresserna.
5. Det publicerade namnet testas positivt från en extern resolver.
6. Icke-auktoritativa namn och rekursiva frågor testas negativt utifrån.
7. DNAT, brandväggsregel, certifikat och returväg för den faktiska tjänsten verifieras separat.

Ett ytterligare DNS ACL-undantag begränsar inte en redan aktiv bred WAN-zonbehörighet. DNS förblir avstängt för WAN i matrisen och tillåts via ett riktat undantag, eller så dokumenteras den bredare behörigheten som en medveten exponering. Device Access och Local Service ACL förklarar hur detta lager hanteras utan administrativ utelåsning.

Om delegeringen, svarsomfattningen eller skyddet mot rekursiv användning inte kan verifieras tydligt ska Publish on WAN inte aktiveras. För vanliga publika DNS-zoner är en dedikerad auktoritativ DNS-tjänst oftast den tydligare lösningen.

Avgränsa fel efter symptom

Brandväggen löser upp, men klienten gör det inte

• Kontrollera vilken DNS-server som faktiskt är konfigurerad på klienten. DHCP kan distribuera brandväggens IP; förloppet finns i Konfigurera DHCP Server på Sophos Firewall.
• Kontrollera DNS over HTTPS, VPN-klientinställningar och statiska resolvrar på klienten som alternativa vägar.
• Kontrollera under Administration > Device access om DNS är tillåtet från klientzonen.
• Bekräfta med Packet Capture om fråga och svar går via brandväggen.
• Ändra inte routing eller NAT så länge klienten inte frågar brandväggen alls.

Klienten får fortfarande den gamla adressen

• Kontrollera den aktuella posten avseende skrivfel, dubbla värdnamn och flera adresser.
• Ta hänsyn till den gamla TTL som fortfarande gäller samt lokala cacheminnen, webbläsar- och applikationscache.
• Skicka en ny explicit fråga till brandväggens IP i stället för att bara ladda om applikationen.
• Sänk TTL i god tid före en planerad migrering och låt den tidigare TTL löpa ut helt.

Tömning av en cache kan rätta till en enskild testklient, men ändrar inte svaren i andra resolvrar eller applikationscache. Det ersätter därför inte en kontrollerad väntetid och ett test genom den DNS-kedja som faktiskt används.

Bakåtuppslagning saknas eller visar fel namn

• Kontrollera att Add reverse DNS lookup for this host entry är aktiverat.
• Säkerställ att flera namn inte gör anspråk på samma adress som PTR-mål.
• Skicka den omvända frågan uttryckligen till brandväggens IP.
• För en intern reverse-zon på en domänkontrollant används lämplig DNS Request Route i stället för en lokal PTR-post.

Publik fråga får inget svar

• Kontrollera NS-delegeringen och WAN-adressernas nåbarhet utifrån.
• Kontrollera Publish on WAN för varje avsedd adress.
• Kontrollera Device Access, Local Service ACL, upstreamfilter samt UDP- och TCP-port 53.
• Registrera en Packet Capture under en specifik extern fråga.
• Aktivera inte bred DNS-behörighet som ett lösningsförsök.

DNS stämmer, men applikationen är fortfarande onåbar

DNS levererar bara måladressen. Därefter följer routing, brandväggsregel, NAT, TLS och den faktiska tjänsten. Testet bör därför kontrollera IP-adress, port och applikationsprotokoll i tur och ordning. Vid regel- och sökvägsproblem hjälper Testa en brandväggsregel med Log Viewer, Policy Test och Packet Capture.

Ändringar, HA och rollback

Före en ändring dokumenteras namn, aktuellt svar, TTL, bakåtuppslagning, använda klientresolvrar och beroende tjänster. Vid flera adresser ingår även viktning, WAN-tilldelning, NS-delegering, DNAT och returväg i utgångsläget.

I ett HA-kluster genomförs en ny DNS-fråga efter en planerad failover. Vid publik publicering testas dessutom båda WAN-vägarna och ett nytt applikationsflöde. Artikeln förutsätter varken synkroniserade DNS-cacheminnen eller en oavbruten aktiv anslutning.

För rollback:

1. Sänk TTL före en planerad migrering och vänta tills tidigare TTL har löpt ut.
2. Dokumentera beroende applikationer och den publika DNS-vägen.
3. Återställ adress, interface eller Host Entry till det bekräftade utgångsläget.
4. Ta bort ett tillfälligt Device Access-undantag och WAN-publicering som inte längre behövs.
5. Fråga uttryckligen igen från brandväggen och klienten.
6. Testa forward lookup, valfri PTR, nåbarhet och den faktiska applikationen på nytt.

Checklista

• Sophos Firewall ser DNS-frågan från den berörda klienten.
• Ett enskilt statiskt namn passar bättre än en DNS Request Route.
• FQDN, IP-version, adress och TTL är dokumenterade.
• Publish on WAN förblir avstängt för interna poster.
• En PTR-post är bara aktiverad för adressens kanoniska namn.
• Brandvägg och klient ger samma förväntade svar.
• DNS-åtkomsten är begränsad till nödvändiga källor i Device Access.
• Vid flera adresser har viktning, länkstatus och applikationsväg testats.
• Vid WAN-publicering är NS-delegering, namnserveradresser och ett negativt rekursionstest dokumenterade.
• Rollback och väntetid för cache är kända före ändringen.

Vanliga frågor