Resumo

  • A documentação pública Delegation Key de ARIN apresenta o tipo de resumo 3 como MD5, com comprimento 32. IANA atribui o tipo DS 3 a GOST R34.11-94, atualmente obsoleto.
  • A coluna de comprimento não informa a unidade. Os 256 bits de GOST correspondem a 32 octetos ou 64 caracteres hexadecimais. Essa diferença não demonstra os limites efetivamente impostos pela API.
  • As quatro recomendações atuais de IANA indicam MUST NOT para o tipo 3, em consonância com o RFC 9906. Acertar o nome não significa recomendar seu uso. Não houve testes de API, zonas, assinadores ou resolvedores.

O que uma linha permite concluir

Antes de discutir segurança operacional, vale identificar o objeto observado. Neste caso, é uma linha de referência pública: na seção Delegation Key dos formatos Reg-RWS, ARIN associa o número 3 ao nome MD5. Na tabela de tipos de resumo DS de IANA, o mesmo número significa GOST R34.11-94. Não são duas grafias da mesma função nem uma escolha de tradução.

O material foi capturado em 14 de setembro de 2026. A data situa a observação, não a origem da linha. Não foi estabelecido quando o nome foi introduzido ou por quanto tempo permaneceu. Tampouco se pode deduzir a história de revisão da página a partir da presença de algoritmos mais novos em outras partes de seu catálogo.

O registro DS combina um identificador de tipo com os dados do resumo. O identificador informa qual função aqueles dados representam. Um nome amigável ajuda alguém a interpretar o número, mas não redefine seu significado no protocolo. A atribuição registrada não muda porque a documentação de uma interface usa outra etiqueta para o campo.

Isso sustenta uma consequência condicional: se um desenvolvedor calculasse MD5 seguindo o nome publicado e vinculasse o resultado ao tipo 3, poderia produzir uma combinação incompatível com a função atribuída. Não foi observado nenhum cliente ou envio que seguisse esse caminho. O fato comprovado é a divergência entre duas descrições públicas do identificador.

É importante não trocar esse fato por uma afirmação maior. Não foi acessada uma conta privada de ARIN, não se utilizou chave de API e não se enviou ou alterou material DS. Não se demonstrou que o serviço aceita MD5 sob esse número, que armazena dados dessa forma ou que os publica no DNS. A descrição da interface não é um recibo de execução.

Dois campos, duas famílias de números

A referência coloca Delegation Key dentro de Delegation Payload e apresenta tanto algorithm quanto digestType. O primeiro diz respeito ao algoritmo de DNSKEY. O segundo identifica a função de resumo DS. Os números podem aparecer no mesmo documento de entrada sem fazer parte da mesma tabela de atribuição. A vizinhança dos campos não elimina a diferença.

O catálogo de algoritmos inclui valores como 5, 7, 8, 10, 13, 14, 15 e 16, acompanhados por nomes de RSA, ECDSA e EdDSA. A tabela de resumos contém SHA1 para 1, SHA256 para 2, MD5 para 3 e SHA384 para 4. Seus comprimentos são 40, 64, 32 e 96. Essa enumeração relata o texto publicado, não uma lista de aceitação validada no ambiente de produção.

ARIN explica que os nomes de algoritmo e de tipo de resumo são determinados pelos valores numéricos inseridos, descartando os nomes fornecidos. Na interface assim descrita, digitar outro nome não substituiria a atribuição do número. Isso torna a correspondência publicada ainda mais relevante para o leitor que procura entender o campo selecionado.

Mas a regra descrita não revela qual nome a versão em operação devolve, qual verificação realiza primeiro, que erro produz ou em que formato guarda o resultado. Essas perguntas precisam de evidência própria do serviço, com data e condições de execução. Não foram respondidas por esta investigação. A documentação pode estar errada sem que todas as etapas da implementação repitam seu erro.

O RFC 5933 deixa explícita a separação de espaços numéricos: 12 foi atribuído ao algoritmo de assinatura DNSKEY ECC-GOST, enquanto 3 foi atribuído ao resumo DS GOST R34.11-94. Um tipo DS 3 não é um algoritmo DNSKEY 3. Também não é o valor 3 do campo de protocolo DNSKEY, nem uma etiqueta de chave que contenha esse algarismo.

A função não define sozinha a entrada

O RFC 4034 descreve o tipo de resumo DS como o identificador do algoritmo empregado em sua construção. Também especifica o material de entrada: o nome canônico do proprietário de DNSKEY seguido pelos dados do registro DNSKEY, que incluem indicadores, protocolo, algoritmo e chave pública. Não basta descrevê-lo como um resumo de qualquer cadeia de chave visível numa tela.

Escolher a função, reunir a entrada e representar o resultado são tarefas distintas. Corrigir um rótulo não comprova que as outras duas estão corretas. Da mesma forma, uma entrada adequada não esclarece automaticamente a unidade usada numa coluna de comprimento. Uma referência útil precisa ajudar o leitor a manter essas distinções, em vez de exigir que ele adivinhe regras a partir de campos vizinhos.

A atribuição original no RFC 5933 e a tabela atual de IANA concordam sobre GOST. O status obsoleto não libera o número para uma nova interpretação como MD5. Uma tabela pode continuar identificando um código histórico e, ao mesmo tempo, recomendar que não seja usado. Descrever algo encontrado em configuração antiga não é aprovar a geração de novo material.

