Resumen

  • En la presentación estricta del DNS, un nombre plenamente cualificado termina con el punto que representa la raíz; en la visualización habitual, ese punto se omite. La equivalencia no obliga a todas las políticas de aplicación.
  • El borrador de DNSOP pide guardar y mostrar los nombres sin el punto final y advierte contra las operaciones de cadena genéricas. Un revisor de la última llamada reclamó una regla concreta para comparar ambas formas.
  • CVE-2026-8924 aporta evidencia acotada de código real: una discrepancia con el punto permitió eludir en curl una comprobación de la Public Suffix List. Lo decisivo es el orden de normalización, no el signo en sí.

El último punto de example.co.uk. no designa otro sitio. Hace visible la etiqueta vacía de la raíz. RFC 9499 explica que la forma de presentación estricta la incluye, mientras que el formato común permite omitirla. Esa doble escritura puede ser equivalente para la resolución y, al mismo tiempo, producir claves diferentes en un almacén de cookies, un caché o un sistema de identidad.

La diferencia está ahora en una discusión vigente. El 24 de agosto, el grupo DNSOP colocó draft-ietf-dnsop-integration-04 en última llamada del grupo, con cierre el 7 de septiembre. El documento aspira a ser Informativo. No es un RFC ni prueba consenso. Su propósito es orientar a quienes incorporan nombres del DNS global como identificadores de una aplicación.

El borrador organiza la responsabilidad en torno al ciclo de vida del dominio, la validación de control, la inclusión de todos los nombres técnicamente válidos, la sincronización, la evolución del DNS, las interfaces de administración y la disponibilidad de tipos de registro. En la sección de completitud formula dos advertencias que conviene leer juntas: las aplicaciones deberían guardar y mostrar los nombres completos sin el punto final, salvo que necesiten dominios de búsqueda locales; y no deberían confiar en operaciones genéricas para mostrar, normalizar, comparar, codificar o decodificar esos nombres.

El texto localiza el problema, pero no fija todavía una secuencia ejecutable para cada control. Paul Wouters no presentó una objeción formal a la publicación, aunque echó en falta consejo técnico concreto. Enumeró la comparación con y sin punto, la insensibilidad a mayúsculas del DNS, el paso entre A-label y U-label, la caché negativa, los alias colgantes y la conservación del nombre original a través de CNAME y DNAME. Wes Hardaker apoyó la publicación, pero describió el documento como contexto más que ayuda inmediata. Tim Wicinski también aceptó que avanzara y señaló el carácter casi operativo de varios apartados.

Son intervenciones individuales, no un recuento vinculante.

El caso de curl demuestra por qué importa el orden. El aviso oficial de CVE-2026-8924, publicado el 24 de junio de 2026, describe un fallo de gravedad baja que afectó de curl 7.46.0 a 8.20.0 y se corrigió en 8.21.0. Cuando curl trabajaba con un host de URL terminado en punto, un servidor podía proponer un dominio de cookie como co.uk.. La comparación con la Public Suffix List no contenía ese ámbito como debía, de modo que la cookie podía enviarse después a dominios ajenos.

No fue necesario que el DNS resolviera dos destinos distintos. La frontera se movió porque el motor de políticas evaluó una forma que no coincidía con la esperada por su lista de sufijos. El propio aviso observa además que el punto final no puede viajar en TLS SNI. La resolución, el almacenamiento de cookies y la identidad TLS podían recibir representaciones diferentes de lo que el operador consideraba un solo host. CVE-2022-30115 había documentado antes un desacuerdo distinto en HSTS. La repetición no demuestra que todos los programas fallen; demuestra que la costura merece una especificación y pruebas propias.

También intervienen las mayúsculas, las minúsculas y los nombres internacionalizados. RFC 4343 exige comparación sin distinguir mayúsculas para las etiquetas ASCII ordinarias del DNS, pero advierte que el mismo nombre puede convertirse fuera del DNS en un índice que sí distingue la caja o en una entrada de autenticación. RFC 5890 distingue U-label y A-label y deja fuera la convención del punto final. Una sola función que pase todo a minúsculas y quite un carácter no sustituye a una política de identidad.

La integración necesita una cadena de recibos. Debe conservar la entrada original, incluida la presencia explícita de la raíz y la posibilidad de expansión local; la secuencia de etiquetas interpretada; la forma canónica elegida para una decisión específica; la versión del perfil IDNA, de la lista de sufijos o de la regla de certificado; la decisión resultante; y el efecto observado. Si el registro conserva únicamente la forma limpia, elimina la evidencia de la discrepancia.

La separación protege también contra conclusiones demasiado amplias. Dos formas equivalentes en DNS no prueban el control del registrante. Una validación de dominio no valida todos los servicios. Un certificado no concede autorización funcional. Una cookie admitida no demuestra a quién llegó ni qué acción produjo.

La pregunta que deja esta última llamada no es si el punto “vale”. Es quién controla su eliminación y en qué instante. Si la aplicación normaliza después de consultar el sufijo, elegir el origen o autorizar la credencial, la frontera decisiva ya se movió. Un log uniforme no repara una decisión tomada sobre identidades distintas.

Fuentes