Quem opera 1.1.1.1? Verificar um endereço DNS antes de confiar nele

Colou 1.1.1.1 no campo DNS da VPN, a página carregou e o tutorial já parece confirmado. Essa observação é mais estreita do que parece: a aplicação comportou-se de forma diferente, e a alteração ainda não diz nada sobre quem respondeu à consulta nem por que a configuração anterior falhou. Um tutorial copiado costuma chamar «o DNS da VPN» a um endereço público conhecido, o que é uma afirmação sobre propriedade e não sobre alcance. Verificar o que o endereço representa leva cinco minutos e evita uma alteração permanente feita pelo motivo errado.

Uma configuração que funciona não é uma identidade

O endereço num campo de configuração é um extremo, e um extremo tem um operador. São dois factos separados, e o segundo é o que as pessoas saltam. Para o par que mais se copia, a resposta é pública: a Cloudflare publica 1.1.1.1 e 1.0.0.1 como os endereços do seu resolvedor e lista-os na sua referência oficial de endereços. É por isso que o nome do operador fica ao lado do endereço e não num tutorial separado.

Introduzir esse par com um túnel ativo não torna a empresa da VPN o seu operador nem torna o tráfego anónimo. A consulta sai da sua máquina para uma empresa que publica o intervalo de endereços, e essa empresa pode ser respeitável e ainda assim não ser a parte que o tutorial sugeria. O rótulo nas instruções e o operador na realidade são afirmações diferentes. Nenhuma das duas diz quem gere o caminho de rede pelo meio.

Use a referência publicada do próprio resolvedor para confirmar um par de endereços ou um extremo cifrado. Uma recomendação de outro fornecedor pode ser legítima, e «recomendado por», «alcançado através de» e «operado por» continuam a descrever três relações diferentes.

Compare as três coisas de que um registo precisa

Um registo pronto para revisão separa três perguntas: quem deve receber a consulta, se a troca é simples ou cifrada e que caminho a deve transportar. O nome de um fornecedor não pode preencher a segunda nem a terceira, e um rótulo de país não pode preencher nenhuma delas. Anote as três entradas antes da alteração e compare-as depois. Essas entradas não são intercambiáveis, e tratá-las como uma só é como uma suposição se torna documentação.

É a comparação que transforma uma configuração que funciona numa decisão documentada. Sem ela, a pessoa seguinte herda um endereço sem qualquer razão anexada. Leia primeiro a terceira coluna da tabela abaixo, porque é aí que a maioria das explicações seguras realmente para.

A tabela é deliberadamente curta. O ponto é que cada entrada responde a uma pergunta diferente e que nenhum campo isolado preenche as três.

Um reencaminhador local esconde a origem real

Um dispositivo configurado para usar o seu router como DNS está a apontar para um reencaminhador. Esse endereço identifica o próximo destinatário da consulta, não o resolvedor que acaba por responder. Um resolvedor stub local acrescenta o mesmo passo extra, e é fácil confundi-lo com a coisa real porque aparece em todas as saídas de estado.

O stub reencaminha para origens que a mesma saída também lista, normalmente mais abaixo. Leia toda a cadeia antes de concluir algo sobre o operador, porque a primeira linha não é toda a resposta. Caso contrário, está a chamar à receção a empresa.

resolvectl status | grep -A4 'Current DNS Server'
dig +short CH TXT whoami.cloudflare @1.1.1.1
dig example.com | grep -E '^;; SERVER'

O segundo comando usa o nome de eco de um resolvedor, quando o operador publica um, para relatar o endereço de origem que vê. O terceiro nomeia o servidor que respondeu, que muitas vezes não é o endereço que configurou. Compare as três saídas antes de anotar um operador.

O DNS cifrado muda o que é visível, não quem o vê

DNS over HTTPS e DNS over TLS protegem a troca entre cliente e resolvedor. O resolvedor continua a ler cada nome que lhe é pedido, porque responder é o trabalho. O que muda é quem pode observar a troca: a rede local vê uma ligação a um único extremo em vez de um fluxo de consultas em texto simples.

O que não muda é a relação de confiança, que continua a apontar para a organização que opera esse extremo. Um navegador com a sua própria configuração de DNS seguro pode contornar por completo o resolvedor do sistema operativo. Trate-os como duas configurações que podem discordar, e não como uma configuração aplicada duas vezes.

Os nomes privados precisam novamente da sua própria decisão. Um túnel de trabalho pode encaminhar domínios selecionados para resolvedores da organização, e substituí-lo por um serviço público pode quebrar pesquisas internas ou revelar nomes internos à parte errada. Verifique a política de domínios antes de substituir as configurações de todo um adaptador.

Mantenha a observação estreita

Quando comparar, preserve a configuração antiga e altere uma configuração de cada vez. Registe a aplicação, a operação, a política do resolvedor e se os nomes públicos e os privados permitidos ainda resolvem após uma reconexão. Uma comparação com duas alterações não prova nenhuma delas. Escreva o resultado onde a próxima pessoa o encontre, ao lado da própria configuração.

resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.com

Se a aplicação começar a funcionar, mantenha a afirmação tão pequena quanto as provas permitirem. Essa alteração ajudou um teste, e não diz nada sobre se o resolvedor anterior agiu de má-fé, se o túnel estava partido ou se outro dispositivo precisa da mesma substituição. O resultado duradouro é uma configuração cujo operador e propósito consegue explicar.