Un resolver pentru dispozitivele tale, nu un amplificator deschis.

Alege rolul

Un resolver recursiv precum Unbound și o interfață de filtrare precum AdGuard Home rezolvă probleme înrudite, dar distincte. Decideți dacă serviciul recurge singur sau redirecționează către un upstream și înțelegeți care parte vede apoi interogările.

Păstrează confidențialitatea

Un resolver public nerestricționat poate fi abuzat pentru atacuri de reflexie. Legați-l la o rețea privată sau permiteți doar surse autorizate, inclusiv IPv6. Dacă folosiți DNS criptat, autentificați sau restricționați în alt mod accesul în mod corespunzător, în loc să presupuneți că HTTPS îl face privat.

Stabilește o politică de jurnalizare

Interogările DNS pot dezvălui activitate sensibilă de navigare și de aplicație. Dezactivați păstrarea inutilă, protejați înregistrările pe care le păstrați și explicați domeniul de aplicare utilizatorilor. Transportul criptat protejează o cale; nu împiedică resolverul însuși să vadă interogările.

Testează mai mult de un nume

Verifică comportamentul DNSSEC acolo unde este activat, rezultatele IPv4 și IPv6, excepțiile de filtrare și recuperarea când un server upstream eșuează. Păstrează o modalitate sigură de a corecta accesul fără a depinde exclusiv de resolverul pe care îl repari.

Dovediți că persoanele străine nu o pot interoga

Leagă resolverul de interfața dorită, definește intervalele de clienți permise și restricționează firewall-ul. Validează configurația înainte de repornire. Interoghează-l dintr-un client autorizat, apoi repetă din afara rețelei de încredere: acea cerere ar trebui refuzată sau ar trebui să expire. Verifică separat IPv6. Un resolver care acceptă interogări arbitrare de pe internet poate deveni o sursă de abuz.

• Rulează validatorul de configurare înainte de a aplica modificările
• Testați un client permis și un client respins
• Păstrați temporar diagnosticele detaliate ale interogărilor

unbound-checkconf

Documentație oficială: Configurare neconstrânsă a controlului accesului

Păstrează precise afirmațiile despre DNS criptat

DNS-peste-HTTPS sau DNS-peste-TLS criptează o anumită cale de transport. Resolverul primește totuși interogarea, iar un resolver de redirecționare o poate transmite altui operator. Examinați alegerea upstream și păstrarea. Dacă expuneți un endpoint de resolver criptat, faceți politica sa de acces la fel de deliberată ca portul obișnuit DNS.

Alegeți lanțul de resolver înainte de a deschide un port

Un design privat util este un client VPN care interoghează AdGuard Home, cu AdGuard redirecționând către Unbound pe loopback. Unbound efectuează apoi recursiunea; AdGuard adaugă filtrare și o interfață de administrare. Alternativ, folosiți doar Unbound pentru un stack mai mic. Acordați fiecărui listener o adresă/port distinct și trasați direcția de redirecționare: trimiterea Unbound înapoi la AdGuard creează o buclă. Decideți ce clienți privați pot folosi serviciul înainte de a publica ceva.

• Menține închise porturile publice de intrare TCP și UDP 53 dacă nu există o politică specifică pentru clienți autorizați.
• Acordați interfeței de filtrare și listener-ului DNS reguli de acces separate.
• Verificați proprietarul portului înainte de instalare; un resolver de sistem existent poate ocupa deja adresa dorită.

Documentație oficială: Configurarea AdGuard Home

Un punct de plecare Unbound pe loopback

Pe un sistem cu Unbound deja instalat, fragmentul următor ilustrează un backend accesibil doar pe gazdă. Integrați-l cu configurația distribuției în loc să suprascrieți setările pachetului sau gestionarea trust-anchor. Portul înalt permite unui alt frontend DNS să utilizeze portul 53. Validați fișierul efectiv complet, apoi reîncărcați prin managerul de servicii instalat. Un client la distanță are nevoie de un tunel sau un frontend controlat separat; acest fragment nu creează intenționat niciun resolver public.

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

Documentație oficială: Referință de configurare Unbound

Rulați o listă de verificare de acceptare din două rețele

Interogați mai întâi backendul local, apoi calea normală a clientului. Verificați înregistrările obișnuite A/AAAA, un nume inexistent în mod deliberat și validarea DNSSEC folosind un domeniu de test documentat. Repetați de pe o mașină din afara subrețelei permise: nu trebuie să primească recursiune. Verificați dacă un browser folosește propriul resolver criptat și ocolește DNS configurat al dispozitivului. Păstrați un resolver independent temporar disponibil în timpul modificării, astfel încât o eroare DNS să nu vă elimine ruta de administrare.

• Diagnostic local: dig @127.0.0.1 -p 5335 example.org A
• Inspectează accesibilitatea atât prin UDP, cât și prin TCP, plus ascultătorii IPv6.
• Confirmă excepțiile de filtrare și înregistrează doar diagnosticele efectiv necesare.

Diagnosticați expirările de timp, buclele și eșecurile de validare

Un timeout al frontend-ului cu un backend local funcțional sugerează adresa frontend-ului, firewall-ul sau ținta de redirecționare. Interogările repetate auto-dirijate sugerează o buclă. Eșecurile DNSSEC răspândite pot implica ora de sistem incorectă sau întreținerea trust-anchor; remediați cauza în loc să lăsați validarea dezactivată. Dacă doar răspunsurile mari eșuează, investigați fallback-ul TCP și calea de rețea. Păstrați jurnalizarea interogărilor temporară și testați o repornire și o restaurare a configurației înainte de a face resolver-ul o dependență pentru fiecare dispozitiv.