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.

Sökvägarna och fälten i guiden motsvarar SFOS 22.0 MR2 Build 546. Etiketterna kan skilja sig något i äldre versioner.

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. För inbound load balancing av ett namn stöds högst åtta adresser och brandväggen stöder totalt högst 1024 DNS Host Entries.

Sökvägar och omfattning för DNS-uppslagning

För frågor som brandväggen själv hanterar gäller följande konfigurationer:

• Om det efterfrågade namnet matchar en DNS host entry svarar brandväggen med adressen som lagrats där.
• Om en DNS request route matchar frågar brandväggen dess Target servers i angiven ordning efter en misslyckad cacheuppslagning. För det namnet återgår den inte till forwarders eller rootservrar.
• Utan en matchande lokal post eller Request Route använder den servrarna under DNS configuration. Statiska servrar frågas i ordning tills ett svar tas emot. NXDOMAIN är redan ett giltigt svar, och då frågas inte nästa server.

Hjälpen för SFOS 22 beskriver matchningen av Host Entries och Request Routes separat, men anger inte resultatet när samma namn matchar båda. Undvik en sådan överlappning: håll en Host Entry utanför en vidarebefordrad zon eller ta bort den dubbla lokala posten. Fråga därefter uttryckligen brandväggens IP för att bekräfta det avsedda svaret.

Dessa uppslagningsvägar gäller bara när brandväggen är resolver för frågan. En klient som direkt använder en domänkontrollant, publik resolver eller DNS over HTTPS kringgår posterna. Under Administration > Device access måste DNS dessutom tillåtas för källzonen eller via en lämplig Local Service ACL Exception; en vanlig brandväggsregel styr inte åtkomsten till denna lokala tjänst.

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

Använd först Test name lookup under Network > DNS för att kontrollera att brandväggen returnerar den förväntade adressen för app01.corp.example. Diagnostics > Tools > Name lookup frågar i stället en vald DNS server IP; Lookup using all configured servers jämför de konfigurerade DNS-servrarna och deras svarstider. Använd bara verktyget som en jämförelse av upstreamservrar, inte som bevis på att en lokal Host Entry eller Request Route matchade. 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.

För överlämning till support eller en jämförelse före och efter ändringen kan även dnsd.log hämtas under Diagnostics > Tools > Troubleshooting logs. En Consolidated troubleshooting report (CTR) innehåller dessutom status- och loggdata. Eftersom filerna kan innehålla uppgifter om konfiguration och miljö ska de endast delas via en säker supportkanal.

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.

Weight är länkens relativa vikt jämfört med övriga länkar i WAN link manager. Det är ingen Health Check av applikationen. Vid valideringen får nya externa DNS-frågor endast returnera aktiva WAN-adresser; därefter testas en ny applikationsanslutning för varje returnerad adress. Ett 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.

Enligt Sophos kan en DNAT-regel och weighted load balancing inte konfigureras samtidigt för samma DNS Host Entry. Publiceringen kräver därför 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.

Ett namn ligger kvar som localhost i cacheminnet för länge

För domäner som slås upp till localhost använder Sophos Firewall inte bara TTL-värdet i DNS-posten. Brandväggen frågar efter dessa namn igen enligt intervallet localhost-ttl. Standardvärdet är 655360 sekunder och det tillåtna intervallet är 60 till 655360 sekunder. När en post ändras från localhost till en annan värd kan brandväggen därför behålla det gamla svaret längre än en vanlig klient.

Bekräfta först med en direkt fråga till den auktoritativa eller avsedda resolvern att posten inte längre pekar på localhost. Läs sedan det aktuella SFOS-värdet i Device Console:

show dns

Endast när just detta fall har bekräftats bör det globala intervallet minskas tillfälligt. 300 sekunder är här ett exempel för ett kontrollerat migrationstest, inte en allmän rekommendation:

set dns localhost-ttl 300

Ett lägre värde ger fler DNS-frågor och är inte en omedelbar tömning av cacheminnet. Testa efter ändringen namnuppslagningen igen från brandväggen och en riktig klient. Om minskningen bara behövdes för migreringen återställs sedan produktens standardvärde:

set dns localhost-ttl default

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