Resumo

  • Na apresentação estrita do DNS, o nome totalmente qualificado termina com o ponto da raiz; na exibição comum, esse ponto quase sempre desaparece. A equivalência no DNS não se transfere automaticamente para toda política de aplicação.
  • O rascunho em Última Chamada do DNSOP recomenda armazenar e exibir nomes sem o ponto final e adverte contra operações genéricas de string. Um revisor pediu uma regra operacional para comparar as duas formas.
  • A CVE-2026-8924 oferece evidência delimitada de código em funcionamento: no curl, a divergência permitiu contornar a Public Suffix List ao definir cookies. A ordem da normalização, e não o ponto isolado, moveu a fronteira.

O ponto depois de uk torna explícito o rótulo vazio da raiz. A RFC 9499 chama essa escrita de apresentação estrita e explica que o formato comum pode omiti-la. Um resolvedor pode chegar ao mesmo nome com as duas formas. Um repositório de cookies, uma verificação de certificado, um cache ou um cadastro de contas não recebe essa igualdade por herança.

Essa costura está no centro de uma discussão atual. Em 24 de agosto, o IETF DNSOP colocou draft-ietf-dnsop-integration-04 em Última Chamada de Grupo, com encerramento em 7 de setembro. O texto pretende ser Informativo; ainda não é RFC nem prova consenso. Ele reúne considerações para aplicações que usam nomes do DNS global como identificadores.

O rascunho trata do ciclo de vida do domínio, validação de controle, completude, sincronização, evolução do protocolo, diferenças entre interfaces de gestão e disponibilidade de tipos de registro. Na seção 3.3, recomenda guardar e mostrar nomes totalmente qualificados sem o ponto final, exceto quando domínios locais de busca forem necessários. Na mesma passagem, afirma que exibir, normalizar, comparar, codificar e decodificar nomes requer tratamento próprio, não simples operações de texto.

O risco está identificado; a sequência testável de cada controle ainda não está. Paul Wouters não apresentou objeção formal à publicação, mas considerou escasso o conselho técnico. Ele citou comparação com e sem ponto, ausência de distinção entre maiúsculas e minúsculas no DNS, equivalência entre A-label e U-label, caches negativos, aliases pendentes e preservação do nome consultado ao seguir CNAME ou DNAME. Wes Hardaker apoiou a publicação, embora tenha visto mais contexto futuro que ajuda imediata. Tim Wicinski também aceitou o avanço e aproximou as últimas partes da seção 3 de questões operacionais.

São comentários individuais, não uma decisão coletiva.

A CVE-2026-8924 mostra por que a ordem precisa ser escrita. O aviso oficial do curl, de 24 de junho de 2026, classifica a falha como baixa, informa impacto das versões 7.46.0 a 8.20.0 e correção na 8.21.0. Ao trabalhar com um host de URL terminado em ponto, como example.co.uk., um servidor podia definir um cookie para co.uk.. A checagem contra a Public Suffix List não barrava o domínio amplo, e o cookie podia ser enviado a domínios sem relação.

O DNS não precisou produzir destinos diferentes. A política recebeu uma representação que não correspondia à forma esperada por sua lista. O aviso também observa que o ponto terminal não pode ser levado no TLS SNI. Assim, resolução, cookie e TLS podiam tratar uma única entrada com convenções textuais distintas. A CVE-2022-30115 registrou antes uma divergência separada no estado HSTS. Isso não generaliza a falha para todo software; confirma que a mesma junção reaparece quando cada componente inventa sua própria forma canônica.

Maiúsculas e nomes internacionalizados ampliam o contrato. A RFC 4343 exige comparação sem distinção de caixa para rótulos ASCII comuns do DNS, mas alerta que o nome, fora do DNS, pode virar índice sensível à caixa ou entrada de autenticação. A RFC 5890 separa U-label Unicode de A-label compatível com ASCII e deixa a convenção do ponto terminal fora de seu escopo. Converter para minúsculas e remover um caractere não é uma identidade universal.

Uma integração auditável precisa conservar etapas. Primeiro, a entrada bruta, a raiz explícita e a permissão para busca local. Depois, os rótulos analisados e o estado absoluto ou relativo. Em seguida, a forma canônica usada por uma decisão específica e a versão da Public Suffix List, do perfil IDNA ou da regra de certificado. Por fim, a decisão e seu efeito: chave armazenada, cookie aceito, credencial transmitida ou pedido recusado.

Esses recibos limitam o significado de cada resultado. Igualdade no DNS não prova controle do registrante. Validação de domínio não certifica todo serviço. Certificado não autoriza toda ação. Correspondência de cookie não demonstra destinatário final nem resultado.

A pergunta deixada pela Última Chamada não é se o ponto deve ser bonito ou invisível. É quem controla a forma canônica e em que momento. Se a aplicação decide suffix, origem ou credencial antes de normalizar, a fronteira já se moveu. Padronizar o registro depois não padroniza a decisão que ocorreu antes.

Fontes