Un resolver per i tuoi dispositivi, non un amplificatore aperto.

Scegli il ruolo

Un resolver ricorsivo come Unbound e un'interfaccia di filtraggio come AdGuard Home risolvono problemi correlati ma distinti. Decidi se il servizio esegue la ricorsione da solo o inoltra a un upstream e comprendi quale parte vede poi le query.

Mantienilo privato

Un resolver pubblico senza restrizioni può essere sfruttato per attacchi di reflection. Associa a una rete privata o consenti solo fonti autorizzate, incluso IPv6. Se usi DNS crittografato, autentica o limita in altro modo adeguatamente l'accesso invece di presumere che HTTPS lo renda privato.

Imposta una policy di logging

Le query DNS possono rivelare attività sensibili di navigazione e applicative. Disabilita la conservazione non necessaria, proteggi i registri che mantieni e spiega l'ambito agli utenti. Il trasporto cifrato protegge un percorso; non impedisce al resolver stesso di vedere le query.

Verifica più di un nome

Verifica il comportamento di DNSSEC ove abilitato, i risultati di IPv4 e IPv6, le eccezioni di filtraggio e il ripristino quando un upstream fallisce. Mantieni un modo sicuro per correggere l'accesso senza dipendere esclusivamente dal resolver che stai riparando.

Dimostra che estranei non possono interrogarla

Associa il resolver all'interfaccia prevista, definisci gli intervalli di client consentiti e limita il firewall. Convalida la configurazione prima di riavviare. Interrogalo da un client autorizzato, poi ripeti dall'esterno della rete attendibile: quella richiesta dovrebbe essere rifiutata o andare in timeout. Verifica separatamente IPv6. Un resolver che accetta query arbitrarie da internet può diventare una fonte di abusi.

• Esegui il validatore di configurazione prima di applicare le modifiche
• Prova un client consentito e un client negato
• Mantieni temporanee le diagnostiche dettagliate delle query

unbound-checkconf

Documentazione ufficiale: Configurazione del controllo degli accessi non vincolata

Mantieni precise le dichiarazioni DNS crittografate

DNS-su-HTTPS o DNS-su-TLS cifra un determinato percorso di trasporto. Il resolver riceve comunque la query, e un resolver di inoltro può passarla a un altro operatore. Esamina la scelta upstream e la conservazione. Se esponi un endpoint resolver cifrato, rendi la sua politica di accesso deliberata quanto la normale porta DNS.

Scegli la catena di resolver prima di aprire una porta

Un progetto privato utile prevede un client VPN che interroga AdGuard Home, con AdGuard che inoltra a Unbound su loopback. Unbound esegue quindi la ricorsione; AdGuard aggiunge il filtraggio e un'interfaccia di gestione. In alternativa usa solo Unbound per uno stack più ridotto. Assegna a ogni listener un indirizzo/porta distinto e traccia la direzione dell'inoltro: rimandare Unbound ad AdGuard crea un loop. Decidi quali client privati possono usare il servizio prima di pubblicare qualsiasi cosa.

• Mantieni chiusi i protocolli TCP e UDP in ingresso pubblici 53 a meno che non esista una specifica policy per client autorizzati.
• Assegna all'interfaccia di filtraggio e al listener DNS regole di accesso separate.
• Verifica la proprietà della porta prima dell'installazione; un resolver di sistema esistente potrebbe già occupare l'indirizzo previsto.

Documentazione ufficiale: Configurazione di AdGuard Home

Un punto di partenza per Unbound su loopback

Su un sistema con Unbound già installato, il seguente frammento illustra un backend raggiungibile solo sull'host. Integralo con la configurazione della distribuzione invece di sovrascrivere le impostazioni del pacchetto o la gestione dei trust anchor. La porta alta consente a un altro frontend DNS di usare la porta 53. Convalida il file effettivo completo, poi ricarica tramite il service manager installato. Un client remoto necessita di un tunnel o di un frontend controllato separatamente; questo frammento non crea intenzionalmente alcun resolver pubblico.

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

Documentazione ufficiale: Riferimento di configurazione di Unbound

Esegui una checklist di accettazione da due reti

Interroga prima il backend localmente, poi il normale percorso client. Verifica i record A/AAAA ordinari, un nome volutamente inesistente e la validazione DNSSEC usando un dominio di test documentato. Ripeti da una macchina esterna alla subnet consentita: non deve ricevere ricorsione. Controlla se un browser usa il proprio resolver cifrato e aggira il DNS del dispositivo configurato. Mantieni un resolver indipendente temporaneo disponibile durante la modifica, così un errore DNS non rimuova la tua via di amministrazione.

• Diagnostica locale: dig @127.0.0.1 -p 5335 example.org A
• Ispeziona la raggiungibilità sia UDP che TCP, oltre ai listener IPv6.
• Conferma le eccezioni di filtraggio e registra solo la diagnostica effettivamente necessaria.

Diagnostica timeout, loop ed errori di validazione

Un timeout del frontend con un backend locale funzionante suggerisce l'indirizzo del frontend, il firewall o la destinazione dell'inoltro. Query ripetute auto-dirette suggeriscono un loop. Errori DNSSEC diffusi possono coinvolgere un orario di sistema errato o la manutenzione dei trust anchor; correggi la causa invece di lasciare la validazione disabilitata. Se falliscono solo le risposte di grandi dimensioni, indaga il fallback TCP e il percorso di rete. Mantieni temporaneamente la registrazione delle query e prova un riavvio e un ripristino della configurazione prima di rendere il resolver una dipendenza per ogni dispositivo.