Resumo

  • Uma sessão DNS autenticada e criptografada comprova propriedades do transporte até o resolvedor; não comprova o tratamento dado à consulta depois que ela chega.
  • A RPS proposta pelo RFC 8932 organiza promessas comparáveis, mas transporte, processamento, armazenamento/acesso e divulgação a montante precisam de evidências próprias, datadas e limitadas.

O celular entra em uma rede de aeroporto e abre uma conexão criptografada com um resolvedor escolhido pelo usuário. Quem controla o Wi-Fi deixa de enxergar facilmente os nomes consultados. O cliente autentica o serviço remoto e reduz o risco de interferência no trajeto. O cadeado representa um ganho concreto.

Só que o trajeto termina em algum lugar. No resolvedor recursivo, a pergunta precisa ser lida para que a resposta seja encontrada. O operador consegue, em princípio, ver a consulta e identificadores do transporte. Também decide o que registrar, por quanto tempo, quem pode acessar, quais sessões podem ser correlacionadas, se a resposta será alterada e quanta informação seguirá para outros servidores.

O RFC 8932, Recommendations for DNS Privacy Service Operators, é valioso por não esconder essa mudança de fronteira. Publicado em outubro de 2020 como BCP 232, o documento é trabalho conjunto de Sara Dickinson, Benno Overeinder, Roland van Rijswijk-Deij e Allison Mankin. O perfil de Dickinson no IETF lista oito RFCs, entre eles o RFC 8932 e o RFC 9250 sobre DNS em QUIC, além de registrá-la como chair do Privacy Enhancements and Assessments Research Group. A RIPE Labs a apresenta como cofundadora da Sinodun IT. Isso delimita uma contribuição continuada, sem transformá-la em inventora única da privacidade no DNS nem em responsável pelos serviços de terceiros.

O documento combina recomendações de operação com uma estrutura de transparência: a Recursive operator Privacy Statement, ou RPS. A intenção não é produzir uma política universal. É oferecer uma ordem comum para que operadores descrevam compromissos e práticas atuais, permitindo comparar propriedades mensuráveis com propriedades declaradas. Publicar a RPS não equivale a obter uma certificação, e o texto não pretende substituir aconselhamento jurídico.

A primeira evidência cobre o transporte entre cliente e serviço. Ela registra endpoint, nome de autenticação, protocolo, resultado do certificado, versão TLS ou QUIC, preenchimento, disponibilidade e eventual fallback para DNS aberto. O RFC 8310 trata de perfis para DNS sobre TLS; o RFC 8484 define DNS sobre HTTPS; o RFC 9250 define DNS em conexões QUIC dedicadas. Cada mecanismo protege esse trecho e identifica seu destino. Nenhum determina que o operador apague a consulta após descriptografá-la.

Essa evidência tampouco substitui DNSSEC. Segundo o RFC 8932, criptografia de transporte e DNSSEC são independentes. Um cliente que não faz sua própria validação não obtém, apenas por usar um canal autenticado, prova de que o resolvedor validou os dados. Ele pode estar confiando no bit AD recebido. O certificado identifica o serviço no fim do canal; não certifica a origem de cada registro DNS devolvido.

A segunda evidência pertence ao processamento. Qual validação foi usada? A resposta veio do cache? Uma regra de segurança, exceção ou lista de bloqueio modificou o resultado? Endereço IP, retomada de sessão, cabeçalhos HTTP, parâmetros TLS ou padrões de consulta foram usados para associar conexões? O RFC 9076 chama atenção para a possibilidade de correlacionar tráfego DNS criptografado na entrada com consultas abertas que saem do resolvedor.

Usar sempre o mesmo resolvedor deixa mais claro quem recebe os dados em redes distintas. Ao mesmo tempo, pode permitir que um operador reconheça o usuário ao longo dessas mudanças. Não há contradição: reduzir observadores intermediários e reduzir a correlação no destino são objetivos diferentes. O primeiro não deve ser usado como atalho para alegar o segundo.

A filtragem também exige recibo próprio. O RFC 8932 pede que a RPS explique alterações feitas por segurança de rede, obrigação legal vinculante, política voluntária de risco jurídico, interesse comercial ou outro motivo. Deve dizer ainda como as listas são geridas e quais fontes externas participam. Um canal pode ser confidencial e entregar uma resposta filtrada. “DNS seguro” é uma expressão insuficiente para distinguir essas escolhas.

A terceira evidência trata de armazenamento e acesso. O RFC recomenda minimizar ou evitar retenção e, quando dados forem mantidos, protegê-los com criptografia e, quando possível, agregação, pseudonimização ou anonimização. O período dos logs deve se limitar à necessidade operacional e regulatória aplicável; o acesso deve ficar com quem precisa dele para desempenhar sua função.

O texto da política é apenas o início. Dizer “sete dias” não prova que uma exclusão ocorreu; o resultado da regra de ciclo de vida pode demonstrar uma execução específica. Uma matriz de cargos não prova quem abriu um arquivo; o log de acesso responde a isso. Criptografia em repouso não mostra se uma cópia saiu do ambiente. E pseudonimização não deve ser promovida a anonimato: um identificador estável mantém a possibilidade de reunir eventos e pode ser revertido quando o mapa ou o método está disponível.

A quarta evidência acompanha os dados que deixam o resolvedor. Para concluir a resolução, o serviço pergunta a outros resolvedores ou a servidores autoritativos. O RFC 8932 recomenda minimizar o QNAME, enviando a cada etapa apenas a parte necessária; o RFC 9156 atualiza o procedimento. Recomenda ainda não usar EDNS Client Subnet ou, se houver necessidade operacional, adotar o prefixo mais curto possível e divulgar a política aplicada.

Um teste externo pode confirmar que uma pergunta observada foi minimizada ou não levou ECS. É uma medição importante, com horário, ponto de vista e caso de teste. Ela não prova a mesma conduta para todos os nomes, encaminhadores e exceções. Também não alcança o compartilhamento posterior de um log armazenado. A privacidade no primeiro salto pode coexistir com exposição desnecessária no seguinte.

A RPS, por isso, pede informações concretas. Endereços IP são tratados como dados pessoais? O que é coletado, retido, compartilhado, vendido ou alugado? Quais métodos de minimização e condições de transferência valem? Quais exceções, afiliados e fontes de financiamento existem? Há correlação com outros dados pessoais? Respostas são filtradas? A seção de prática acrescenta os endpoints e métodos de autenticação, capacidades a montante, desvios de política, suporte e processamento relevante.

Uma boa declaração funciona como índice de comprovação. A promessa de minimizar QNAME aponta para configuração e teste independente. O prazo de retenção aponta para regra e resultado de exclusão. A limitação de acesso aponta para papéis e eventos auditados. O compartilhamento aponta para destinatário, finalidade, campos, condição e vencimento. Relatórios de transparência e auditorias com escopo definido podem ampliar a observação.

Ainda assim, documento e execução não são sinônimos. Auditorias cobrem períodos e amostras; sondas enxergam determinados caminhos; relatórios dependem do acesso de quem os escreve; uma RPS pode ficar atrás da configuração. Reconhecer esses limites não torna a privacidade impossível de avaliar. Impede apenas que uma evidência seja esticada até afirmar o que nunca observou.

O legado prático de Dickinson e dos demais autores está nessa mudança de pergunta. Em vez de encerrar a análise no “DNS está criptografado”, o operador precisa dizer quem decide o destino da consulta depois da chegada, qual rastro torna a decisão verificável e quando a prova deixa de ser atual.

Fontes