Resumo

  • Para a RFC 3008, uma assinatura de dados só se tornava evidência material de DNSSEC depois de passar pelos campos exigidos e corresponder a uma chave de zona; o cálculo correto era insuficiente.
  • Chaves de host e usuário ainda autenticavam transações SIG(0), mas a chave de zona assinava o estado público, mantendo separadas a identidade de quem pede uma mudança e a autoridade que atesta a zona.

Uma assinatura podia estar matematicamente perfeita e, ainda assim, não valer como voz da zona. A chave existia, os bytes não haviam mudado e a operação fechava. Faltava o mandato. Publicada em novembro de 2000, a RFC 3008 colocou essa diferença no caminho normal de um resolvedor DNSSEC.

O texto chamou algumas assinaturas de materiais e outras de imateriais. Uma data SIG cobria normalmente um RRset e podia participar da validação. Outra assinatura poderia servir a uma aplicação, não estar vinculada a conjunto algum ou proteger a mensagem inteira como SIG(0). Imaterial não significava falsa; significava que o objeto não ocupava um lugar na cadeia pública usada para aceitar dados da zona.

A mudança restringiu a arquitetura da RFC 2535. O modelo anterior aceitava, em certos casos, que chaves de zona, host e usuário assinassem dados. Na atualização dinâmica, isso parecia oferecer uma vantagem: o host assinaria o que acrescentava, enquanto a chave privada mais sensível da zona ficaria fora de linha.

O restante do mecanismo impedia esse isolamento completo. Atualizações em uma zona segura também exigiam novas assinaturas dos conjuntos SOA e NXT. O processo da RFC 3007 já precisava de capacidade de assinatura de zona online. Se essa chave tinha de estar presente e podia assinar os dados admitidos, reconhecer a assinatura do host como evidência pública não eliminava a exposição. Apenas obrigava cada resolvedor a interpretar uma rede mais complexa de autorizadores.

A RFC 3008 preferiu um padrão mais estreito: dados de uma zona segura deveriam ser assinados por uma chave de zona. Salvo política local explícita, o resolvedor ignoraria chaves de outros tipos ao avaliar uma data SIG material. Havia menos flexibilidade, mas o comprimento da cadeia ficava limitado pela profundidade dos rótulos do nome, e a autoridade acompanhava a estrutura visível das zonas.

O rótulo zone não substituía as demais verificações. Type covered precisava coincidir com o tipo do RRset. O algoritmo tinha de ser reconhecido e possuir um formato SIG definido. O número de labels não podia superar o nome proprietário da assinatura. Original TTL tinha de ser pelo menos igual ao TTL atual da SIG, pois um servidor intermediário não pode aumentá-lo. O relógio deveria estar entre inception e expiration.

Signer name, key tag e algoritmo então localizavam uma KEY candidata. Sem correspondência, a assinatura era imaterial. Havendo várias chaves com os mesmos seletores, todas permaneciam candidatas até a verificação matemática indicar qual delas produziu a assinatura. O resolvedor não podia usar um resultado bem-sucedido para inventar depois a função institucional da chave.

A própria KEY tinha limites. Seus type flags precisavam permitir autenticação. Para uma assinatura material de dados, name type tinha de ser zone. O campo protocol deveria anunciar DNSSEC ou ALL. O algoritmo da KEY precisava ser o mesmo da SIG. Assim, a mesma matéria pública poderia executar corretamente o cálculo e, ainda assim, estar declarada para outro protocolo ou ator.

Cada etapa emitia um recibo diferente. A criptografia ligava chave, assinatura e entrada. A elegibilidade confirmava a forma. O tipo de chave atribuía autoridade sobre aquela classe de objeto. A cadeia ligava a zona a um ponto de confiança. O intervalo delimitava a validade. Mesmo juntas, essas provas não garantiam que o serviço indicado por um endereço estivesse funcionando nem que o conteúdo fosse verdadeiro fora da afirmação DNS assinada.

SIG(0) permaneceu em outra trilha. Quando type covered era zero, a SIG protegia uma solicitação ou transação, segundo a RFC 2931. Como uma pessoa ou host inicia a operação, user ou host/entity eram os tipos esperados. Até um servidor de nomes assinava ali como host, não como uma zona. Por isso, chaves de zona normalmente não deveriam gerar SIG(0).

Isso não retirava utilidade da chave de host; definia o objeto de sua prova. Ela podia autenticar o principal que enviou a atualização. Depois, o primário aplicava a política local da RFC 3007, limitando nomes, tipos e operações e negando alterações por padrão. Se aceitasse o pedido, a chave de zona assinava o estado público. Propor, admitir e atestar eram poderes separados.

O resolvedor também deixava de precisar da política privada do primário. Não era necessário reconstruir qual cliente recebera permissão para escrever cada RR. A zona publicada seguia uma regra comum. O operador poderia alterar seu controle de acesso sem mudar o protocolo ou exigir que todos os resolvedores entendessem uma nova representação de política.

O antigo campo signatory de KEY não assumiu essa função. A RFC 3008 não lhe atribuiu valores nem exigiu sua presença. Alguns bits poderiam parecer um modo portátil de representar autoridade, mas prenderiam políticas futuras a uma enumeração fixa e misturariam admissão de atualização com validação pública. A arquitetura preferiu política local no ponto de escrita e regra de chave de zona no ponto de leitura.

O modelo continuava histórico e transitório. A RFC 3090 esclareceu o status seguro de uma zona naquele sistema. A RFC 3658 acrescentou o registro DS e alterou o elo entre delegações. As RFCs 4033, 4034 e 4035 acabaram substituindo a geração KEY/SIG das RFCs 2535 e 3008.

Logo, a RFC 3008 não é manual de configuração atual, e seus flags não devem ser traduzidos sem ressalva para DNSKEY e RRSIG. O relatório RFC 3130 registrou em 2001 que DNSSEC era visto como uma caixa de ferramentas cujas partes evoluíam em ritmos diferentes. Isso prova uma fase de projeto, não implantação universal nem benefício medido causado por um único documento.

O legado é a ordem da decisão. Uma prova não leva consigo todo o mandato. O código do resolvedor precisa juntar função do signatário, objeto coberto, uso declarado, tempo e caminho de confiança. Caso contrário, a precisão matemática transforma posse de chave em uma autoridade pública que a arquitetura nunca concedeu.

Na lente Running-Code Primacy de Lu Heng, a autoridade só aparece quando o resolvedor executa a classificação inteira, e não quando encontra uma assinatura. A regra de chave de zona forma a camada comum mínima. Uma exceção local continua pertencendo ao resolvedor que a escolheu e não reescreve silenciosamente a regra de todos. Estabilidade exige recibos separados, não um único sinal verde de validade.

A RFC 3008 tornou a assinatura menos mágica e mais responsável. A operação prova controle da chave; KEY declara finalidade; a posição na zona fornece papel; a cadeia fornece procedência; o relógio fornece prazo. Só a convergência dessas provas transforma uma assinatura correta em evidência autorizada sobre aquele RRset.

Sources