Een resolver voor jouw apparaten, geen open amplifier.

Kies de rol

Een recursieve resolver zoals Unbound en een filterinterface zoals AdGuard Home lossen verwante maar verschillende problemen op. Bepaal of de dienst zelf recursie uitvoert of doorstuurt naar een upstream en begrijp welke partij dan de queries ziet.

Houd het privé

Een onbeperkte openbare resolver kan worden misbruikt voor reflectieaanvallen. Bind aan een privénetwerk of sta alleen geautoriseerde bronnen toe, waaronder IPv6. Als u versleutelde DNS gebruikt, authenticeer of beperk de toegang dan op passende wijze in plaats van aan te nemen dat HTTPS het privé maakt.

Stel een loggingbeleid in

DNS-query's kunnen gevoelige browse- en applicatieactiviteit onthullen. Schakel onnodige retentie uit, bescherm de records die u bewaart en leg de reikwijdte uit aan gebruikers. Versleuteld transport beschermt een pad; het verhindert niet dat de resolver zelf query's ziet.

Test meer dan één naam

Verifieer DNSSEC-gedrag waar ingeschakeld, IPv4 en IPv6-resultaten, filteringuitzonderingen en herstel wanneer een upstream faalt. Houd een veilige manier om toegang te herstellen zonder uitsluitend afhankelijk te zijn van de resolver die u repareert.

Bewijs dat onbekenden er geen query op kunnen uitvoeren

Bind de resolver aan de beoogde interface, definieer de toegestane clientbereiken en beperk de firewall. Valideer de configuratie voordat u herstart. Bevraag deze vanaf een geautoriseerde client en herhaal dit vervolgens van buiten het vertrouwde netwerk: dat verzoek moet worden geweigerd of time-out geven. Controleer IPv6 afzonderlijk. Een resolver die willekeurige internetquery's accepteert, kan een bron van misbruik worden.

• Voer de configuratievalidator uit voordat je wijzigingen toepast
• Test een toegestane client en een geweigerde client
• Houd uitgebreide querydiagnostiek tijdelijk

unbound-checkconf

Officiële documentatie: Onbeperkte toegangscontroleconfiguratie

Houd versleutelde DNS-claims precies

DNS-over-HTTPS of DNS-over-TLS versleutelt een bepaald transportpad. De resolver ontvangt de query nog steeds, en een doorsturende resolver kan deze aan een andere operator geven. Beoordeel de keuze van de upstream en de bewaring. Als je een versleuteld resolver-eindpunt aanbiedt, maak het toegangsbeleid dan even bewust als de gewone DNS-poort.

Kies de resolver-keten voordat u een poort opent

Een bruikbaar privéontwerp is een VPN-client die AdGuard Home bevraagt, waarbij AdGuard doorstuurt naar Unbound op loopback. Unbound voert vervolgens recursie uit; AdGuard voegt filtering en een beheerinterface toe. Gebruik alternatief alleen Unbound voor een kleinere stack. Geef elke listener een afzonderlijk adres/poort en teken de doorstuurrichting: Unbound terugsturen naar AdGuard creëert een lus. Bepaal welke privéclients de dienst mogen gebruiken voordat je iets publiceert.

• Houd openbare inkomende TCP en UDP 53 gesloten, tenzij er een specifiek beleid voor geautoriseerde clients is.
• Geef de filterinterface en de DNS-listener afzonderlijke toegangsregels.
• Controleer poorteigendom vóór installatie; een bestaande systeemresolver kan het beoogde adres al binden.

Officiële documentatie: AdGuard Home instellen

Een loopback-Unbound-startpunt

Op een systeem waarop Unbound al is geïnstalleerd, illustreert het volgende fragment een backend die alleen op de host bereikbaar is. Integreer het met de distributieconfiguratie in plaats van pakketinstellingen of trust-anchor-beheer te overschrijven. De hoge poort laat een andere DNS-frontend poort 53 gebruiken. Valideer het volledige effectieve bestand en herlaad vervolgens via de geïnstalleerde servicemanager. Een externe client heeft een afzonderlijk beheerde tunnel of frontend nodig; dit fragment maakt bewust geen openbare 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

Officiële documentatie: Unbound-configuratiereferentie

Voer een acceptatiechecklist uit vanaf twee netwerken

Query eerst de backend lokaal en daarna het normale clientpad. Controleer gewone A/AAAA-records, een bewust niet-bestaande naam en DNSSEC-validatie met een gedocumenteerd testdomein. Herhaal dit vanaf een machine buiten het toegestane subnet: die mag geen recursie ontvangen. Controleer of een browser zijn eigen versleutelde resolver gebruikt en het geconfigureerde apparaat DNS omzeilt. Houd tijdens de wijziging een tijdelijke onafhankelijke resolver beschikbaar, zodat een DNS fout je beheerroute niet wegneemt.

• Lokale diagnose: dig @127.0.0.1 -p 5335 example.org A
• Inspecteer zowel UDP- als TCP-bereikbaarheid, plus IPv6-listeners.
• Bevestig filteruitzonderingen en registreer alleen de daadwerkelijk benodigde diagnostiek.

Diagnose time-outs, loops en validatiefouten

Een frontend-time-out met een werkende lokale backend wijst op het frontendadres, de firewall of het doorstuurdoel. Herhaalde zelfgestuurde query's wijzen op een lus. Wijdverspreide DNSSEC-fouten kunnen te maken hebben met een onjuiste systeemtijd of onderhoud van trust anchors; verhelp de oorzaak in plaats van validatie uitgeschakeld te laten. Als alleen grote antwoorden mislukken, onderzoek dan TCP-fallback en het netwerkpad. Houd querylogging tijdelijk en test een herstart en het herstellen van de configuratie voordat u de resolver een afhankelijkheid maakt voor elk apparaat.