Um resolvedor DNS local com cache usando Unbound: access-control, encaminhamento e validação DNSSEC

Objetivo

Executar o Unbound como resolvedor DNS com cache e validação para um segmento de rede: definir quem pode consultá-lo, se ele faz a recursão por conta própria ou encaminha as consultas a um resolvedor upstream, e confirmar que a validação DNSSEC está ativa.

Pré-requisitos

Unbound instalado; um segmento de rede cujos hosts apontarão para este resolvedor; acesso de saída à internet (para recursão) ou a um resolvedor upstream (para encaminhamento).

Passos

1. Na cláusula server: do unbound.conf, adicione uma linha interface: com o endereço da LAN (por padrão, o Unbound escuta apenas em localhost). Depois restrinja quem pode fazer consultas com linhas access-control:, uma por bloco de rede, cada uma com uma ação. O bloco de rede é informado como um endereço IP4 ou IP6 com um tamanho anexado, para indicar um bloco de rede sem classes. Por padrão, só o localhost é permitido e todo o resto é recusado. refuse responde REFUSED; deny descarta a consulta em silêncio. Não configure uma permissão geral (allow) em uma interface exposta à internet, pois isso transforma o resolvedor em um resolvedor recursivo aberto, que pode ser usado em ataques de amplificação de DNS.
2. Decida entre recursão e encaminhamento. Sem uma cláusula forward-zone:, o Unbound resolve as consultas por conta própria, percorrendo a hierarquia DNS a partir da raiz. Se você adicionar uma forward-zone: com name: "." e um ou mais destinos forward-addr:, as consultas passam a ser enviadas a um resolvedor recursivo upstream: essa lista de servidores de nomes é usada para encaminhar as consultas, e o Unbound continua validando o DNSSEC das respostas, desde que o upstream devolva os registros DNSSEC.
3. Mantenha a validação DNSSEC configurada: defina auto-trust-anchor-file: com um caminho em que o usuário unbound possa gravar (os pacotes do Debian e do RHEL já definem um, criado por unbound-anchor). O arquivo contém uma âncora de confiança para a zona, acompanhada por sondagens RFC 5011 executadas várias vezes por mês; por isso, o resolvedor precisa ficar online com frequência suficiente para atualizá-la.
4. Antes de recarregar, valide a sintaxe: unbound-checkconf verifica o arquivo de configuração do resolvedor DNS Unbound em busca de erros de sintaxe e de outros tipos, sem iniciar o daemon.
5. Recarregue o resolvedor em execução como root (unbound-control reload, que também limpa o cache, ou reiniciando o serviço). O unbound-control exige control-enable: yes em uma cláusula remote-control:, além de chaves TLS criadas uma única vez com unbound-control-setup ou de um control-interface em socket Unix local.
6. Para eliminar uma entrada obsoleta ou envenenada do cache sem reiniciar: unbound-control flush <name> remove o nome do cache, abrangendo os tipos de registro mais comuns em uma só chamada.

Resultado esperado

As consultas vindas da rede configurada são resolvidas e ficam em cache; as consultas de fora recebem REFUSED (ou nenhuma resposta, com deny). O dig +dnssec contra uma zona validada mostra a flag AD, e um domínio de teste com DNSSEC propositalmente quebrado falha ao resolver, em vez de devolver uma resposta que poderia ser falsificada.

Limites e base de verificação

O unbound-checkconf detecta erros de sintaxe, não erros operacionais, como um destino de encaminhamento inacessível; por isso, teste a resolução após o reload, e não apenas a verificação da configuração. Uma regra access-control ampla demais é uma fonte comum de abuso de resolvedores; revise-a sempre que o resolvedor mudar para uma nova rede. O auto-trust-anchor-file exige que o resolvedor fique em execução de forma contínua o bastante para concluir as sondagens de atualização do RFC 5011; um resolvedor que fique offline por muito tempo pode precisar de uma nova carga da âncora de confiança.