Resumo

  • O RFC 5625 saiu em agosto de 2009 como BCP 152, com um único autor, e sua página de status pede discussão e sugestões; o RFC 8490 é um Proposed Standard de março de 2019, com seis autores, cujas obrigações só fazem sentido em conjunto.
  • Os dois textos dizem o que um implementador pode ou deve fazer, e nenhum dos dois alcança quem escolhe não adotar. O registro da IANA guarda o OpCode 6 e os códigos de tipo da DSO, mas nenhum registro prova que uma rede qualquer os utilize.

Duas datas, dois leitores

Há uma assimetria que o leitor apressado perde. O RFC 5625 foi escrito para ser lido por quem monta firmware de gateway doméstico e precisa decidir o que fazer com um pacote que não entende. O RFC 8490 foi escrito para quem mantém software de servidor e cliente e precisa coordenar um estado que só existe se as duas pontas concordarem. O primeiro trata de não estragar; o segundo, de construir.

A forma editorial acompanha essa diferença. O RFC 5625 é uma Best Current Practice: em agosto de 2009 virou o BCP 152, e a página do BCP 152 mostra uma sub-série com exatamente um RFC dentro. Prática corrente, num documento só, assinado por R. Bellis, então na Nominet UK, e produzido no grupo DNSEXT a partir do draft-ietf-dnsext-dnsproxy (texto do RFC 5625).

O RFC 8490 é outra coisa. Proposed Standard, março de 2019, seis assinaturas — Bellis pela ISC, Cheshire pela Apple, os dois Dickinson pela Sinodun, Lemon pela Nibbhaya e Pusateri sem afiliação — e a atualização de dois documentos anteriores, o RFC 1035 e o RFC 7766 (texto do RFC 8490).

Os verbos que proíbem mexer

No RFC 5625, quase todo verbo forte serve para impedir interferência. A seção 4.1 exige que o proxy ignore qualquer flag de DNS desconhecida e encaminhe o pacote como está. A seção 4.4 exige que, se o proxy precisar truncar uma resposta por conta própria, marque o bit TC. A seção 4.5 exige que ele seja capaz de encaminhar pacotes com registros de recurso TKEY. Três obrigações, nenhuma delas pedindo uma funcionalidade nova: todas pedem que o intermediário não invente.

O que é positivo aparece em grau menor. A seção 3 recomenda que o proxy seja tão transparente quanto possível. A seção 4.4.1 diz que, ao receber uma consulta por TCP, ele deve encaminhá-la por TCP e não tentar UDP primeiro. A seção 5.2 recomenda que o valor padrão da opção descrita seja vazio. O autor sabia o que estava fazendo ao escolher esse registro: um equipamento vendido em 2009 continuará em serviço quando o DNS já tiver mudado, e a única regra que se sustenta nesse horizonte é a de não atrapalhar. Um proxy que só transporta o que não compreende é um proxy que sobrevive à próxima extensão do protocolo sem uma atualização de firmware.

O que uma sessão obriga a dividir

No RFC 8490, os verbos fortes não protegem um observador externo. Constituem um estado compartilhado. A seção 5.1 proíbe que o servidor inicie mensagens de requisição DSO ou mensagens unidirecionais antes que uma sessão DSO tenha sido mutuamente estabelecida. A seção 5.1.1 proíbe que um servidor que implementa DSO devolva DSOTYPENI a uma requisição de Keepalive, porque o TLV de Keepalive é de implementação obrigatória. A seção 5.4.1 trata um identificador de mensagem igual a zero em resposta DSO como erro fatal, com aborto forçado da conexão.

Leia as três juntas e aparece uma instituição de duas partes: a sessão existe porque as duas pontas a criaram; um código de recusa desaparece do repertório disponível porque certa peça é obrigatória; um identificador inválido não é advertência, é encerramento. O texto determina, e é isso que um documento pode fazer. Não determina que alguém implemente: um resolvedor que prefira não manter estado simplesmente não entra na conversa, e nenhuma cláusula o alcança.

As obrigações mais fracas tratam da leitura do silêncio. Um cliente deve esperar trinta segundos quando não recebe resposta e deve marcar aquela instância de serviço como não compatível com DSO se o servidor derrubar a conexão. São instruções sobre o que concluir de uma ausência, e o tipo de coisa que uma especificação consegue fixar sem tocar no que está instalado.

A página de errata em branco

O registro público de correções é o melhor teste disponível a um leitor externo sobre a saúde de um documento. Em 18 de outubro de 2026, a página de errata do RFC 5625 e a do RFC 8490 não exibiam nenhum item, e nenhuma das páginas de informação indicava documento obsoleto ou sucessor. Isso é o que as páginas mostravam naquele dia, e vale exatamente por isso.

Uma página vazia tem duas leituras possíveis que se parecem em tudo: o texto resistiu ao uso, ou ninguém propôs correção. Um verificador de registro não distingue as duas. O mesmo cuidado se aplica à história editorial. Os registros do Datatracker para o RFC 5625 e para o RFC 8490 estavam disponíveis como resumos de página, não como histórico completo de revisões, então a linhagem das duas discussões aparece pela metade: sabe-se que uma passou pelo DNSEXT e outra pelo DNSOP, não se sabe qual rascunho produziu qual frase.

E o ponto mais importante: não há evidência de implementação. Este texto não afirma que o RFC 5625 mudou a forma como gateways encaminham consultas, nem que a DSO esteja presente em algum resolvedor em produção. É uma pergunta sobre software, e o software não deixou rastro no material examinado.

O número que sobrevive ao autor

A tabela de parâmetros de DNS da IANA registra o valor 6 de OpCode como DNS Stateful Operations, com referência ao RFC 8490, e mantém ao lado uma tabela de DSO Type Codes com 0x0001 KeepAlive, 0x0002 RetryDelay e 0x0003 EncryptionPadding. Três linhas de registro, atribuídas por procedimento, mantidas por uma função administrativa que não depende de quem escreveu o documento.

Essa é a parte da história que realmente dura. Um assinatura de RFC é um ato datado; um registro de protocolo é uma inscrição que continua sendo consultada depois que o autor mudou de emprego, de empresa e de interesse. Mas a durabilidade é do registro, não de quem o pediu. A IANA guarda que o código existe, não que alguém o envie.

Onde termina a autoria

Sobra um inventário pequeno e verificável do que Ray Bellis controlou. Controlou a redação: quais obrigações receberam MUST, quais ficaram em RECOMMENDED, e em especial a decisão de usar o verbo mais forte para proibir dano em vez de exigir recurso. Controlou, entre cinco coautores, a escolha de tratar a sessão como precondição e não como cortesia. Controlou a submissão que transformou essas frases em registro. São atos reais, atribuíveis a uma pessoa nomeada, visíveis no texto.

Não controlou a parte que decide se aquilo importa. Um implementador lê o RFC 8490, compara o custo do estado de sessão com o calendário do seu firmware e recusa. Nenhuma frase do documento o alcança, e é justamente por isso que o registro importa mais do que a assinatura: ele permanece quando a adoção não vem.