Resumo

  • RFC 8005 permite que um RR HIP publique a identidade pública HI, seu HIT e nomes opcionais de RVS. É uma peça de descoberta, não uma sonda de vida.
  • DNSSEC protege os dados DNS no âmbito da cadeia de validação; o TTL delimita a reutilização do cache. Eles não observam a associação HIT-endereço no RVS nem a chave privada em uso.
  • Uma conclusão operacional liga o RR escolhido ao endereço do RVS, registro corrente, relé de I1, autenticação baseada na HI, conclusão da associação e resultado da aplicação.

Um verde tecnicamente correto e operacionalmente falso

Às 9h, o resolvedor recebe o RR HIP de um nó móvel. HI, HIT e nome do RVS são os esperados, DNSSEC valida e o TTL é de uma hora. A tela converte tudo em uma frase: “identidade verificada e destino alcançável”.

Doze minutos depois, o nó troca de rede. A atualização de endereço para o RVS se perde. Nada obriga o DNS a mudar: o ponto de encontro publicado continua sendo o mesmo nome. Às 9h20, I1 chega ao RVS, que consulta uma associação antiga e encaminha para o endereço anterior.

O cenário é construído e não relata um incidente real. A resposta DNS permaneceu verdadeira dentro da pergunta que pode responder. Quem errou foi a camada de garantia, ao transformar validade da publicação em observação do caminho.

Informação pública não demonstra posse presente

RFC 5205 definiu o RR tipo 55 em 2008, como Experimental. RFC 8005 o substituiu em 2016 na Standards Track. O registro carrega a Host Identity pública, o HIT derivado dela e, quando necessário, domínios de rendezvous.

A HI prepara a autenticação posterior. O HIT oferece um identificador compacto. Nenhum deles contém a chave privada, nem prova que o equipamento consegue usá-la no instante da consulta.

RFC 8005 orienta o endpoint a não autenticar um par somente com o HIT recuperado do DNS. Deve usar autenticação baseada na HI. Encontrar o identificador publicado e verificar o uso da chave em uma troca atual são eventos diferentes.

Se o inventário marca authenticated=true assim que resolve o HIT, ele elimina a etapa que deveria produzir a prova. A chave pode ter sido retirada ou estar indisponível enquanto os dados públicos seguem válidos.

DNSSEC protege bytes, não o sistema inteiro

Sem um canal seguro, alguém pode trocar a HI ou redirecionar I1 alterando o RR. O documento recomenda integridade e autenticidade dos dados e aponta DNSSEC para esse papel.

Mas ele restringe expressamente a interpretação: a garantia vai do servidor que publica a zona ao nó HIP. Não garante que a entidade publicadora seja confiável. A RRSIG do conjunto HIP não deve ser tratada como certificado que vincula HI ou HIT ao nome proprietário.

O estado secure é, portanto, uma evidência forte com assunto estreito. Ele precisa de âncora, algoritmos, tempo, política e conjunto assinado. Não conhece o armazenamento da chave, a tabela do RVS, a rota IP ou o processo que atende a aplicação.

Uma assinatura perfeita não acrescenta fatos à declaração. Quando essa fronteira é ignorada, uma falha de mobilidade faz a equipe investigar DNSSEC, embora DNSSEC tenha funcionado.

TTL mede reutilização de cache

RFC 8005 determina que, ultrapassado o TTL desde a obtenção, o registro deve ser considerado inválido e eliminado; se ainda for necessário, uma nova consulta deve buscar cópia atualizada.

Esse relógio pertence ao cache. Ele não reserva uma entrada de rendezvous, não congela o localizador e não obriga o endpoint a manter a chave disponível. Quarenta minutos restantes significam apenas que a publicação ainda pode ser reutilizada segundo a política DNS.

Até a nova consulta pode devolver o mesmo RR assinado enquanto a associação dinâmica permanece errada. Atualizar uma camada não renova as demais.

O risco de automação nasce da facilidade do cálculo. cacheAge < ttl pode autorizar o consumo da informação DNS; não autoriza preencher serviceHealthy=true. Para isso é preciso observar o serviço.

Nome de RVS e estado do RVS são autoridades distintas

O desenho de mobilidade publica nomes relativamente estáveis em DNS e mantém separadamente o RVS informado sobre os endereços atuais. RFC 8004 mostra o servidor consultando registros correntes antes de encaminhar I1.

Assim, o nome pode resolver e o servidor pode responder, mas o HIT pode não ter entrada vigente. Uma entrada pode ter expirado, sobrevivido com localizador antigo ou desaparecido após reinício. Mesmo um relé registrado não prova recepção pelo endpoint.

O encadeamento correto é:

RR publicado → DNSSEC validado → TTL vigente → RVS escolhido → registro atual → I1 encaminhado → HI autenticada → associação concluída → resultado observado.

Cada seta atravessa uma fonte. Ausência de recibo deve produzir “desconhecido”, não herdar a cor da etapa anterior.

Vários registros exigem preservar a unidade

Um nome pode possuir múltiplos RR HIP. A política de escolha fica fora do escopo, e os RVS podem variar. Quando existem alternativas, o host deve confirmar que o RVS usado pertence à HI escolhida.

Separar todas as HIs em uma lista e todos os RVS em outra cria combinações que a zona nunca publicou. Durante rotação, registros antigos e novos coexistem; uma projeção sem proveniência pode juntar a chave nova ao caminho antigo.

O recibo deve manter algoritmo, HI, HIT, RVS, TTL, impressão da resposta e razão da seleção por RR. Só assim uma falha pode ser atribuída ao dado realmente consumido.

O recibo de alcance

Registrar nome consultado, resolvedor, autoridade, horário e impressão do pacote; conservar o RRset com associações; anotar resultado DNSSEC, âncora e política; guardar obtenção, idade, TTL e reconsulta. Os A/AAAA do RVS possuem seus próprios relógios e validações.

No plano operacional, associar ID do registro, HIT, localizadores, atualização, expiração, cancelamento e geração de configuração. Ligar envio de I1, chegada ao RVS, busca, relé e recepção. Depois vêm transcrição HIP, HI selecionada, assinatura, estado nos dois pares e, separadamente, dados úteis e resultado da aplicação.

RFC 8005 adicionou ECDSA, esclareceu reconsulta, registros múltiplos e formato de vários RVS. A publicação do RFC não demonstra migração do código. Versão, build, configuração e tráfego permanecem necessários.

Limitar o RR à descoberta não reduz seu valor. Uma interface honesta diria: “RR seguro; TTL atual; registro RVS não confirmado; alcance desconhecido”. A frase aponta para a atualização perdida, sem culpar a zona que cumpriu sua função.

Fontes