Registros do resolvedor DNS versus registros de conexão VPN: o que cada um guarda

Um registro do resolvedor DNS e um registro de conexão VPN são ambos registros de rede, ambos úteis e não intercambiáveis. O resolvedor recebe os nomes que lhe pediram para responder. O ponto final da VPN trata das conexões de túnel e registra o que a sua implementação decidiu registrar sobre elas. Podem estar no mesmo edifício, ser operados pela mesma equipe e estar cobertos pelo mesmo aviso de privacidade, e ainda assim descrevem eventos diferentes com identificadores diferentes e retenção diferente. Ler um como se fosse o outro é como as investigações tomam o rumo errado.

Dois registros, dois eventos

Uma entrada do resolvedor responde a uma pergunta sobre nomenclatura: este cliente pediu este nome neste momento, e a resposta foi esta. Uma entrada da VPN responde a uma pergunta sobre conectividade: este par estabeleceu ou perdeu um túnel, recebeu este endereço e transferiu aproximadamente esta quantidade de dados antes de desaparecer. Nenhum dos dois é um registro do que o usuário fez dentro de uma sessão HTTPS, e nenhum substitui o outro.

A distinção tem uma consequência prática para as promessas. A afirmação de que um provedor de VPN não registra a atividade do túnel não diz nada sobre o resolvedor que ele distribui, e a política de retenção de um resolvedor não diz nada sobre quem se conectou ao túnel. Cada afirmação pertence ao seu próprio operador e ao seu próprio sistema.

Siga a consulta antes de ler qualquer um dos dois registros

Uma consulta só chega a um resolvedor se o caminho realmente lhe perguntar. Uma aplicação pode usar o resolvedor do sistema operacional, executar o seu próprio cliente DNS cifrado ou ler uma resposta em cache e nunca enviar nada. Assim, um registro do resolvedor que não mostra nada não é prova de que um nome nunca foi usado; é prova de que este resolvedor não foi consultado.

resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pager

Esse último comando lê o diário do próprio resolvedor local, o que não é o mesmo que o registro do servidor a montante. Se as suas consultas saírem por DNS over HTTPS para um provedor, o stub local pode não mostrar nada enquanto o provedor tem o registro completo, e o provedor é outro operador com outra política.

O que cada registro pode e não pode mostrar

Uni-los é o trabalho de verdade, e uni-los nem sempre é possível. Um resolvedor que registra endereços de clientes pode ser comparado a uma VPN que atribui endereços de um conjunto conhecido, e essa comparação produz um vínculo plausível entre um nome consultado e um túnel, que continua a ser um vínculo entre dois registros e não um registro de uma pessoa.

O DNS cifrado muda o transporte, não a visibilidade no ponto final. O resolvedor continua a receber a pergunta a que responde, como RFC 8484 deixa claro, e a retenção nesse resolvedor é uma decisão de política e não uma propriedade do protocolo.

Onde o DNS dividido e as caches confundem a história

Vários resolvedores são normais. Um desenho de DNS dividido envia os nomes internos para um servidor interno e todo o resto para um público, pelo que uma única investigação pode envolver dois registros que nunca foram pensados para ser combinados e dois ajustes de retenção que nunca foram pensados para ser comparados. Ver consultas nos dois é prova de que o desenho funciona, não prova de uma fuga.

As caches cortam na outra direção. Um nome popular pode ser respondido a partir da cache durante horas, pelo que o registro do resolvedor mostra a primeira consulta e depois nada, enquanto a aplicação do usuário continua a resolver o mesmo nome alegremente. A ausência de entradas depois de um certo momento não significa que ninguém usou o nome depois desse momento.

O tráfego de fundo é a terceira distorção. Um telefone que resolve um nome de telemetria ao arrancar, um navegador que resolve um domínio de sugestão de pesquisa e um atualizador que se liga a cada hora aparecem todos num registro do resolvedor ao lado do nome que realmente lhe importa. O volume nesse registro não é atenção, e contar consultas não é contar visitas. Um registro do resolvedor é um registo de perguntas, e as perguntas são baratas de gerar.

Faça as perguntas sobre retenção separadamente

Para cada sistema, faça três perguntas: quem recolhe, o que é recolhido e quanto tempo é conservado. Depois pergunte quem o pode ler e em que processo. A discussão do RFC 8484 sobre DNS over HTTPS é um bom lembrete de que o transporte cifrado não elimina o ponto final, e a documentação do próprio operador é a única afirmação fiável sobre o que esse ponto final conserva.

Quando se faz uma afirmação sobre privacidade acerca da «VPN», divida-a em componentes antes de a aceitar: o operador do túnel, o resolvedor que o túnel distribui, qualquer resolvedor a montante que essas consultas alcancem e as aplicações no dispositivo. Cada um tem a sua própria resposta, e uma afirmação exata para um é rotineiramente repetida como se cobrisse os quatro.

Para resolução de problemas, use a mesma divisão. Pergunte que aplicação fez a consulta e que resolvedor a respondeu, e depois olhe para o registro que realmente é dono desse evento. Adivinhar a partir do outro registro poupa um minuto e custa uma tarde.