Um resolver para os seus dispositivos, não um amplificador aberto.

Escolha a função

Um resolvedor recursivo como o Unbound e uma interface de filtragem como o AdGuard Home resolvem problemas relacionados, mas distintos. Decida se o serviço faz a recursão por si próprio ou encaminha para um upstream e compreenda que parte passa então a ver as consultas.

Mantenha tudo privado

Um resolver público sem restrições pode ser abusado para ataques de reflexão. Vincule-o a uma rede privada ou permita apenas fontes autorizadas, incluindo IPv6. Se utilizar DNS encriptado, autentique ou restrinja o acesso de forma adequada em vez de assumir que HTTPS o torna privado.

Defina uma política de registo

As consultas DNS podem revelar atividade sensível de navegação e de aplicações. Desative a retenção desnecessária, proteja os registos que mantém e explique o âmbito aos utilizadores. O transporte encriptado protege um caminho; não impede que o próprio resolver veja as consultas.

Teste mais de um nome

Verifique o comportamento do DNSSEC onde estiver habilitado, os resultados de IPv4 e IPv6, as exceções de filtragem e a recuperação quando um upstream falhar. Mantenha uma forma segura de corrigir o acesso sem depender exclusivamente do resolvedor que você está reparando.

Comprove que estranhos não conseguem consultá-la

Vincule o resolvedor à interface pretendida, defina os intervalos de clientes permitidos e restrinja o firewall. Valide a configuração antes de reiniciar. Consulte-o a partir de um cliente autorizado e depois repita de fora da rede confiável: essa solicitação deve ser recusada ou expirar. Verifique IPv6 separadamente. Um resolvedor que aceita consultas arbitrárias da internet pode se tornar uma fonte de abuso.

• Execute o validador de configuração antes de aplicar alterações
• Teste um cliente permitido e um cliente negado
• Mantenha diagnósticos detalhados de consultas temporários

unbound-checkconf

Documentação oficial: Configuração de controle de acesso sem restrições

Mantenha as alegações de DNS encriptado precisas

DNS-sobre-HTTPS ou DNS-sobre-TLS criptografa um caminho de transporte específico. O resolvedor ainda recebe a consulta, e um resolvedor de encaminhamento pode passá-la a outro operador. Revise a escolha do upstream e a retenção. Se você expõe um endpoint de resolvedor criptografado, torne sua política de acesso tão deliberada quanto a porta DNS comum.

Escolha a cadeia de resolução antes de abrir uma porta

Um design privado útil é um cliente VPN a consultar o AdGuard Home, com o AdGuard a encaminhar para o Unbound em loopback. O Unbound realiza então a recursão; o AdGuard acrescenta filtragem e uma interface de gestão. Em alternativa, use apenas o Unbound para uma stack mais pequena. Dê a cada listener um endereço/porta distintos e desenhe a direção do encaminhamento: enviar o Unbound de volta para o AdGuard cria um ciclo. Decida que clientes privados podem usar o serviço antes de publicar o que quer que seja.

• Mantenha as portas TCP e UDP 53 de entrada públicas fechadas, a menos que exista uma política específica de clientes autorizados.
• Dê à interface de filtragem e ao listener DNS regras de acesso separadas.
• Verifique a propriedade da porta antes da instalação; um resolvedor de sistema existente pode já estar a ocupar o endereço pretendido.

Documentação oficial: Configuração do AdGuard Home

Um ponto de partida Unbound em loopback

Num sistema com o Unbound já instalado, o fragmento seguinte ilustra um backend acessível apenas no host. Integre-o com a configuração da distribuição em vez de substituir as definições do pacote ou a gestão de trust-anchors. A porta alta permite que outro frontend DNS use a porta 53. Valide o ficheiro efetivo completo e, em seguida, recarregue através do gestor de serviços instalado. Um cliente remoto precisa de um túnel ou frontend controlado separadamente; este fragmento não cria intencionalmente nenhum resolver público.

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ção oficial: Referência de configuração do Unbound

Execute uma lista de verificação de aceitação a partir de duas redes

Consulte primeiro o backend localmente e depois o caminho normal do cliente. Verifique registos A/AAAA comuns, um nome deliberadamente inexistente e a validação DNSSEC através de um domínio de teste documentado. Repita a partir de uma máquina fora da sub-rede permitida: não deve receber recursão. Avalie se um navegador utiliza o seu próprio resolvedor encriptado e contorna o DNS configurado no dispositivo. Mantenha um resolvedor independente temporário disponível durante a alteração para que um erro de DNS não elimine a sua rota de administração.

• Diagnóstico local: dig @127.0.0.1 -p 5335 example.org A
• Inspecione a acessibilidade tanto por UDP quanto por TCP, além dos listeners IPv6.
• Confirme as exceções de filtragem e registe apenas os diagnósticos realmente necessários.

Diagnosticar tempos limite, ciclos e falhas de validação

Um timeout no frontend com um backend local funcional sugere o endereço do frontend, a firewall ou o destino de encaminhamento. Consultas repetidas auto-dirigidas sugerem um loop. Falhas generalizadas de DNSSEC podem envolver hora do sistema incorreta ou manutenção de trust-anchor; corrija a causa em vez de deixar a validação desativada. Se apenas respostas grandes falharem, investigue o fallback TCP e o caminho de rede. Mantenha o registo de consultas temporário e teste um reinício e a restauração da configuração antes de tornar o resolver uma dependência para todos os dispositivos.