Resumo

  • RFC 5395 tratou OpCodes, RCODEs, bits de cabeçalho, TYPEs de dados, QTYPEs, Meta-TYPEs e CLASSes como espaços semânticos distintos, mesmo quando cabem em campos de mesma largura.
  • Não atribuído, reservado e Private Use são estados diferentes. O último permite acordos locais, mas transfere aos participantes a responsabilidade por colisões.
  • A prova operacional deve separar campo e contexto, número, procedimento de autoridade, retrato datado do registro, preservação na rede, interpretação pelo software e efeito para o usuário.

A custódia dos bytes funcionou

RFC 3597 criou uma representação genérica para resource records desconhecidos: TYPE seguido do número decimal, depois \#, comprimento e RDATA hexadecimal. Também limitou compressão e definiu comparação de modo que servidores pudessem armazenar e transferir material que ainda não compreendiam.

Esse mecanismo resolve um problema essencial de implantação. Um novo TYPE não precisa esperar que cada servidor intermediário receba código especializado. A infraestrutura antiga pode exercer custódia neutra enquanto aplicações novas interpretam a semântica nas extremidades.

Mas custódia não é execução. Um secundário que replica o RR demonstrou transferência. Um cache que o devolve demonstrou retenção. Uma API que expõe os octetos demonstrou acesso. Nenhum desses recibos prova que o consumidor validou o formato, tomou a decisão pretendida ou produziu benefício para o usuário.

Há também o caso inverso. Uma interface pode reconhecer o mnemônico e aceitar a entrada, mas serializar RDATA incorretamente. O teste precisa acompanhar apresentação, parser, wire format, transferência, cache, API, biblioteca, aplicação e resultado. Se o tipo já é conhecido, escrevê-lo na forma genérica não elimina seu processamento específico depois da leitura.

Uma linha vazia descreve estado, não permissão

Ao consultar a tabela da IANA, uma equipe pode encontrar um valor marcado como unassigned. Isso responde apenas se uma atribuição pública foi registrada naquele instante. Não informa quem está autorizado a alterar o estado, qual procedimento se aplica, nem se um experimento local pode escapar para a Internet.

RFC 5395 distribuiu políticas diferentes por OpCodes, RCODEs, bits, RRTYPEs, CLASSes e subtipos AFSDB. Alguns valores exigiam Standards Action, outros IETF Review ou Expert Review. Reserved continha uma barreira mais forte. Private Use oferecia liberdade local em troca da ausência deliberada de unicidade global.

Escolher ao acaso um valor não atribuído toma emprestado o futuro da tabela. Uma atribuição legítima posterior pode encontrar equipamento instalado com outro significado, e o custo de migração vira argumento político para conservar a ocupação. O experimento não adquire autoridade por ter chegado primeiro.

O registro de mudança deve, portanto, guardar o nome do registro, o campo, o estado, a política, a referência, o responsável, o domínio de colisão e a saída planejada. “Estava livre” é uma observação sem cadeia de decisão.

Dois laboratórios podem estar corretos e colidir

Para RRTYPE, Private Use ocupa 65280 a 65534. Imagine duas organizações que escolhem 65300. Em uma, ele carrega uma declaração de saúde; na outra, uma credencial de política. Dentro de cada laboratório, servidor e cliente concordam, e todos os testes passam.

Depois de uma interconexão, fusão ou serviço de DNS compartilhado, o mesmo número chega com RDATA incompatível. Não existe linha pública que eleja um significado, pois a falta dessa coordenação é exatamente o contrato de Private Use. RFC 8126 deixa aos usuários a prevenção de conflitos no escopo pretendido.

A resposta não é proibir experimentos. É tornar a fronteira executável: enumerar sistemas participantes, filtrar vazamentos, etiquetar telemetria, definir prazo, detectar novos pares e manter plano de renumeração. Quando a necessidade passa a ser interoperabilidade ampla, deve-se buscar uma atribuição adequada.

O momento perigoso é a expansão silenciosa. Um parceiro externo é adicionado, a convenção entra em firmware, o número vai para um contrato e o “local” deixa de ter contorno. Cada integração aumenta o custo de corrigir a suposição original.

Dezesseis não era uma identidade completa

Os códigos de erro mostram por que número e significado não formam um par simples. RCODE pode envolver o cabeçalho básico e a extensão de OPT, além de contextos como TSIG ou TKEY. RFC 5395 registrou 16 como BADVERS quando se refere a versão OPT não suportada e como BADSIG para falha de assinatura TSIG.

