Resumo

  • O parâmetro next-hop-aliases registra aliases e nomes canônicos que o proxy recebeu durante a resolução DNS do próximo salto.
  • A lista pode estar ausente, vazia ou incompleta; não contém DNSSEC e depende da honestidade e da visibilidade do proxy e dos resolvedores.
  • Uma decisão confiável combina procedência do relato, DNS bruto, validação, autenticação do endpoint, política local e efeito executado.

O cliente pediu um nome. O proxy resolveu outro, seguiu um CNAME e abriu a conexão por um endereço. Antes do RFC 9532, boa parte dessa passagem podia desaparecer da visão do cliente. Depois dele, o proxy pode devolver a trilha nominal em Proxy-Status.

Ganhar a trilha não significa ganhar a identidade.

O RFC 9532 define next-hop-aliases para transportar os aliases e nomes canônicos recebidos na resolução do próximo salto. Isso é especialmente útil quando o cliente delega a resolução a um proxy e quando uma cadeia CNAME oculta um rastreador ou destino malicioso atrás de um nome de aparência benigna.

O relato pertence a quem resolveu

O RFC 9209 criou Proxy-Status para intermediários descreverem como trataram uma requisição. Portanto, a lista não é uma transcrição neutra emitida pela autoridade DNS. É uma afirmação do proxy sobre o que seu resolvedor lhe mostrou.

Esse detalhe muda a auditoria. É preciso identificar qual proxy gerou o item, como o cliente estabelece confiança nele, qual resolvedor foi usado, se havia validação, que cache e versão de configuração estavam ativos e se outro intermediário poderia remover ou alterar o campo.

A confiança na presença e na ausência passa pelos mesmos atores. Um resolvedor recursivo ou autoritativo pode omitir CNAMEs. Um proxy malicioso pode deixar de reportá-los. Não receber a cadeia não demonstra que ela não existia.

Uma string, duas camadas de parsing

Por fora, o valor é uma string de Structured Fields, conforme o RFC 8941. Por dentro, o RFC 9532 define nomes separados por vírgulas. O nome original pode aparecer, seguido pelos aliases e pelo nome que finalmente produziu endereços. A ordem é recomendada por consistência, não uma garantia absoluta.

Se uma vírgula fizer parte de um nome DNS, deve ser codificada em porcentagem. Um ponto dentro de um label precisa ser escapado antes da codificação da barra. A barra literal exige tratamento próprio. Misturar essas etapas pode mudar a identidade textual do nome mesmo quando o transporte HTTP foi aceito.

Por isso, o recibo preserva os bytes originais, o resultado de Structured Fields, a decodificação percentual, os labels reconstruídos e a versão do parser.

Um campo válido pode carregar só o fim da história

O proxy nem sempre tem acesso à cadeia completa. APIs comuns como getaddrinfo podem fornecer o nome canônico final com AI_CANONNAME, sem devolver os aliases intermediários. O RFC permite informação incompleta nesses casos.

Ausente, vazio, preenchido e inválido são estados diferentes. Ausente pode significar sem suporte, removido ou não aplicável. Vazio significa apenas que aquele proxy declara não ter encontrado CNAME naquela resolução. Preenchido é o conjunto que ele diz ter recebido. Inválido não deve ser convertido em uma lista conveniente.

Outro resolvedor, cache, instante ou ambiente de DNS dividido pode enxergar algo diferente. A lista descreve uma execução, não a topologia eterna do nome.

A prova DNSSEC não viaja no parâmetro

O RFC diz expressamente que next-hop-aliases não inclui informação DNSSEC e não implica o uso de DNSSEC. A lista é uma pista e não deve decidir a identidade do recurso acessado.

Os RFC 4033 e RFC 4035 tratam de origem e integridade autenticadas dos dados DNS e de negação validável. Assinaturas, cadeia de confiança e estado de validação não aparecem na lista do proxy.

Mesmo DNS validado não substitui autenticação TLS, autoridade HTTP, identidade de conta, política de cookies ou permissão para liberar dados. Cada camada mantém seu responsável.

O recibo que torna a pista útil

Uma decisão defensável junta: intenção da requisição; identidade do proxy; resolvedor e cache; consulta e resposta DNS; CNAMEs, endereço final e TTL; material DNSSEC separado; transformação para o campo; conexão; autenticação; política; decisão e resultado.

Essa cadeia aplica a separação de camadas de Heng Lu. Um nome não é uma resposta; uma resposta não é o relato do proxy; o relato não é validação; validação não é autorização. A primazia do código executado exige evidência de cada passagem.

O padrão comum pode permanecer mínimo. O proxy divulga uma observação num formato interoperável; cada cliente decide localmente se usa a pista para inspeção adicional, cookies, bloqueio ou acesso. Coordenação não precisa virar autoridade central.

As fontes não provam adoção por produtos específicos, frequência de cloaking nem resultados reais. Os exemplos do RFC são ilustrações. Essa incerteza impede que a norma seja convertida em notícia de implantação.

Fontes