En resolver til dine enheder, ikke en åben forstærker.

Vælg rollen

En rekursiv resolver som Unbound og en filtreringsgrænseflade som AdGuard Home løser beslægtede, men forskellige problemer. Beslut, om tjenesten selv rekurserer eller videresender til en upstream, og forstå, hvilken part der derefter ser forespørgslerne.

Hold det privat

En ubegrænset offentlig resolver kan misbruges til refleksionsangreb. Bind til et privat netværk, eller tillad kun autoriserede kilder, herunder IPv6. Hvis du bruger krypteret DNS, skal du godkende eller på anden måde begrænse adgangen passende i stedet for at antage, at HTTPS gør den privat.

Fastlæg en logningspolitik

DNS-forespørgsler kan afsløre følsom browsing- og applikationsaktivitet. Deaktivér unødvendig opbevaring, beskyt de registreringer, du beholder, og forklar omfanget over for brugerne. Krypteret transport beskytter en vej; det forhindrer ikke resolveren selv i at se forespørgsler.

Test mere end ét navn

Verificér DNSSEC-adfærd, hvor det er aktiveret, IPv4- og IPv6-resultater, filtreringsundtagelser og gendannelse, når en upstream fejler. Bevar en sikker måde at rette adgang på uden udelukkende at afhænge af den resolver, du reparerer.

Bevis, at fremmede ikke kan forespørge den

Bind resolveren til det tilsigtede interface, definér de tilladte klientområder og begræns firewallen. Validér konfigurationen, før du genstarter. Forespørg fra en autoriseret klient, og gentag derefter udefra det betroede netværk: den anmodning bør afvises eller time out. Kontrollér IPv6 separat. En resolver, der accepterer vilkårlige internetforespørgsler, kan blive en kilde til misbrug.

• Kør konfigurationsvalideringen, før ændringer anvendes
• Test en tilladt klient og en afvist klient
• Hold detaljerede forespørgselsdiagnostik midlertidig

unbound-checkconf

Officiel dokumentation: Ubegrænset adgangskontrolkonfiguration

Hold krypterede DNS-påstande præcise

DNS-over-HTTPS eller DNS-over-TLS krypterer en bestemt transportvej. Resolveren modtager stadig forespørgslen, og en videresendende resolver kan sende den videre til en anden operatør. Gennemgå valg af upstream og opbevaring. Hvis du eksponerer et krypteret resolver-endpoint, skal dets adgangspolitik være lige så bevidst som den almindelige DNS-port.

Vælg resolverkæden, før du åbner en port

Et brugbart privat design er en VPN-klient, der forespørger AdGuard Home, hvor AdGuard videresender til Unbound på loopback. Unbound udfører derefter rekursion; AdGuard tilføjer filtrering og en administrationsgrænseflade. Alternativt kan du kun bruge Unbound til en mindre stak. Giv hver lytter en distinkt adresse/port, og tegn videresendelsesretningen: at sende Unbound tilbage til AdGuard skaber en løkke. Beslut, hvilke private klienter der må bruge tjenesten, før du offentliggør noget.

• Hold offentlig indgående TCP og UDP 53 lukket, medmindre der er en specifik politik for autoriserede klienter.
• Giv filtreringsgrænsefladen og DNS-lytteren separate adgangsregler.
• Kontroller portens ejerskab før installation; en eksisterende systemresolver kan allerede binde den tilsigtede adresse.

Officiel dokumentation: Opsætning af AdGuard Home

Et loopback-Unbound-udgangspunkt

På et system, hvor Unbound allerede er installeret, illustrerer følgende fragment en backend, der kun kan nås på værten. Integrer det med distributionens konfiguration i stedet for at overskrive pakkeindstillinger eller håndtering af trust-anchors. Den høje port lader en anden DNS-frontend bruge port 53. Valider den komplette effektive fil, og genindlæs derefter via den installerede tjenestestyring. En fjernklient har brug for en separat kontrolleret tunnel eller frontend; dette fragment opretter bevidst ingen offentlig resolver.

server:
  interface: 127.0.0.1
  port: 5335
  access-control: 127.0.0.0/8 allow
  access-control: 0.0.0.0/0 refuse
  access-control: ::0/0 refuse

# Validate the complete installed configuration:
unbound-checkconf

Officiel dokumentation: Konfigurationsreference for Unbound

Kør en accepttjekliste fra to netværk

Forespørg først backend lokalt, derefter den normale klientsti. Kontrollér almindelige A/AAAA-poster, et bevidst ikke-eksisterende navn og DNSSEC-validering ved hjælp af et dokumenteret testdomæne. Gentag fra en maskine uden for det tilladte subnet: den må ikke modtage rekursion. Gennemgå, om en browser bruger sin egen krypterede resolver og omgår den konfigurerede enheds-DNS. Hold en midlertidig uafhængig resolver tilgængelig under ændringen, så en DNS-fejl ikke fjerner din administrationsrute.

• Lokal diagnostik: dig @127.0.0.1 -p 5335 example.org A
• Undersøg både UDP- og TCP-tilgængelighed samt IPv6-lyttere.
• Bekræft filtreringsundtagelser, og registrér kun de diagnostikdata, der faktisk er nødvendige.

Diagnostiser timeouts, loops og valideringsfejl

En frontend-timeout med en fungerende lokal backend peger på frontend-adressen, firewallen eller videresendelsesmålet. Gentagne selvinitierede forespørgsler tyder på en løkke. Udbredte DNSSEC-fejl kan skyldes forkert systemtid eller vedligeholdelse af trust-anchors; ret årsagen i stedet for at lade valideringen være deaktiveret. Hvis kun store svar fejler, undersøg TCP-fallback og netværksstien. Hold forespørgselslogning midlertidig, og test en genstart og gendannelse af konfigurationen, før du gør resolveren til en afhængighed for alle enheder.