RFC 6895 manteve a exceção e registrou outra para 9: “Not Authoritative” em um contexto e “Not Authorized” em outro. Fora dessas exceções, procurou impedir que o mesmo erro adquirisse significados diferentes apenas por aparecer em outro RR.

Uma métrica que guarda somente rcode=16 pode contar perfeitamente e diagnosticar mal. Falha de versão e falha de assinatura conduzem a proprietários, riscos e correções diferentes. A evidência precisa incluir localização do campo, record contêiner, largura efetiva, peer e especificação aplicável.

Da mesma forma, uma coluna chamada code não deve unir registros independentes. O namespace faz parte da chave. Igualdade numérica entre campos ou tabelas não cria equivalência semântica.

O bit aparentemente livre carregava memória

RFC 5395 observou que algumas implementações montavam uma resposta copiando o cabeçalho da consulta e não limpavam bits sem uso naquela direção. Um bit que voltava não era necessariamente sinal deliberado. Atribuir-lhe um novo significado de resposta poderia transformar resíduo histórico em comando válido.

O bit Z guardava história ainda mais antiga: certas implementações o interpretaram na consulta como pedido de resposta do servidor primário. Embora o documento julgasse esse comportamento abandonado, exigiu Standards Action para uma nova atribuição.

O ponto não é alegar que todo servidor atual reproduz o problema. É reconhecer que o diagrama do campo não inventaria o conjunto instalado. Teste de uma implementação é necessário e insuficiente; procedimento público é necessário e insuficiente. A decisão segura combina autoridade de coordenação com evidência de interoperabilidade real.

Running code tem prioridade como prova do que de fato acontece, não como escritura do primeiro ocupante. Se o código revela estado antigo, a política deve incorporá-lo. Se um protótipo funciona, ele ainda não cancela comportamento desconhecido em outros sistemas.

A aprovação do especialista reserva identidade, não mercado

RFC 5395 introduziu um procedimento de Expert Review específico para RRTYPE, depois simplificado por RFC 6895. O solicitante fornece um modelo completo; a IANA nomeia um especialista; a decisão deve ser explicada; modelos aprovados vão para arquivo público.

Para um TYPE de dados, a proposta precisa sobreviver como RR desconhecido sob RFC 3597. Para Meta-TYPE, o processamento deve ser opcional e o descarte seguro. Pedidos obscuros, baseados em premissas erradas do DNS, incompatíveis com essas condições ou maiores que o necessário podem ser recusados.

Esse aceite prova uma decisão dentro do procedimento. Não prova suporte de fornecedor, parser de zona, transferência, biblioteca, adoção de operador ou valor para o usuário. Da mesma forma, uma demonstração funcional não prova que um número público foi legitimamente obtido.

Separar os recibos reduz pressão indevida. O registro pode reservar identidade antes de adoção universal; o produto não pode vender a reserva como funcionalidade pronta. Especificação, implementação e resultado têm calendários próprios.

Uma tabela histórica e uma tabela viva não disputam verdade

RFC 5395 foi publicado em 2008 e substituído por RFC 6195 em 2011. RFC 6895 substituiu o segundo em 2013, simplificou processos de RRTYPE e fechou o registro de subtipos AFSDB. O retrato da IANA congelado para esta pesquisa informa atualização em 28 de agosto de 2026 e contém decisões posteriores.

Uma tabela no RFC antigo documenta o estado e a arquitetura de política de sua época. A tabela IANA mostra ações acumuladas até outra data. Ambas podem estar corretas porque respondem a tempos diferentes. Auditoria sem timestamp transforma sucessão normal em contradição.

Mesmo “a IANA diz” precisa de precisão: qual registro, qual formato e qual hora? HTML, XML, texto, cache interno e código gerado podem divergir por falha de sincronização. Compará-los e associar hash ao artefato implantado torna a decisão reproduzível.

A identidade durável é uma cadeia: RFC que estabeleceu política, sucessor que a alterou, ação registrada pela IANA e comportamento do software. Remover um elo produz, respectivamente, estado congelado, autoridade sem execução ou execução sem autoridade.

Limite da evidência

As fontes congeladas sustentam os textos e a sucessão de RFC 5395, 6195 e 6895, as regras genéricas de RFC 3597, a terminologia de RFC 8126 e o retrato capturado da IANA. Não demonstram suporte atual em produto nomeado, adoção por operador, colisão observada ou causa de incidente.

A conclusão defensável é que um número se torna utilizável em vários momentos: escolha local, atribuição autorizada, registro, preservação por infraestrutura, entendimento da aplicação e resultado. O sucesso de um estágio não deve ser promovido a sucesso da cadeia inteira.