Resumo

  • O RFC 5074, escrito por Sam Weiler, descreveu o DNSSEC Lookaside Validation (DLV) para validar zonas assinadas quando o domínio pai não fornecia o DS esperado.
  • DLV não dispensava confiança. O resolvedor precisava configurar antes uma âncora para outro domínio, o DLV, e só então podia usar seus registros autenticados como substitutos do DS da zona em questão.
  • A ISC retirou as entradas do registro em 2017, mas manteve uma zona assinada vazia para configurações antigas. Em 2020, o RFC 8749 levou o DLV à categoria Historic diante da expansão da delegação DNSSEC convencional e do custo de manter código extra.

Quando a zona filha não conseguia provar a delegação

Assinar uma zona não basta para que um resolvedor valide suas respostas. No caminho normal, o domínio pai publica um registro Delegation Signer (DS), que liga a DNSKEY da zona filha aos dados assinados do pai. Se algum ancestral ainda não está assinado ou se o registrador não aceita o DS da filha, a cadeia criptográfica para ali. Esse obstáculo era relevante no começo da implantação do DNSSEC, quando a raiz e muitos domínios de topo ainda não tinham assinatura.

O DLV acrescentou uma segunda porta de entrada. O RFC 5074 permite que um domínio DLV, assinado separadamente, publique registros autenticados para zonas abaixo de um ponto escolhido, mesmo que não sejam suas filhas diretas. Depois de validar o conjunto de registros DLV, o resolvedor pode tratá-lo como trataria um DS e continuar a validação das chaves e assinaturas da zona consultada. O RFC 4431 define o tipo 32769 para o registro DLV e tem Mark Andrews e Sam Weiler como coautores. Weiler escreveu o RFC 5074, que explica o comportamento esperado do validador e o mecanismo.

Essa solução mudava a origem da confiança, não a eliminava. Antes de usar o caminho alternativo, o operador precisava configurar uma âncora para o domínio DLV. O RFC 5074 orienta a tentar primeiro as âncoras convencionais aplicáveis; se a validação normal funcionar, não é necessário processar DLV. Quando vários domínios DLV cobrem a mesma zona, o padrão deixa a precedência para cada implementação e recomenda que o operador possa escolher. O mecanismo adicionava uma opção, mas deixava explícito quem precisava confiar nela.

A retirada exigiu olhar para o que continuava instalado

Segundo a ISC, seu DLV Registry começou a funcionar em 2006 como apoio temporário à adoção do DNSSEC. Conforme a raiz e as delegações dos domínios de topo passaram a ser assinadas, a rota adicional perdeu utilidade. O RFC 8749, de W. Mekking e Dan Mahoney, registra que a raiz foi assinada em julho de 2010 e que 1.389 dos 1.531 domínios de topo recebiam delegação segura da raiz em maio de 2019. Publicado em 2020, o RFC reclassificou os RFCs 4431 e 5074 como Historic.

Uma mudança de status não remove uma configuração dos resolvedores. A ISC apagou as entradas de DLV em 30 de setembro de 2017, mas deixou dlv.isc.org como uma zona assinada vazia. A organização informou que apagar também a zona poderia fazer alguns resolvedores BIND antigos ainda configurados para DLV devolverem SERVFAIL para muitas consultas. A zona vazia permitia que essas instalações desatualizadas parassem de encontrar registros DLV antigos sem transformar o encerramento em uma interrupção imediata nos casos testados pela ISC. Esse relato descreve uma configuração legada específica, não o comportamento universal de todos os resolvedores.

O RFC 8749 registra o benefício e o custo. O DLV reduzia a pressão para que os domínios pai assinassem e os registradores aceitassem DS, mas acrescentava complexidade ao código de validação. Os autores apontaram implementações em BIND 9 e Unbound e disseram não conhecer uso em empresas privadas. Isso descreve o que sabiam ao publicar, em 2020; não é um levantamento dos sistemas ativos em 2026. As fontes permitem uma conclusão mais estreita: o DLV preencheu lacunas enquanto a cadeia normal se expandia, e sua aposentadoria precisava levar em conta configurações que sobreviveram ao motivo inicial do mecanismo.

A Nota 64 de Heng Lu entra somente como lente editorial: ajuda a perguntar se o mecanismo comum ficou restrito ao necessário e se a mudança foi julgada pela adoção em operação. Ela não é evidência sobre Weiler nem sobre DNSSEC.

Fontes