O argumento não é que MD5 nunca apareça em qualquer protocolo relacionado ao DNS ou em outro contexto tecnológico. Essa seria uma tese diferente, com exigências próprias de pesquisa. A conclusão é localizada: MD5 não é a função atribuída ao tipo de resumo DS 3. Essa delimitação torna a correção solicitada precisa e verificável.

Comprimento sem unidade não é limite comprovado

O nome incorreto pode ser comparado diretamente. Já o número 32 na coluna Digest Length exige cautela. ARIN não informa a unidade dessa coluna. As entradas vizinhas 40, 64 e 96 são compatíveis com quantidades de caracteres hexadecimais. A sequência sugere uma leitura, mas não demonstra que a API impõe essa quantidade de caracteres como limite.

O RFC 5933 especifica um resumo GOST de 256 bits. Isso equivale a 32 octetos; representado em hexadecimal, equivale a 64 caracteres, pois cada octeto ocupa dois. O RFC 4034 descreve o resumo DS como hexadecimal sem distinção entre maiúsculas e minúsculas e permite espaços. A extensão de um texto formatado não deve ser confundida com o tamanho dos dados subjacentes.

Se a intenção da coluna é contar caracteres hexadecimais, 32 não descreve o GOST atribuído ao tipo 3. Se a intenção é contar octetos, a cifra serve para GOST, mas as linhas vizinhas precisam de outra explicação. A página não permite escolher entre essas hipóteses. Uma correção deveria explicitar a unidade e o tratamento de espaços, não transformar uma inferência em regra oculta.

Não se provou, portanto, que o serviço rejeita uma entrada de 64 caracteres ou aceita uma de 32. Decodificação, normalização, sequência de validação, mensagens de erro e armazenamento não foram examinados em execução. Seria possível investigar esses pontos separadamente em condições autorizadas. Eles não estão resolvidos pela comparação do comprimento publicado.

Um mesmo documento pode reunir nome errado e unidade ambígua sem que isso revele toda a implementação. Outras combinações também são possíveis. A evidência atual não escolhe uma delas. Separar os problemas ajuda a direcionar eventual trabalho adicional ao que continua desconhecido, sem repetir a demonstração de que a etiqueta pública diverge da atribuição.

GOST correto no nome, proibido na recomendação

Substituir MD5 por GOST consertaria a identidade do código, mas não faria do tipo 3 uma opção recomendada para uma nova delegação. O RFC 9906, publicado em novembro de 2025, retirou ECC-GOST e GOST R34.11-94 do uso em DNSSEC. A tabela atual de IANA reflete essa decisão.

As quatro colunas dizem MUST NOT: uso em delegação, uso em validação, implementação para delegação e implementação para validação. A descrição histórica de implementação opcional no RFC 5933 explica o estado anterior. Ela não prevalece sobre a retirada posterior. Citar um MAY antigo como recomendação atual de validação criaria outro erro, agora de tempo, durante a correção do primeiro.

É possível que um catálogo descreva identificadores encontrados ao inspecionar, editar ou remover configurações antigas. Isso é diferente de recomendar sua criação. Não se testou aqui uma função específica de compatibilidade ou remoção oferecida por ARIN. A distinção é sobre o papel da descrição, não uma certificação de capacidade real da interface.

O RFC 9906 também diferencia a condição de uma cadeia dependente apenas dos algoritmos retirados. Sem outro caminho aceitável de autenticação, o tratamento prescrito é insecure, em vez de validar com esses algoritmos e classificá-la como bogus. Nenhum desses termos significa simplesmente que o nome está inacessível. Não houve medição desse estado em qualquer zona de ARIN.

Neste artigo, a retirada é um limite à reparação proposta, não a tese principal. O centro da investigação é a correspondência de um campo de provisionamento que aponta para a função errada. A orientação vigente impede que a correção do nome seja interpretada como um convite a implantar GOST. Identificação histórica e escolha operacional precisam permanecer separadas.

O pai não é todo o DNS

O guia de DNS reverso de ARIN fornece o contexto operacional. Depois de proteger a zona reversa, o operador pode sinalizar dados DS ao pai e administrá-los por delegação por meio de ARIN Online ou do serviço RESTful de provisionamento. O campo discutido está numa fronteira concreta entre material da zona filha e sua descrição do lado pai.

Gerenciar DS no pai não é assinar a zona filha, publicar todos os seus DNSKEY ou controlar os resolvedores que poderão verificar a cadeia. Um nome errado pode influenciar uma interpretação local sem atravessar todas essas fronteiras até uma resposta pública. As páginas não fornecem a história de cada envio ou o estado final das delegações.

A solicitação proporcional é reconciliar a tabela com a atribuição, declarar a unidade e distinguir o status retirado do tratamento do serviço. Se este último for contestado, ele precisa de evidência datada e reproduzível própria. A comparação não recomenda excluir DS existentes por precaução, não oferece procedimento seguro de troca de chaves e não fundamenta novos poderes sobre recursos numéricos.

Fontes

  • Referência Reg-RWS de ARIN: campos Delegation Key, nomes derivados de números e tabela de tipos e comprimentos.
  • Registro IANA dos tipos de resumo DS: atribuição do tipo 3 e recomendações atuais.
  • RFC 5933: números separados de GOST e resumo de 256 bits; recomendações originais são históricas.
  • RFC 9906: retirada de novembro de 2025 e tratamento de validação prescrito.
  • Guia de DNS reverso de ARIN: contexto de DS no pai, não evidência sobre uma zona específica.
  • RFC 4034: campos DS, entrada do cálculo e apresentação hexadecimal, não orientação atual para selecionar algoritmos.