Resumo
- A forma de comprimento zero da opção proposta autoriza ECS sem estabelecer um teto do cliente; prevalece o máximo do resolvedor, limitado por outras condições aplicáveis.
- Receber uma resposta com um valor é uma declaração do resolvedor, não prova independente de quantos bits foram enviados nem de como uma resposta em cache foi obtida.
O cliente marcou “sim”, mas não respondeu “quanto”. Na proposta de opt-in para EDNS Client Subnet, essa situação cabe em uma opção de comprimento zero: o resolvedor ganha permissão para encaminhar informação de endereço, enquanto seu próprio máximo define a exposição.
É uma escolha legítima de protocolo. Também é o tipo de escolha que interfaces e relatórios costumam simplificar demais. “Opt-in ativado” pode significar um teto explícito de 16 bits, um valor zero que proíbe encaminhamento ou uma autorização sem limite definido pelo cliente. Agrupar os três estados sob uma chave booleana apaga a decisão econômica e operacional que importa.
O documento Client Opt-In Signaling for EDNS Client Subnet, publicado em 20 de agosto de 2026, ainda é um Internet-Draft individual. Não é RFC, não foi adotado pelo grupo DNSOP, pede um código EDNS marcado como TBD e não traz evidência de implantação. A indicação de status Experimental é uma intenção editorial do rascunho, não a certificação de um experimento concluído. A análise, portanto, deve se concentrar nos limites que o texto realmente define.
O problema que a opção tenta resolver
RFC 7871 permite que um resolvedor recursivo envie a servidores autoritativos um prefixo do endereço de rede do cliente. A resposta pode ser adaptada à localização aproximada desse prefixo. O custo é a circulação de uma informação que, sem ECS, ficaria no limite entre o cliente e o resolvedor.
Um cliente pode pedir opt-out com SOURCE PREFIX-LENGTH igual a zero. Para pedir um prefixo positivo mais curto na opção ECS existente, porém, precisa fornecer o endereço cujos bits serão usados. Atrás de NAT, CGNAT ou VPN, o dispositivo pode desconhecer o endereço público observado pelo resolvedor. Seu endereço privado não representa o ponto de saída e não deve ser encaminhado como substituto.
A nova opção diz apenas que o resolvedor pode encaminhar e, opcionalmente, qual é o máximo. Na forma de um octeto, o valor é o maior número de bits permitido. Se não houver endereço ECS válido fornecido, o resolvedor usa o endereço de origem que observa. O limite efetivo é o menor entre o teto do cliente, um eventual teto ECS, o máximo local cacheável e o limite da família de endereço.
Essa operação de mínimo é um desenho de poder: nenhuma parte posterior pode aumentar o que uma parte anterior restringiu. Mas a forma sem dados não introduz a restrição do cliente. Ela autoriza a política do resolvedor até os demais tetos. Para organizações que anunciam minimização, essa diferença precisa aparecer na interface e no registro de auditoria.
Omitir é diferente de enviar zero
O rascunho recomenda que um cliente que não permite encaminhamento omita a opção. Um valor explícito zero também resulta em zero bits, mas revela em transporte não criptografado que o cliente implementa a proposta. A omissão reduz esse sinal e, para um resolvedor compatível, significa ausência de permissão.
Entretanto, a ausência só governa quem implementa o novo comportamento. Um resolvedor antigo ignora a opção desconhecida e responde como faria antes. Ele pode continuar usando ECS por configuração própria. A chegada normal da resposta não prova que a escolha do cliente foi entendida.
O mesmo vale para a forma sem dados. O painel pode mostrar “opt-in” sem mostrar que o máximo veio inteiramente da política do operador. Se essa política mudar de 24 para 32, o cliente continuará emitindo exatamente o mesmo pacote, mas a exposição autorizada aumentará. Uma decisão aparentemente local do operador muda o alcance de milhões de consentimentos genéricos.
Por isso, políticas de produto devem distinguir autorização aberta de teto explícito. A primeira é dependência contínua da configuração de terceiros. A segunda cria uma barreira que o resolvedor afirma respeitar, embora ainda seja necessário verificar a execução.
A resposta é o recibo de uma parte interessada
Um resolvedor compatível retorna o limite efetivo. O cliente pode ver zero ou um valor positivo e identificar a capacidade declarada. O dado é útil, mas vem do mesmo ator cujo comportamento está sendo medido.
Registros OPT não são assinados por DNSSEC. Uma resposta DNSSEC válida para o nome não autentica a afirmação sobre quantos bits foram encaminhados. O resolvedor pode enviar mais e declarar menos. Somente observação no lado autoritativo, quando disponível de modo legítimo, revela o prefixo recebido.
Transporte criptografado protege a mensagem contra terceiros no caminho. Sem criptografia, um atacante pode adicionar a opção, aumentar o valor, removê-la ou falsificar a resposta. Com DoT, DoH ou DoQ, essas alterações ficam protegidas no salto cliente-resolvedor. Ainda assim, a criptografia não controla o ato seguinte do resolvedor.
Uma governança honesta mantém recibos separados. O cliente prova o que pediu. A sessão prova como a instrução chegou. O resolvedor declara o que aplicou. O ponto autoritativo registra o que recebeu. A confiança pode ligar esses recibos, mas não deve transformá-los em um único fato.
O consentimento não viaja como credencial
O rascunho proíbe copiar a opção para consultas destinadas a servidores autoritativos ou simplesmente propagá-la para cima. A instrução é hop a hop e dirigida ao resolvedor que recebeu a escolha diretamente.
Um resolvedor de encaminhamento pode agir como cliente do próximo resolvedor e enviar uma nova opção. Seu limite não pode ser maior que o limite recebido. Se ele próprio montar ECS com o endereço do cliente, assume a responsabilidade de relatar os bits encaminhados. Se deixar a escolha de endereço para o serviço superior, o endereço visto acima será o do encaminhador e ele deve relatar zero bits do cliente original.
Essa não transitividade impede que uma escolha limitada vire mandato geral. Cada operador decide apenas sobre o ato que controla. ECS comum, sozinho, não demonstra opt-in do usuário, porque um encaminhador pode adicioná-lo. A opção separada existe para preservar a origem da decisão.
O cache preserva a consequência da divulgação
Um resolvedor que implementa a proposta não pode entregar a um cliente não sinalizante uma resposta obtida com ECS. Precisa saber, para cada entrada, se ECS participou de sua obtenção. Caso contrário, uma resposta adaptada para outra rede pode atravessar a fronteira sem deixar marca no pacote entregue.
Separar caches é uma solução. Guardar metadados de origem e aplicar critérios de elegibilidade é outra. O requisito é que a decisão seja demonstrável. Um cache que preserva apenas nome, tipo, TTL e resposta perdeu a informação necessária para cumprir a regra.
Para clientes sinalizantes, a correspondência de prefixo de RFC 7871 continua. Uma entrada obtida com prefixo mais longo que o teto atual pode ser usada, pois o acesso ao cache não encaminha novos bits. Isso separa exposição de reutilização. O teto limita uma transmissão; a origem do cache e o contexto do cliente decidem se o resultado anterior pode responder.
O rascunho atualmente manda relatar o limite efetivo mesmo em acerto de cache. Nesse caso, o valor pode ser 24 embora nenhum bit novo tenha sido enviado. O próprio texto deixa em aberto se deveria reportar os bits realmente usados. Teto permitido e divulgação ocorrida são métricas distintas, especialmente quando não houve consulta autoritativa.
Um prefixo reduzido não é anonimato
O prefixo pode chegar a vários servidores autoritativos e a observadores do tráfego não protegido. Reduzir seu comprimento diminui a precisão, mas não o torna anônimo. Uma política responsável escolhe o menor teto que preserve a utilidade e explica quem ainda pode observar a informação.
Uma futura atribuição do código EDNS também não encerrará a análise. O registro evita colisão e permite software interoperável. Não comprova que caches mantêm origem, que encaminhadores preservam limites ou que resolvedores declaram a verdade. A coordenação do identificador é mais estreita que a garantia operacional.
O insight de liderança está na diferença entre dar permissão e definir um limite. A opção de comprimento zero transfere poder à política do resolvedor. Isso pode ser aceitável, desde que seja visível, reversível e não vendido como minimização escolhida pelo usuário. Quando a interface esconde essa diferença, um “sim” pequeno autoriza uma mudança futura grande.
Fontes
- https://www.ietf.org/archive/id/draft-farrokhi-dnsop-ecs-opt-in-00.txt
- https://www.ietf.org/archive/id/draft-farrokhi-dnsop-ecs-opt-in-00.html
- https://www.ietf.org/archive/id/draft-farrokhi-dnsop-ecs-opt-in-00.xml
- https://datatracker.ietf.org/doc/draft-farrokhi-dnsop-ecs-opt-in/
- https://datatracker.ietf.org/doc/draft-farrokhi-dnsop-ecs-opt-in/history/
- https://datatracker.ietf.org/doc/draft-farrokhi-dnsop-ecs-opt-in/references/
- https://datatracker.ietf.org/api/v1/doc/document/draft-farrokhi-dnsop-ecs-opt-in/
- https://www.rfc-editor.org/rfc/rfc7871.txt
- https://www.rfc-editor.org/rfc/rfc6891.txt
- https://www.rfc-editor.org/rfc/rfc9499.txt
- https://www.rfc-editor.org/rfc/rfc7858.txt
- https://www.rfc-editor.org/rfc/rfc8484.txt
- https://www.rfc-editor.org/rfc/rfc9250.txt
- https://www.rfc-editor.org/rfc/rfc8126.txt
- https://www.rfc-editor.org/rfc/rfc7942.txt
- https://www.rfc-editor.org/rfc/rfc6890.txt
- https://www.rfc-editor.org/rfc/rfc9660.txt
- https://www.ietf.org/archive/id/draft-bellis-dnsop-edns-tags-01.txt
- https://www.rfc-editor.org/rfc/rfc7873.txt
- https://www.rfc-editor.org/rfc/rfc7828.txt
- https://www.rfc-editor.org/rfc/rfc7314.txt
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
