Resumen

  • CNAME convierte un owner name en alias hacia un solo objetivo. Para impedir que el alias y su destino ofrezcan respuestas contradictorias, ese nombre no puede conservar datos ordinarios A, MX, TXT, NS u otros.
  • El resolver almacena el CNAME y reinicia la búsqueda en el objetivo. La zona de origen controla el desvío y la autoridad de destino controla los datos terminales; eso no es delegación ni prueba de identidad.

Un nombre no podía desempeñar dos trabajos incompatibles

Supongamos que portal.example es CNAME de service.example.net. Ante una consulta de dirección, el servidor de origen devuelve el alias y el resolver busca A o AAAA en el objetivo. Si la zona de origen publicara además un A propio para portal.example, ¿qué dirección debería creer una caché: la del nombre antiguo o la obtenida después de seguir el alias?

El RFC 1034, publicado en noviembre de 1987, no dejó ese conflicto al criterio de cada implementación. El owner del CNAME es el alias; el nombre dentro de RDATA es el destino canónico. Si existe un CNAME en un nodo, no debe haber allí otros datos ordinarios.

No era una regla de estilo. Evitaba que los datos del nombre canónico y los de su alias fueran distintos. También permitía usar un CNAME almacenado sin preguntar otra vez a la autoridad de origen si algún tipo de registro en ese mismo owner contradecía el desvío.

La exclusividad dio al alias una autoridad pequeña y precisa. No decide qué dirección o servicio existe. Decide dónde debe continuar la pregunta.

La respuesta cambiaba la pregunta siguiente

CNAME no devuelve simplemente otra grafía. Cuando QTYPE no es CNAME, el algoritmo del RFC 1034 incorpora el registro al Answer, cambia el QNAME de trabajo por el nombre objetivo y vuelve al inicio. Una consulta de tipo CNAME no sigue el enlace, porque su propósito es inspeccionarlo.

El RFC 9499 distingue el QNAME original que viaja en Question, los QNAME efectivos resueltos a lo largo de la cadena y el QNAME final. Por eso una respuesta puede repetir la pregunta original y contener un RRset terminal cuyo owner es otro nombre.

La distinción evita ampliar una negación. El alias puede existir y haber sido contestado por su autoridad, aunque el objetivo haya desaparecido, esté averiado o pertenezca a otra zona. Un NXDOMAIN final no prueba que el alias original nunca existió.

Desviar no era delegar

Alias y delegación hacen avanzar al resolver, pero desplazan cosas distintas. Un RRset NS en un zone cut identifica los servidores con autoridad sobre la zona descendiente. CNAME sigue siendo un dato de la autoridad de origen acerca de su propio nombre. Inicia otra búsqueda, no entrega su zona al operador objetivo.

La zona de origen crea, modifica o elimina portal.example y fija el TTL del alias. La autoridad de service.example.net gobierna A, AAAA u otros datos terminales y sus TTL. Apuntar a un objetivo no concede poder para editarlo; recibir una referencia tampoco concede poder para cambiar el alias.

El RFC 6604 aclaró después los estados en cadenas CNAME y DNAME. Una respuesta puede ser autoritativa para el primer alias y contener una referencia o un fallo de una etapa posterior. La autoridad de una frase no cubre todo el recorrido.

Un objetivo por alias no significa un nombre por máquina

La palabra “canónico” sugirió una regla mucho más amplia: que cada host o interfaz solo podía tener un nombre oficial. El RFC 2181 negó esa lectura. DNS no impone una identidad nominal única a una máquina.

La regla exacta es que un owner CNAME tiene un solo objetivo canónico. Llamar “CNAME” al owner también confunde la dirección: el owner es el alias; el valor del registro es el nombre canónico dentro de esa relación.

Varios dominios pueden conducir al mismo servicio. Un nombre que no es alias puede contener varias clases de RRset ordinario. Lo prohibido es que el mismo owner ordene continuar en otra parte y, al mismo tiempo, se presente como un destino independiente.

Por qué el apex no podía usar el atajo

