Resumo

  • A revisão 03 do rascunho DNSOP sobre GREASE propõe usar valores não alocados em pontos de extensão do DNS para impedir que implementações e middleboxes tratem apenas os valores atuais como aceitáveis. É um Internet-Draft ativo e incompleto, não uma RFC nem autorização de implantação.
  • A repetição sequencial pode acrescentar latência; uma consulta comum em paralelo preserva o caminho de serviço, mas aumenta o volume no lado autoritativo. GREASE iniciado pelo respondedor é mais arriscado porque ele pode não observar o dano no cliente final.
  • Antes da ativação padrão, uma carta com prazo deve registrar campo, algoritmo, amostra, exclusões, limites de atraso e volume, telemetria, risco de impressão digital, data final, gatilhos de interrupção e dono da reversão. É uma proposta de Daniel Kade, não uma exigência do IETF.

Um ponto de extensão pode existir no documento e desaparecer na prática. Basta passar anos sem receber valores novos. O software começa a confundir a lista vista com a lista permitida. Equipamentos intermediários repetem a suposição. Tudo parece estável até o dia em que uma extensão real tenta usar o espaço e encontra uma rede que já não aceita mudança.

GREASE mantém o espaço em movimento. Ele cria valores sem significado operacional, destinados a ser ignorados. A RFC 8701 aplicou o método ao TLS por meio de valores reservados e espalhados. Um par correto continua a negociação; o defeito de um par intolerante aparece antes que um recurso futuro dependa dele.

O rascunho Greasing Protocol Extension Points in the DNS examina a aplicação ao DNS. A revisão 03 saiu em 6 de julho de 2026 e expira em 7 de janeiro de 2027. O texto pertence ao grupo DNSOP, mas continua sendo trabalho em andamento. Não há consenso do grupo sobre faixas reservadas. A seção de valores reservados ainda traz um marcador, e comportamento detalhado, fallback, fim de teste, controles individuais e compartilhamento de telemetria aparecem como assuntos a desenvolver.

Esse estágio pede experimentação cuidadosa, não imobilidade. Também impede que a capacidade técnica seja confundida com uma delegação automática para usar tráfego de produção.

Cada campo cobra uma conta diferente

O rascunho menciona a posição restante de flag no cabeçalho DNS, Opcode, versão EDNS, flags EDNS, Class, tipo de registro e código de opção EDNS. Os espaços variam de um bit a 65.536 valores. O estoque não alocado muda conforme a IANA faz registros.

RCODE e RCODE estendido ficam de fora. Esses campos comunicam o estado da resposta; alterá-los mudaria o juízo do solicitante, em vez de apenas verificar se uma novidade sem significado é tolerada.

Portanto, GREASE não é sinônimo de mensagem malformada. Ele usa uma estrutura em que o valor desconhecido deveria ser ignorado. O fracasso comprova uma diferença entre experimento e controle, mas não identifica automaticamente o middlebox, a versão ou o operador responsável.

Uma opção EDNS ainda carrega dados, que precisam de regra própria. Um teste de RR Type pode construir outra pergunta. Um intervalo razoável para dezesseis bits é impossível numa posição única. A autorização precisa nomear o ponto de extensão e a direção; um único botão para “DNS GREASE” não descreve o que realmente foi ligado.

Proteger o usuário pode transferir custo ao servidor

No modelo sequencial, o resolvedor envia a consulta com GREASE e, se houver falha, repete sem o valor. O serviço pode terminar bem, mas o usuário absorve o tempo da primeira tentativa. Se a monitoração registra só a resposta final, a incompatibilidade fica escondida pelo próprio mecanismo de proteção.

No modelo paralelo, uma consulta normal sai junto com a experimental. A primeira serve a resolução; a segunda produz apenas telemetria. A latência do usuário fica isolada, porém a autoridade e a rede processam tráfego adicional.

Uma opção gasta orçamento de atraso; a outra gasta orçamento de consultas, CPU e saída. Ambas consomem logs, análise e coordenação de incidentes. A informação fica com o iniciador, enquanto parte da conta vai para a contraparte.

A revisão 03 fala em amostra pequena e inclui, ainda com interrogação, algo como uma consulta em mil. Não é limite normativo nem prova de segurança. Um milésimo de um resolvedor público gigantesco ainda pode concentrar carga relevante em uma autoridade pequena.

As regras precisam combinar percentual e teto absoluto, incluindo limite por destino. Janelas de incidente, sistemas frágeis e usos sensíveis a atraso podem ser excluídos. A expansão deve ocorrer em fases e parar quando a comparação com o tráfego normal deixa de ser confiável.

O respondedor não enxerga necessariamente o fim da história

O foco principal do texto é o GREASE iniciado pelo resolvedor. Quem envia a consulta conhece o valor e observa a resposta próxima, podendo repetir ou comparar. Ainda não localiza sozinho o defeito, mas controla os extremos imediatos da medição.

Um servidor autoritativo também poderia inserir uma flag, opção ou versão inesperada na resposta. Em experiência direcionada, isso é útil. O problema é que o servidor talvez não saiba se o resolvedor aceitou a mensagem, tentou outro servidor, falhou em silêncio ou causou indisponibilidade numa aplicação atrás dele.

Por isso o rascunho diz que GREASE iniciado pelo respondedor deveria vir desabilitado. O produto não deve juntar as duas direções na mesma preferência. Consentir com sondas do resolvedor não significa consentir com respostas experimentais da autoridade.

Um teste do lado servidor precisa de zona ou tráfego nomeado, observadores externos, teto menor e desligamento imediato. A ausência de erro no log autoritativo não comprova que o usuário ficou ileso.

