Resumo

  • A revisão 01 de um Internet-Draft individual registra duas atribuições concluídas por Expert Review em 20 de agosto de 2026: UNECE ficou com o tipo DNS 69 e ISO com o 70. Os números já constam do registro da IANA, mas o texto não é RFC nem documento adotado pelo DNSOP.
  • O RDATA preserva literalmente o código mantido fora da IANA e omite ano de edição, emenda e correção. O rascunho orienta a leitura histórica pela versão externa vigente no início do RRSIG; a assinatura não carrega o identificador nem o resumo criptográfico dessa versão.

As linhas 69 e 70 do DNS Parameters da IANA agora têm nomes: UNECE e ISO. Ambas trazem a data de 20 de agosto de 2026 e apontam para solicitações separadas de Expert Review. A atribuição do espaço numérico, portanto, não é uma intenção futura.

O documento que explica o uso continua sendo trabalho em andamento.

A revisão 01 foi enviada em 9 de setembro. Seu apêndice e o diff oficial dizem que a única mudança diante da revisão 00 é registrar os dois valores e a conclusão da análise em 20 de agosto. A página no Datatracker, o histórico e a entrada da API ainda descrevem um Internet-Draft individual ativo, sem número de RFC, stream ou Area Director responsável.

O cabeçalho fala em Standards Track, não em consenso obtido. RFC 6895 submete RRTYPEs a Expert Review; RFC 8126 explica o papel dos especialistas designados. É possível reservar um tipo após avaliação técnica sem antecipar o destino institucional de toda a especificação.

Um tipo central, um significado externo

O desenho evita uma cópia IANA das listas UNECE e ISO. O tipo identifica a organização mantenedora; um discriminator escolhe a recomendação ou norma; o campo Code leva os octetos publicados. O emissor não pode criar código próprio. Um receptor que não conhece o discriminator ou o code deve mantê-lo e mostrá-lo sem interpretação, em vez de invalidar o RR.

Os formulários de UNECE e ISO mostram a escolha. Convenções em TXT perdem estrutura e interoperabilidade; espelhar a lista produziria um segundo polo de autoridade. A fonte continua nas recomendações UNECE e nos mecanismos de ISO 3166. RFC 6116 oferece o precedente do ENUM usando atribuições E.164 administradas externamente.

Essa contenção institucional é valiosa. Mas a aplicação passa a depender da disponibilidade e do histórico de um objeto que não está no DNS.

Compatibilidade não é identidade de edição

Os tokens de recomendação e norma deixam de fora anos, emendas e correções. ISO 3166-1 e UNECE 20 continuam iguais no fio mesmo quando suas listas mudam. O protocolo permanece estável e não exige nova ação da IANA a cada revisão externa.

As regras de retirada, porém, variam. O rascunho afirma que a UNECE mantém códigos excluídos ou desaconselhados visíveis; ISO 4217 conserva moedas históricas e datas de retirada; ISO 639 não reutiliza identificadores aposentados; ISO 3166 aplica uma reserva, embora já tenha havido reatribuição. O software precisa saber qual desses regimes acompanha o código.

A lista só pode ser usada na publicação se estiver ativa, for citável e estiver disponível gratuitamente. Futuras especificações que seguirem o padrão devem documentar aposentadoria e reuso. Esses controles não dizem qual cópia foi aberta no momento da interpretação.

O inception do RRSIG marca tempo, não edição

Para precisão histórica, o texto recomenda interpretar o código com a revisão externa vigente no instante de início do RRSIG que cobre o RRset. Isso oferece um ponto temporal. Não oferece uma referência completa.

RFC 4034 define Signature Inception como o primeiro momento em que o RRSIG pode autenticar o conjunto. A assinatura traz expiração, algoritmo, key tag, signatário e valor criptográfico, mas não traz edição UNECE, release ISO, URL externa ou digest da lista. RFC 9364 enquadra DNSSEC como autenticação de origem e integridade dos dados DNS, não como arquivo de padrões externos.

Uma zona pode assinar novamente o mesmo RDATA, mudando o início sem mudar a declaração. Uma lista externa pode ser revisada enquanto uma assinatura anterior continua válida. Para ligar hora a significado, o receptor ainda precisa de um arquivo recuperável e de uma regra sobre retirada.

Não há evidência aqui de erro ou incidente. O limite é probatório: validar os octetos e identificar a edição externa consultada são operações diferentes.

Emitir um comprovante de resolução

Minha proposta é um comprovante local de resolução do registro externo. Ele liga RRTYPE, discriminator, value e code brutos; mantenedor externo; edição exata ou URL, horário e digest do conteúdo; início, expiração, signatário e resultado do RRSIG; regra de retirada ou reatribuição usada; saída para código desconhecido; versão da política do emissor; e decisão local que consumiu aquela interpretação.

O comprovante não certifica a organização externa e não autoriza a decisão. Ele registra o caminho. Se a página mudar, ainda se sabe qual material foi usado. Se o mesmo RRset for assinado de novo, sua história semântica não se desloca silenciosamente. Se duas aplicações discordarem, a diferença pode ser localizada.

A proposta segue a Minimum Initial Specification de Heng Lu: tornar determinística apenas a fronteira necessária e manter política e implementação locais. The Policy Mirror acrescenta a reconstrução entre regra, autoridade e resultado. Este comprovante é análise editorial, não requisito do rascunho.

Os tipos 69 e 70 preservam a autoridade externa. O uso responsável preserva também a edição externa que produziu o significado adotado.

Fontes