Resumo

  • O ECS pode multiplicar entradas para o mesmo nome, tipo e classe porque a resposta passa a ser selecionada também por prefixo de rede; por isso o RFC 7871 recomendou operação desativada por padrão e limites de cache.
  • O resolvedor escolhe quantos bits da rede do cliente envia; o servidor autoritativo devolve um escopo que determina a área em que a resposta poderá ser reutilizada.
  • O prefixo não comprova identidade, consentimento nem posição geográfica precisa. O RFC 8932 recomendou evitar ECS em serviços de privacidade ou minimizar e divulgar seu uso.

Uma cache deixa de ser uma só

O DNS em cache começa pelo conjunto conhecido de nome, tipo e classe. Com ECS, a busca ganha outra dimensão: depois desse trio, o resolvedor escolhe o RRset adequado por correspondência de prefixo. Respostas ao mesmo nome podem ficar associadas a redes diferentes, conforme o escopo devolvido pela autoridade.

Essa separação cobra um preço. Mais partições significam potencialmente mais memória, menos acertos compartilhados e maior carga no resolvedor e nos servidores consultados. O RFC 7871 recomendou manter o recurso desligado nas configurações padrão, ativá-lo somente quando houvesse benefício claro para clientes e limitar o número de redes e respostas preservadas para cada consulta. Também aconselhou nunca enviar mais bits de endereço do que o resolvedor está disposto a armazenar.

Quando uma resposta não contém ECS, ela é normalmente tratada como escopo /0, reutilizável para todos os endereços de cliente. Se a autoridade responde REFUSED, um resolvedor compatível repete a consulta sem ECS. Assim consegue distinguir a rejeição da opção de outras convenções que usam o mesmo código.

Por que introduzir a partição

Um servidor autoritativo costuma ver o endereço do resolvedor recursivo, não a origem da consulta. Quando ambos estão próximos na topologia, esse endereço pode servir como indicação aproximada. Um resolvedor central, porém, pode representar usuários em redes muito distantes; adaptar a resposta à sua própria posição pode não beneficiar a pessoa por trás dele.

O EDNS Client Subnet permitiu que o intermediário enviasse informação sobre a rede de origem. A opção contém a família de endereços, o comprimento do prefixo de origem, o comprimento do escopo e um endereço variável. Em IPv4 ou IPv6, o endereço é truncado aos bits significativos e preenchido apenas até o último octeto necessário. Não é preciso transmitir o endereço inteiro.

O resolvedor configura um comprimento máximo compatível com a sua cache e deve escolher algo menor que o endereço completo. Se uma consulta recebida já traz limite mais curto, um encaminhador posterior não pode ampliá-lo. A promessa operacional é estreita: fornecer uma pista de rede para que a autoridade possa adaptar a resposta. O RFC não garante que essa resposta será a mais próxima, rápida ou disponível.

Quem limita a divulgação e quem limita o efeito

Na consulta, SOURCE PREFIX-LENGTH diz quantos bits iniciais do endereço têm significado; SCOPE PREFIX-LENGTH vale zero. Na resposta, a autoridade mantém o comprimento de origem e devolve um escopo real. Esse segundo número indica quantos bits iniciais definem a rede coberta pela resposta.

Um escopo curto permite reaproveitamento mais amplo. Um escopo longo pode mostrar que o prefixo apresentado não foi específico o bastante para a seleção pretendida. As duas medidas, portanto, não são intercambiáveis. A primeira limita o que o resolvedor revela em nome do cliente; a segunda limita quais clientes posteriores herdarão o resultado da autoridade.

Nenhuma delas prova identidade ou geografia. O próprio RFC distingue proximidade topológica de distância física e deixa fora de seu escopo o método de seleção usado pela autoridade. O prefixo é uma pista, e o escopo é uma regra de cache — não credenciais, consentimento ou certificado de localização.

Optar por /0 depende de um caminho real

Um stub pode pedir SOURCE PREFIX-LENGTH igual a zero. O resolvedor que recebe essa instrução não deve acrescentar informações do endereço do cliente nas consultas seguintes; pode omitir ECS ou usar dados próprios. Encaminhadores também devem preservar o limite recebido.

O RFC 7871 registrou, em 2016, que a possibilidade prática de expressar essa preferência era limitada quando o software não expunha a opção. Trata-se de uma observação histórica, não de um retrato atual. As fontes usadas aqui não oferecem censo de adoção, comparação de fornecedores ou inventário de resolvedores públicos.

Em 2020, o RFC 8932 tratou o problema do ponto de vista dos serviços de privacidade DNS. Criptografar o trecho entre cliente e resolvedor impede certos observadores de ler a consulta, mas o resolvedor continua a vê-la e pode enviar informações adiante. A recomendação é respeitar /0 e evitar ECS a montante ou oferecer uma alternativa sem ele. Se houver uso, o operador deve mandar o prefixo operacional mais curto, preferencialmente restringir os destinos elegíveis e informar comprimento e política reais.

Segurança de resposta não autentica o contexto

O RFC 7871 recomenda conferir campos de identidade entre consulta e resposta e descartar divergências. Isso restringe algumas oportunidades de falsificação e envenenamento de cache, mas não autentica a rede do cliente nem torna a escolha autoritativa confiável por si só.

DNSSEC também é separado do escopo ECS. A recomendação é usar /0 para a maioria dos registros DNSSEC; uma RRSIG continua ligada ao RRset que assina. Validação não assina a decisão do resolvedor de divulgar o prefixo, não prova geografia e não certifica a política de localidade.

A lição histórica não é que ECS sempre melhorou a entrega ou destruiu a privacidade. É que uma otimização acrescentou duas políticas duráveis: quanto contexto de rede um intermediário envia e como outro divide o reaproveitamento do resultado. Essa é uma inferência editorial baseada na mecânica documentada, não uma medição da implantação atual.

Fontes