DNS sobre TLS mais uma VPN: que parte fica protegida

DNS sobre TLS cifra a troca entre um cliente e o resolvedor que ele escolheu, e o resolvedor continua a ler o nome. Essa frase resolve a maior parte da confusão em torno do DoT mais uma VPN. O túnel decide que caminho a consulta cifrada segue, enquanto o resolvedor continua a saber o que foi perguntado. Nenhum dos mecanismos substitui o outro, e nenhum torna o outro redundante.

Quatro verificações decidem se a disposição que tem é a que pensa ter.

Verificação 1: o que a cifra cobre

O DoT embrulha a troca DNS em TLS, por isso um observador no caminho vê uma ligação a um endereço e uma porta em vez de um nome numa consulta. O próprio resolvedor decifra e responde. Compare com DNS sobre HTTPS: ambos cifram e usam transportes diferentes, por isso uma rede que permite tráfego web não permite automaticamente uma ligação DoT.

Essa distinção importa quando um portal cativo ou um intermediário de filtragem permite a 443 e bloqueia a 853. A ferramenta que funcionou ali não é prova de que a outra funcionará.

Verificação 2: que rota a consulta toma

A rota é uma questão de política do cliente. Um resolvedor DoT pode ser alcançado pelo túnel, fora dele, ou por um caminho que muda com a rede. Qual acontece depende das rotas e de o cliente proteger o seu próprio socket DNS. Um túnel que captura todo o tráfego costuma levar a consulta consigo, diga o que disser o endereço do resolvedor.

Ver um endereço de resolvedor de terceiros num teste não prova um desvio, e ver cifra não prova o destinatário pretendido. Leia o resolvedor e o caminho em separado, e depois decida se o par é o que desenhou.

Verificação 3: nomes internos

Uma organização que publica nomes internos precisa de um resolvedor que guarde esses registos. Um serviço DoT público não conhece o seu espaço de nomes privado, e apontar o cliente para um garante que esses nomes falham. Esta é a regressão prática mais comum quando alguém ativa DNS cifrado num dispositivo gerido.

Mantenha o resolvedor interno para os sufixos internos e cifre esse salto se a política o exigir, em vez de o substituir por um fornecedor público.

Verificação 4: comportamento em caso de falha

Uma configuração rigorosa de resolvedor sem resolvedor acessível produz uma falha de resolução de nomes enquanto o túnel continua de pé. Olhe para o modo da plataforma e para o recurso documentado dela em vez de mexer em chaves ou certificados.

Um recurso que usa silenciosamente DNS em claro é uma decisão de política, não uma comodidade. Decida se a falha deve ser visível ou deve degradar-se para algo mais fraco, e escreva a resposta.

Confie no certificado, não na resposta

Use o nome de anfitrião do fornecedor e a configuração de verificação documentados para o serviço. Desativar as verificações TLS para que um resolvedor desconhecido responda dá-lhe um canal cifrado até um ponto final não verificado, o que é pior do que a consulta em claro que substituiu num aspeto concreto: parece seguro. A especificação de DNS sobre TLS expõe a expectativa de autenticação por trás dessa verificação.

Uma resposta de um resolvedor que não consegue autenticar é uma afirmação, não um resultado.

O que isto deixa por explicar

O DoT não esconde o nome ao resolvedor, não esconde o endereço de destino da ligação à rede e não decide se a consulta passou pelo túnel. São três perguntas separadas com três respostas separadas.

Escreva a identidade do resolvedor, o caminho de trânsito e a política de nomes internos em três linhas. A próxima pergunta sobre DNS que receber será uma delas.