Reservar evita uma colisão e cria outro atalho

Valores reservados para GREASE são fáceis de reconhecer e não serão usados depois como extensão normal. Ao mesmo tempo, o receptor pode aprender a ignorar apenas essa faixa conhecida. Passará no teste e continuará rejeitando qualquer outro número novo. O remédio ganha sua própria forma de ossificação.

Escolher aleatoriamente entre valores hoje não alocados evita um padrão tão simples. Mas um deles pode receber significado real da IANA no futuro. Software antigo, treinado para descartá-lo, talvez continue descartando a nova extensão.

O rascunho sugere uma data de término pré-configurada ou configurável. Trata-se de segurança de protocolo, não de mera organização de projeto. O vencimento interrompe uma suposição velha e obriga a renovar o teste com uma fotografia atual do registro.

Na data desta pesquisa, a página IANA Domain Name System Parameters havia sido atualizada em 28 de agosto de 2026 e mantinha registros separados para classes, tipos, opcodes, opções e versões EDNS. Ela não oferecia uma decisão pronta para as faixas gerais de DNS GREASE ainda abertas no rascunho.

A carta deve guardar o estado do registro analisado no início. Esse documento comprova o que parecia livre naquele momento; não concede posse duradoura. Nova alocação em conflito deve aposentar o valor experimental de forma automática.

O dado precisa pagar pela perturbação

GREASE só produz benefício se o resultado levar a um diagnóstico. O rascunho geral sobre a técnica mostra a tensão: frequência baixa demais some no ruído; frequência e padrão constantes demais facilitam tratamento especial.

No DNS, a repetição cria dois resultados. O serviço pode obter sucesso depois que o ensaio falhou. O evento mínimo deve registrar ponto de extensão, classe do valor, versão do algoritmo, direção, horário, resposta observada, duração, ramificação de controle e aquilo que foi entregue ao cliente.

O registro não pode dizer mais do que sabe. Timeout não aponta sozinho para um intermediário. FORMERR não informa onde houve rejeição. Uma diferença repetível permite abrir investigação; não basta para responsabilizar publicamente um operador.

Há também o risco de identificação. A revisão DNS alerta que valores não aleatórios podem denunciar implementações de resolvedor. A orientação mais ampla lembra que variação de parâmetros também participa de técnicas de fingerprinting. Um padrão estável durante uma versão melhora a reprodução, mas torna o produto reconhecível; mudança a cada consulta reduz estabilidade e pode deixar a repetição automática mascarar defeitos.

A carta deve registrar a escolha: rotação por período, minimização de nomes, retenção curta, acesso limitado aos eventos brutos e compartilhamento agregado. “Telemetria anônima” sem definição de campos e prazo não resolve a questão.

Fallback é contenção, não absolvição

Desligar uma extensão e tentar novamente preserva compatibilidade. Também permite que software rígido continue sem correção, transferindo o custo de manutenção para todos os emissores.

O problema pode ser de segurança. A revisão 03 observa que uma rota de fallback capaz de desligar opções de extensão pode ser provocada para remover uma proteção. GREASE busca revelar essa fragilidade e, com o tempo, reduzir a necessidade de recuo para extensões futuras.

Descobrir intolerância, conter o impacto e retirar o fallback são três decisões. O operador que mede pode não controlar o equipamento defeituoso. Retirar a compatibilidade imediatamente transforma dívida técnica em falha para o usuário.

O registro deve manter estados distintos: observado, mitigado, corrigido e autorizado para retirada. Cada transição tem dono e evidência. O gráfico experimental informa a decisão; não a substitui.

Uma carta que expira por desenho

O primeiro campo é autoridade: quem aprovou tráfego real, quem implementa, quem interpreta e quem possui acesso efetivo ao desligamento. O padrão escolhido pelo fornecedor não vale como consentimento de todos os operadores.

Depois vem o objeto de protocolo: ponto de extensão, conjunto ou algoritmo, conteúdo adicional, direção, versão e fotografia da IANA. Reservado, experimental, privado e não alocado não devem virar uma só categoria.

O escopo especifica classes incluídas e excluídas, percentual, taxa máxima global e por destino, etapas e período de observação. Declara se o controle é repetição posterior ou consulta paralela. Separa limites de latência, falha, volume, processamento, logs e alertas.

A parte de evidência define sucesso, falha e ausência de atribuição; coleta mínima; retenção; compartilhamento; proteção contra impressão digital; e canal para contestar uma conclusão. A consulta normal precisa continuar capaz de servir mesmo quando a rama experimental falha.

Por fim, a carta fecha o tempo: início, término padrão, renovação explícita, revisão do registro, interruptor por teste, gatilhos automáticos e dono da reversão. Aumento de falha visível, sobrecarga, perda do controle, assinatura estável ou colisão com alocação nova são razões para parar antes de ampliar.

O DNS precisa conservar espaços que ninguém usa ainda. Isso não transforma a capacidade, o tempo e a confiança usados hoje em recursos sem dono. GREASE merece virar prática regular somente depois que sua irregularidade deliberada puder ser limitada, explicada e desfeita.

Fontes

  1. Greasing Protocol Extension Points in the DNS — revisão 03
  2. Registro do rascunho DNS GREASE no Datatracker
  3. Histórico do documento DNS GREASE
  4. Documentos ativos do DNSOP
  5. Carta do grupo DNSOP
  6. RFC 8701 — GREASE no TLS
  7. RFC 6891 — mecanismos de extensão do DNS
  8. Maintaining Protocols Using Grease and Variability — revisão 06
  9. Parâmetros DNS da IANA