Resumo

  • A RFC 8901 é um documento Informativo de consenso do IETF, não uma norma obrigatória nem prova de que um provedor específico implemente DNSSEC com múltiplos signatários.
  • Nos dois modelos, o RRset DNSKEY de cada provedor contém os ZSK ativos de todos os participantes. Sem isso, um resolvedor pode guardar as chaves de A, receber a assinatura de B no failover e rejeitar a resposta.
  • O proprietário da zona coordena troca de chaves, relação KSK–DS no pai, algoritmos comuns e cronograma de rotação antes da falha. O segundo fornecedor continua sendo apenas um caminho potencial até existir essa prova.

A resposta veio; a cadeia, não

Uma zona usa dois provedores independentes. Um resolvedor validador segue a delegação segura, obtém de A o RRset DNSKEY, autentica-o por meio do DS no pai e o mantém em cache. Enquanto esse estado ainda é válido, A fica indisponível. O resolvedor escolhe B, que devolve o registro pedido com uma RRSIG feita por seu próprio ZSK.

B está funcionando, mas sua resposta pode ser inútil. Se o conjunto guardado de A não contém o ZSK ativo de B, não há chave pública autenticada para verificar a assinatura. O resolvedor pode tentar outro servidor, pagar mais latência ou desistir antes do cliente. A RFC 8901 não muda esse comportamento; ela define o estado comum que os signatários precisam preparar para a validação normal atravessar a troca de caminho.

Redes distintas, contratos distintos e vários NS demonstram rotas possíveis. Não provam que uma assinatura de B seja verificável com a visão recebida de A. A redundância só se completa quando o caminho criptográfico também sobrevive.

Dois modelos de custódia, um invariante

No Modelo 1, o proprietário guarda um KSK comum e administra o DS do pai. Cada provedor mantém seu próprio ZSK. O proprietário recolhe todos os ZSK públicos, monta um RRset DNSKEY combinado, assina-o com o KSK e o distribui. Mesmo sem mudança de chaves, renova a assinatura do conjunto antes do vencimento.

O pai tem uma entrada comum e todos servem o mesmo objeto assinado. Em compensação, custódia do KSK, reassinatura periódica, acesso às APIs e distribuição tornam-se uma superfície crítica. Uma cópia antiga em um provedor divide a realidade.

No Modelo 2, cada provedor tem KSK e ZSK próprios. Cada um importa os ZSK públicos dos demais e assina o RRset com seu KSK. O pai publica um DS para cada KSK. A custódia privada fica distribuída, mas aumenta o estado público compartilhado: a rotação do KSK de A muda seu caminho no pai; a rotação do ZSK de A muda o DNSKEY que B precisa publicar.

Rotação é uma transação distribuída

No Modelo 1, A não começa a assinar imediatamente com um ZSK novo. O proprietário o obtém, acrescenta ao conjunto combinado, assina e distribui a todos. A ativação espera propagação e TTL do DNSKEY; a retirada espera até que dados e caches não dependam mais da chave antiga. A troca do KSK também cruza o DS do pai.

No Modelo 2, A pode assinar seu DNSKEY, mas entrega o novo ZSK ao proprietário para importação em B. Só o usa em dados comuns depois da importação, da propagação em todas as autoridades e do TTL. A retirada percorre a mesma coordenação ao contrário.

“Chave criada”, “API 200” ou uma consulta correta não são recibos de continuidade. O registro defensável encadeia exportação, aceitação, importação em cada provedor, publicação em cada superfície autoritativa, passagem dos TTL, validação independente com respostas de A e B e, por fim, ativação ou retirada.

Algoritmos e respostas negativas

Os participantes usam um algoritmo de assinatura comum ou o mesmo conjunto. Quando DNSKEY anuncia vários algoritmos, as regras da RFC 4035 alcançam os RRsets da zona. Escolhas incompatíveis não se complementam só porque pertencem a empresas diferentes.

Provas NSEC ou NSEC3 acompanham a resposta negativa, permitindo alguma diversidade. Mas misturar NSEC com NSEC3 desfaz a proteção do NSEC3 contra enumeração simples; configurações permanentemente diferentes também podem reduzir a eficiência do cache negativo. A RFC 8901 prefere um método e recomenda limitar diferenças inevitáveis.

Testar apenas A ou AAAA do site deixa esse plano sem cobertura. Uma resposta positiva pode validar enquanto uma ausência de nome ou tipo revela outra assinatura, prova e memória de cache.

O que a RFC não demonstra

A RFC 8901 é Informativa. Ela não prova suporte de API, implantação, falha medida, ganho de disponibilidade nem adoção. A validação DNSSEC também não prova autorização comercial, saúde da aplicação ou troca de tráfego; prova uma relação criptográfica limitada nos dados observados.

A conclusão é estreita: comprar um segundo provedor reduz uma dependência apenas quando o proprietário consegue reproduzir, antes do incidente, a visão conjunta de chaves, os DS, os algoritmos e a linha do tempo da rotação.

Fontes