dnsmasq descarta uma resposta DNS privada: é a proteção contra rebinding?

O servidor DNS da empresa devolve o endereço privado esperado e, ainda assim, uma consulta pelo resolvedor de encaminhamento local falha. A resposta existe, o que descarta a zona upstream e o próprio registro. Resta a etapa em que o resolvedor decide se devolve essa resposta ao cliente. Se esse resolvedor for o dnsmasq, a rejeição provavelmente já está no log.

Receber uma resposta e escolher devolvê-la são duas etapas diferentes.

Compare o mesmo nome nos dois resolvedores

Anote qual resolvedor a aplicação realmente usa e o nome de host exato que ela consulta. Depois compare o resultado upstream com o evento do resolvedor de encaminhamento para o mesmo nome. Uma resposta upstream ausente, uma resposta negativa em cache e uma rejeição registrada exigem três correções diferentes.

Um endereço visível numa consulta de diagnóstico direta não prova que a aplicação o recebeu pelo caminho habitual. As duas consultas podem sair de resolvedores diferentes, ou do mesmo resolvedor com políticas diferentes. Anote os dois resultados antes de teorizar, porque é nesta etapa que as pessoas trocam um pelo outro. A comparação é todo o diagnóstico.

Leia a rejeição em vez do sintoma

A opção stop-dns-rebind do dnsmasq rejeita respostas de endereço privado qualificadas vindas do upstream e as registra quando o faz. Essa proteção existe por um bom motivo: um nome público que de repente resolve para um endereço privado é o clássico ataque de rebinding. Ela também cruza com um serviço intencionalmente privado, que é o seu caso.

Procure a rejeição no log antes de mudar qualquer coisa, porque a mensagem nomeia o mecanismo.

Se não houver rejeição nem resposta upstream, a proteção contra rebinding não é o seu problema, e desativá-la seria uma mudança que não corrige nada e amplia a exposição. É pior do que a falha original, porque remove um controle e deixa o defeito. Confirme primeiro a linha de log específica. Depois decida.

Limite a exceção a um único domínio

Para um domínio verificado, o manual do dnsmasq oferece uma exceção limitada ao domínio em vez de um interruptor global.

rebind-domain-ok=corp.example

O domínio acima é apenas ilustrativo. Use o domínio administrativo que você realmente opera e entenda o escopo de correspondência da opção antes de aplicá-la, porque uma regra de sufixo cobre mais do que o único host testado. O gerador de configuração de um roteador pode expor o mesmo ajuste por meio do próprio controle em vez de uma diretiva bruta. Qualquer caminho serve, desde que o escopo resultante seja o pretendido.

Uma exceção à detecção de rebinding faz exatamente uma coisa: deixa passar as respostas desse domínio.

Ela não configura um encaminhador de split-DNS, não torna alcançável um upstream inalcançável nem cria uma rota para o endereço devolvido. Cada um desses itens é um requisito separado, com sua própria assinatura de falha, e cada um falha de forma diferente no cliente.

Verifique sem remover a fronteira

Consulte o nome de host novamente pelo caminho de encaminhamento e depois conecte-se ao serviço com suas verificações de identidade habituais. Uma exceção de DNS não é motivo para aceitar um certificado inesperado, e as duas falhas são fáceis de confundir quando ambas aparecem como erro do navegador. Teste o nome e o serviço separadamente. Apenas um dos dois foi alguma vez um problema de DNS.

Guarde o motivo da exceção junto à configuração, com data e responsável.

Reveja-o quando o serviço privado mudar de lugar ou o domínio mudar. Desativar a proteção globalmente mudaria o tratamento de respostas não relacionadas e ainda deixaria a falha de rota ou de serviço no lugar se o rebinding nunca foi a causa.