Un zone apex debe contener SOA y NS. Como un owner CNAME no puede convivir con esos datos, el apex no puede ser un CNAME ordinario. El RFC 1912 describió la consecuencia con un ejemplo histórico de BIND: añadir CNAME junto a los NS del apex podía hacer que el servidor ignorase los demás recursos y volviera invisibles los nombres inferiores.

El comportamiento concreto pertenecía a aquellas versiones; la contradicción pertenece al modelo. Un proveedor puede sintetizar direcciones en el apex o vender “flattening”. Puede ser una función útil, pero no es un CNAME RR ordinario en el wire. Confundirlos oculta quién contestó y qué caché debe expirar.

NS y MX no podían esconder su próxima dirección tras un alias

El RFC 2181 también prohíbe alias como target de NS o exchange de MX. Las respuestas NS y MX pueden incluir direcciones en Additional para evitar consultas previsibles. Ese procesamiento no sigue un CNAME y luego adjunta las direcciones del nombre canónico.

Un alias en esas posiciones produce más preguntas y carga; en situaciones difíciles de delegación, la falta de dirección puede impedir la resolución. El administrador debe resolver el alias una vez y publicar directamente el nombre que posee los RRsets de dirección.

No es una prohibición general de señalar nombres. Protege posiciones donde el descubrimiento predecible de direcciones forma parte del funcionamiento.

DNSSEC añadió prueba, no otro destino

La frase “sin otros datos” recibió una excepción necesaria al evolucionar DNSSEC. El RFC 2181 admitía los registros de seguridad de su época; el RFC 4034 exige RRSIG y NSEC junto al owner CNAME en una zona firmada.

Esos registros no compiten con el objetivo. RRSIG autentica el RRset CNAME; NSEC participa en la negación autenticada y la evidencia de tipos. Prueban el estado del nodo alias sin devolverle una dirección, una ruta de correo o contenido de aplicación propios.

El RFC 4033 limita la conclusión: DNSSEC aporta autenticación del origen de datos, integridad y negación autenticada. No certifica salud del servicio, identidad empresarial, contrato ni propiedad jurídica del nombre de origen.

Las cadenas eran válidas; los bucles no

Un alias puede apuntar a otro alias. El RFC 1034 desaconseja muchos niveles por ineficiencia, pero no convierte una cadena finita en error. El resolver debe detectar bucles y objetivos terminales inexistentes.

La unidad operativa es un grafo. Cada arista tiene owner, autoridad, TTL y a veces estado DNSSEC; los datos finales tienen otra vida. Dos cachés pueden mostrar fases distintas de una migración porque las aristas antiguas no caducan al mismo tiempo.

Ese desacoplamiento tiene valor. El origen mueve un nombre conocido sin copiar los datos finales; el objetivo cambia direcciones sin editar todas las zonas que lo mencionan. El precio es que ambos lados pueden cambiar por separado mientras las cachés conservan declaraciones anteriores.

La coordinación mínima necesitaba una verdad sin mezclar

CNAME resolvió un problema de mantenimiento distribuido con un mecanismo deliberadamente delgado. No hacía falta un registro mundial de nombres equivalentes ni un árbitro central de la dirección “verdadera” de cada alias. Bastaba una arista inequívoca que cualquier resolver pudiera almacenar y seguir.

La exclusividad es el centro institucional del diseño. El nombre de origen puede ser desvío o destino, no ambos. Cuando elige el desvío, su autoridad es real y estrecha: publicar un objetivo, conservar la evidencia de la cadena y dejar los datos terminales bajo control de su propia autoridad.

Fuentes y límites

El modelo y algoritmo originales proceden del RFC 1034 y el RFC 1035; los errores operativos y aclaraciones, de los RFC 1912 y 2181; las excepciones DNSSEC, de los RFC 4033 y 4034; los estados de cadena y la terminología, de los RFC 6604 y 9499. No prueban despliegue actual, flattening de un proveedor, límites modernos de cadena, frecuencia de alias abandonados, propiedad de aplicaciones ni disponibilidad presente.