Resumo

  • A opção 137 no DHCPv4 e a opção 51 no DHCPv6 carregam, cada uma, um único FQDN. Elas não carregam o endereço final, uma lista de preferência nem um resultado LoST.
  • O domínio segue para U-NAPTR e DNS, depois para conexão e verificação de identidade. Cada transição tem operador, relógio e falha próprios.
  • Um indicador de descoberta só é confiável quando pode ser decomposto até a mensagem DHCP, o nome recebido, a resolução feita e o serviço efetivamente contatado.

O nome chegou antes da confiança

Em uma sequência construída para auditoria, não em um incidente real, um terminal entra na rede às 08:14:00. Um DHCPACK chega às 08:14:01 com a opção 137. O parser obtém lost.access.example, confirma a estrutura dos rótulos e encontra exatamente uma raiz. Às 08:14:02, a tela registra “LoST descoberto”.

Não há, naquele instante, resposta U-NAPTR, endereço DNS, estado de validação, conexão, identidade TLS, XML LoST, versão de mapa, URI de contato, tentativa de sessão ou atendimento. A configuração entregou um nome; a observabilidade inventou o restante.

RFC 5223 permite que uma rede que opere LoST, ou conheça um terceiro que o opere, forneça um domínio ao terminal. O domínio vira entrada do mecanismo de resolução baseado em DNS. O servidor DHCP não é declarado autoridade universal de mapeamento, e o FQDN não é tratado como credencial.

Essa contenção importa. Uma descoberta bem desenhada reduz a configuração manual sem apagar a diferença entre indicação e autorização.

Um campo pequeno não deve carregar uma política enorme

No IPv4, OPTION_V4_LOST é o código 137. No IPv6, OPTION_V6_LOST é o 51. Ambas usam a codificação de nomes DNS e contêm um único domínio completo, terminado por uma raiz. O cliente pode solicitar a opção pelo mecanismo adequado de cada versão.

O valor não é IP, não é URI e não é uma lista ordenada de servidores. Também não traz uma regra universal de cache ou failover. Se uma implementação lê várias preferências onde o RFC define um nome, ela cria comportamento local que precisa ser documentado como tal.

O recibo técnico deve manter os bytes, o código, o comprimento, o FQDN decodificado e a decisão de sintaxe. Armazenar só o texto impede revisar uma aceitação permissiva; armazenar só “presente” impede detectar mudança; armazenar o IP posterior como se viesse do DHCP apaga a resolução intermediária.

O registro de um código pela IANA coordena significado entre implementações. Ele não autentica a mensagem que o transporta. Interoperabilidade não é procuração.

A configuração pertence a um vínculo de rede

RFC 2131 descreve seleção de servidor, ACK, parâmetros e concessão no DHCPv4. RFC 8415 estabelece a base atual do DHCPv6. O que esses protocolos podem comprovar é uma troca de configuração em determinado contexto.

O identificador do DHCP ajuda a apontar o participante dessa troca. RFC 3046 acrescenta dados do agente de relay que podem explicar o caminho de acesso. Nenhum deles certifica que o operador do nome LoST é o mesmo ator, que possui autoridade para qualquer jurisdição ou que mantém informação atual.

Um dispositivo que muda de Wi-Fi para rede móvel pode conservar estado de aplicação além da validade prática daquela indicação. Por isso, FQDN, interface, domínio administrativo, servidor, relay, transação, horário e lease precisam permanecer associados. A implementação também deve expor qual evento dispara nova solicitação ou invalidação.

Sem esse contexto, “fornecido pela rede” vira uma frase sem sujeito. O último valor salvo passa a governar ambientes que nunca o forneceram.

O ataque de desvio está no texto do RFC

RFC 5223 alerta que a alteração ou inserção de uma resposta DHCP pode levar o cliente a um servidor LoST controlado pelo adversário ou a um endereço inválido. RFC 5069 enquadra esse risco entre as ameaças ao encaminhamento e mapeamento de emergência.

RFC 3118 especifica autenticação e proteção contra replay para mensagens DHCP. Isso demonstra que origem, integridade e atualidade têm recibos próprios. Não demonstra implantação universal. Um relatório sério diz quais verificações rodaram nesta transação.

Mesmo uma resposta autenticada pode conter configuração equivocada. O operador de acesso pode ter legitimidade para administrar sua rede sem deter autoridade sobre o mapa de atendimento. Confirmar o autor de uma mensagem não confirma toda consequência operacional da mensagem.

A primazia do código em execução, na formulação de Heng Lu, pede evidência da decisão local: qual entrada foi consumida, que teste ocorreu e que estado resultou. Um cliente DHCP não deve falar em nome do resolvedor, do serviço LoST ou do atendente.

Resolver é uma etapa, autenticar é outra

O FQDN alimenta o procedimento associado ao RFC 5222. U-NAPTR identifica o serviço; DNS fornece alvos e endereços; o cliente escolhe e conecta. Um nome válido pode não ter registro adequado. O DNS pode falhar, o endereço pode estar inacessível e o peer pode não corresponder à identidade esperada.

RFC 8446 protege a sessão TLS. RFC 9525 trata da identidade de serviço. Criptografia não conserta uma seleção ilegítima: é possível proteger perfeitamente a conversa com o peer errado.

O registro precisa guardar consulta U-NAPTR, resposta selecionada, TTL, validação DNS quando usada, conjunto de endereços, destino escolhido e resultado da identidade TLS. Só assim “DHCP correto, identidade TLS recusada” continua sendo um diagnóstico possível.

RFC 8917 dá ao serviço de validação LoST uma etiqueta S-NAPTR distinta. O papel pode ser nomeado no processo de descoberta; a etiqueta não prova que o papel foi exercido corretamente.

Descoberta concluída ainda não é mapeamento concluído

Depois da conexão, vem a requisição LoST. A resposta pode trazer erro, aviso, redirecionamento ou mapa com fonte, versão, validade e fronteira. Nada disso estava dentro da opção DHCP.

O artigo vivo sobre RFC 5222 já cobre a etapa posterior: um mapa e uma URI não comprovam uma chamada atendida. Este texto preserva outro limite: o nome DHCP não comprova sequer o mapa futuro.

RFC 6739 reforça a proveniência na sincronização entre servidores. Uma cadeia backend assinada não autentica retroativamente a resposta DHCP nem a visão DNS do terminal. RFC 6881 mostra descoberta e mapeamento dentro de uma prática mais ampla de comunicação de emergência; conexão entre etapas não significa equivalência de provas.

Um rastro que permite localizar a quebra

O mínimo é registrar: vínculo de rede; transação DHCP; servidor e relay; proteção verificada; opção e FQDN; lease e invalidação; U-NAPTR; DNS; identidade TLS; troca LoST; adequação do mapa; sinalização; aceitação e resultado.

Uma falha posterior não apaga um recibo anterior, mas também não pode ser escondida dentro dele. “Nome recebido, nenhum serviço U-NAPTR” informa mais que “descoberta falhou” e muito mais que uma luz verde indevida.

Fontes

  1. RFC 5223
  2. RFC 5223 no IETF Datatracker
  3. Situação do RFC 5223
  4. Histórico do RFC 5223
  5. Errata do RFC 5223
  6. RFC 2131
  7. RFC 2132
  8. RFC 8415
  9. RFC 3118
  10. RFC 3046
  11. RFC 5222
  12. RFC 5069
  13. RFC 6881
  14. RFC 8917
  15. RFC 6739
  16. RFC 8446
  17. RFC 9525
  18. Heng Lu — primazia do código em execução
  19. Heng Lu — especificação inicial mínima e adoção voluntária