Resumo

  • O RFC 3397 atribuiu o código DHCP 119 a uma lista ordenada de domínios de pesquisa. O cliente primeiro juntava fragmentos segundo o RFC 3396 e só depois seguia ponteiros de compressão do RFC 1035 no agregado completo.
  • A lista agia antes do DNSSEC. Um sufixo hostil, se aceito, podia construir outro nome completo cujos registros fossem legitimamente assinados: uma resposta autêntica para uma pergunta diferente da intenção do usuário.

Um nome curto era uma solicitação incompleta. Ao digitar myhost, a pessoa não transmitia na própria palavra o domínio administrativo esperado. Entre a entrada e o pacote DNS, o resolvedor precisava escolher um sufixo e produzir um nome completo. O RFC 3397 padronizou como o DHCP podia fornecer essa lista de escolhas.

Publicado em novembro de 2002 na trilha de padrões, o documento definiu a opção Domain Search, código 119. Sua competência era exclusivamente DNS. Ele não ordenava mecanismos distintos de resolução de nomes; essa era a função da opção do RFC 2937. A opção 119 dizia quais domínios acrescentar a nomes incompletos dentro do DNS.

O valor economizava espaço usando a própria representação de nomes do RFC 1035. Searchstring concatenava domínios em etiquetas e permitia substituir um nome inteiro ou um sufixo repetido por um ponteiro de dois octetos. Assim, duas entradas terminadas em apple.com. não precisavam duplicar todos esses octetos.

O deslocamento do ponteiro começava no primeiro octeto dos dados da opção, sem incluir código nem comprimento. Era uma referência local ao objeto lógico, não uma consulta externa, endereço de rede ou salto para outro pacote. Essa precisão era essencial porque o objeto podia chegar dividido.

O RFC 3397 incorporou a regra do RFC 3396. Quando várias instâncias da opção 119 transportavam partes do valor, o receptor precisava concatenar todos os dados antes de interpretar nomes. Os ponteiros operavam sobre esse agregado e podiam atravessar uma fronteira física entre fragmentos. Examinar cada ocorrência como uma lista independente mudaria o sistema de coordenadas.

No exemplo, eng.apple.com. e marketing.apple.com. ocupavam três instâncias. O segundo domínio terminava em C004, referência ao deslocamento quatro do bloco agregado, onde começava apple.com.. O exemplo não era apenas uma demonstração de compactação: ele estabelecia que reconstrução DHCP precedia descompressão DNS.

Também havia uma regra contra adivinhação. Cada nome precisava terminar na etiqueta raiz de tamanho zero ou em um ponteiro válido de dois octetos. Se os dados acabassem no meio de um domínio, a entrada parcial seria descartada. Receber quase todo o nome não autorizava o cliente a completar o restante.

Depois da decodificação vinha a política de busca. Com base nos alertas dos RFCs 1535 e 1536, o RFC 3397 recomendava listas explícitas, sem inferi-las do nome da máquina. Uma entrada com ponto deveria ser tentada primeiro como FQDN e só depois do fracasso receber sufixos. Uma entrada sem ponto poderia ser combinada imediatamente com a lista.

Esse passo abria o ataque. A pessoa podia esperar que myhost virasse myhost.bigco.com. Um servidor DHCP malicioso oferecia roguedomain.com, e o cliente passava a perguntar por myhost.roguedomain.com. Não era necessário adulterar a resposta DNS. A alteração importante já estava na formação da pergunta.

O texto dizia expressamente que o DNSSEC não evitava esse cenário. O domínio adversário podia publicar os próprios registros e assiná-los corretamente. A validação mostraria que os dados eram autênticos para myhost.roguedomain.com. Ela não demonstraria que aquele era o domínio imaginado pelo usuário ou aprovado pela política local.

Tratar isso como falha criptográfica apagaria a separação de responsabilidades. A configuração local decidia a precedência. O DHCP apresentava a lista. O cliente autenticava, aceitava e decodificava. O resolvedor montava candidatos. O DNS respondia ao candidato escolhido. O DNSSEC verificava a resposta. A aplicação, por fim, usava ou não o endereço.

Por isso o RFC julgava o sufixo malicioso uma via mais promissora que simplesmente anunciar um servidor DNS ilegítimo. O atacante podia apoiar-se em servidores autoritativos comuns e registros válidos de seu próprio domínio. Todos os sinais posteriores pareciam normais porque o desvio acontecera antes deles.

As mitigações acompanhavam a cadeia: implementar o comportamento de busca do RFC 1536, não permitir que o DHCP substituísse parâmetros DNS manuais e, onde coubesse, exigir autenticação DHCP para aceitar a opção 119. Uma mensagem autenticada, porém, ainda provava a identidade de quem a enviou, não a intenção específica de quem digitou o nome curto.

Uma auditoria precisa conservar recibos em cada fronteira. Guardar a entrada original, listas manual e aprendida, ordem, procedência, servidor e resultado de autenticação. Guardar instâncias 119, agregado RFC 3396, ponteiros, nomes rejeitados e sequência de candidatos. Depois vincular a pergunta transmitida à validação, resposta, endereço e conexão da aplicação.

Uma captura de opção não comprova aceitação. Uma lista decodificada não comprova uso. Uma consulta DNS talvez não revele o texto inicial. Uma assinatura válida não explica quem selecionou o sufixo. Sem esses vínculos, “resolução bem-sucedida” pode esconder exatamente a troca de autoridade investigada.

O registro IANA de parâmetros BOOTP/DHCP confirma a atribuição do código 119, não a implantação. A busca atual do RFC Editor não mostra errata correspondente ao RFC 3397, o que não certifica analisadores, precedência manual nem comportamento real de resolvedores.

O princípio de Especificação Inicial Mínima de Lu Heng ajuda a entender o alcance: padronizar somente a fronteira compartilhada — uso em DNS, codificação, espaço dos ponteiros e terminação — sem impor a arquitetura interna. A Primazia do Código em Execução completa a exigência: testar um ponteiro que atravesse fragmentos e observar desde os bytes agregados até a pergunta e a conexão reais.

O RFC 3397 preserva uma distinção que continua útil. Uma resposta assinada pode ser inteiramente verdadeira. Saber se ela responde à intenção exige provar uma etapa anterior: quem teve autoridade para escolher o nome consultado.

Fontes