Resumen

  • DNAME apareció en 1999 para sustituir el sufijo propietario por un sufijo objetivo en las consultas de todos sus descendientes. Una regla podía representar una familia de alias que todavía no tenía un número cerrado de miembros.
  • La regla no redirige su propio nombre ni crea una delegación. El ápice conserva SOA y NS, y la autoridad sobre una zona hija sigue naciendo de un conjunto NS en un corte de zona.
  • La revisión de 2012 hizo visibles los límites: CNAME sintetizado por consulta, validación del DNAME firmado, ocultación de datos inferiores, rechazo práctico del comodín, control de bucles y YXDOMAIN cuando la sustitución produce un nombre excesivo.

El hueco que CNAME y NS dejaban abierto

En RFC 1034, CNAME y NS ya permitían dos desplazamientos fundamentales. CNAME desviaba la búsqueda de un nombre exacto hacia su nombre canónico. Un conjunto NS situado en un corte enviaba al resolvedor a los servidores autoritativos de una zona hija.

No eran variantes de la misma operación. El primero trataba la identidad de un nodo; el segundo repartía la administración del árbol. Faltaba expresar algo más modesto que una delegación y más amplio que un alias individual: conservar las etiquetas iniciales de cualquier descendiente, pero cambiar la terminación compartida.

Si una organización abandonaba viejo.example, un CNAME para www no resolvía correo, datos.correo ni nombres futuros. Delegar la zona podía ser excesivo si no cambiaba quién administraba el espacio antiguo. La necesidad era una instrucción de reescritura, no una cesión de autoridad.

Una regla para un conjunto abierto de nombres

RFC 2672 creó DNAME, tipo 39, en agosto de 1999. Cuando el propietario del registro coincide con el sufijo de un nombre descendiente, el resolvedor sustituye ese sufijo por el objetivo. La coincidencia respeta etiquetas completas.

Un DNAME de viejo.example a nuevo.example transforma archivo.lab.viejo.example en archivo.lab.nuevo.example. No duplica los registros del destino y tampoco obliga a que ambas zonas tengan el mismo operador. Conserva archivo.lab porque la regla solo gobierna la parte derecha.

El RFC original presentó la renumeración de redes y el cambio de nombre de organizaciones como motivaciones. En DNS inverso, una regla podía reducir la cantidad de datos que había que modificar cuando cambiaban las etiquetas de direcciones. En una reorganización, los nombres descendientes antiguos podían conducir a sus equivalentes nuevos.

Son ejemplos de diseño, no estadísticas de adopción. Lo perdurable es la unidad de control: un registro pequeño adquiría efectos sobre un subárbol potencialmente enorme.

El ápice se negaba a desaparecer

RFC 6672 sustituyó la especificación original y dejó inequívoca la excepción. DNAME redirige los nombres subordinados a su propietario; no redirige el propietario.

Así, www.viejo.example puede seguir el nuevo sufijo, pero una consulta por viejo.example permanece en el ápice antiguo. Allí pueden existir otros tipos compatibles, y una zona sigue necesitando SOA y NS. DNAME no puede reflejar una zona entera porque no refleja su ápice.

La consecuencia aparece al migrar servicios. El correo del ápice quizá necesite un MX explícito en ambos espacios. El servidor web y el certificado deben reconocer el nombre antiguo. Resolver hasta un destino no obliga a una aplicación a aceptar la identidad con la que llegó el usuario.

La excepción no reduce accidentalmente la función. Define su honestidad: DNAME promete equivalencia estructural para descendientes, no identidad total entre dominios.

El servidor fabricaba el alias concreto

Cuando aplica la sustitución, el servidor incluye el DNAME y sintetiza un CNAME para la consulta exacta. La pregunta por archivo.lab.viejo.example recibe un CNAME hacia archivo.lab.nuevo.example, aunque esa línea nunca haya sido almacenada en el archivo de zona.

El diseño separa norma y ejecución. DNAME es la norma compacta publicada por el administrador. El CNAME sintetizado es la consecuencia que un cliente puede seguir. Los servidores recursivos con caché también deben sintetizarlo para clientes que no procesen DNAME por sí mismos.

La experiencia cambió el TTL. La primera especificación usaba cero; RFC 6672 da al CNAME el TTL del DNAME. Los resolvedores deben tolerar ambos porque las implementaciones antiguas no desaparecieron con la revisión. Una norma madura debía corregir el futuro sin declarar ilegible el pasado aún operativo.

Tampoco existe una señal EDNS para anunciar comprensión de DNAME. La idea mencionada en 1999 nunca se especificó. La compatibilidad procede de respuestas DNS ordinarias y de un CNAME familiar, no de una negociación inexistente.

Firmar la causa y comprobar el efecto

DNSSEC no puede preparar una firma para cada posible CNAME descendiente: el nombre consultado puede no haber existido antes de la pregunta. En su lugar, firma el DNAME.

El validador verifica esa regla, repite la sustitución y comprueba que el CNAME no firmado es exactamente el resultado que corresponde. La prueba no está en una firma independiente sobre cada efecto, sino en una causa autenticada y una transformación determinista.

Esta arquitectura limita lo que el servidor puede inventar. Debe mantener las etiquetas izquierdas, reconocer el sufijo propietario por límites de etiqueta y usar la meta contenida en el DNAME firmado. Una redirección diferente no pasaría la comprobación.

Las cadenas añaden otra frontera. DNAME puede llevar a CNAME, a otro DNAME o a un error. RFC 6604 exige interpretar el código de respuesta y los bits de estado con respecto al resultado terminal. Un primer salto auténtico no autentica por sí solo la zona de destino ni convierte su fallo en éxito.

Delegar significa cambiar quién responde

La terminología vigente de RFC 9499 clasifica como alias a un subdominio del propietario de DNAME. En cambio, una delegación crea una zona separada mediante un conjunto NS en la zona padre, justo en un corte.

La diferencia puede observarse en el algoritmo. Una referencia NS cambia el conjunto de servidores al que el resolvedor atribuye autoridad sobre el nombre original. DNAME cambia el nombre buscado. Después, ese nuevo nombre recorre su propia jerarquía de delegaciones.

Por eso un DNAME no puede compartir, fuera del ápice, el mismo propietario con un NS que marque delegación. Si la zona hija desea usar DNAME en su ápice, la regla debe estar debajo del corte y convivir allí con sus SOA y NS.

El operador origen controla el puntero. Los operadores padre e hijo controlan la delegación origen. El operador destino controla los datos alcanzados. La continuidad de la respuesta no fusiona esos tres poderes.

La compresión administrativa podía ocultar datos

No deben existir registros en descendientes del propietario DNAME dentro de la misma zona. Si permanecen en el contenido cargado, quedan ocultos por la redirección. El árbol parece haberse vaciado aunque las líneas todavía estén presentes.

Durante una modificación, un caché puede conservar datos inferiores anteriores y recibir el nuevo DNAME. RFC 6672 permite manejar temporalmente esa contradicción de varias formas y confía en la expiración de los TTL para recuperar coherencia.

Una puesta en producción requiere por ello inventariar el subárbol antes de añadir la regla. También exige una retirada que respete el tiempo distribuido: borrar DNAME en el servidor autoritativo no borra copias válidas en los resolvedores.

DNAME es único en su propietario y no puede coexistir allí con CNAME. La amplitud del efecto no da permiso para crear destinos competidores. El protocolo conserva una decisión legible por cada punto del árbol.

El comodín cruzaba una frontera peligrosa

Un DNAME fijo produce CNAME concretos. Un DNAME cuyo propietario fuera comodín permitiría que la expansión del comodín produjera primero la propia regla de redirección. Diferentes cachés podrían adquirir reglas distintas.

RFC 4592 lo describió como una amenaza a la coherencia de DNS. RFC 6672 desaconseja esa combinación y permite a los servidores advertir o rechazarla.

La lección es precisa: sintetizar una consecuencia es manejable cuando su regla autoritativa es fija. Sintetizar también la regla hace borroso el origen de la autoridad. La automatización deja entonces de ser una transformación verificable y empieza a repartir capacidad de decisión de forma no determinista.

El DNS pudo aceptar una cantidad infinita de preguntas potenciales. No por ello debía aceptar una cantidad infinita de reglas potenciales inventadas al responderlas.

Un alias amplio necesitaba frenos amplios

DNAME y CNAME pueden formar bucles entre sí. Una sustitución también puede devolver el nombre al espacio donde la misma regla vuelve a coincidir. Los resolvedores deben limitar recursos y profundidad, aunque algunas cadenas largas sean válidas.

Otra salida es puramente geométrica. Sustituir un sufijo largo por otro puede producir un nombre de más de 255 octetos. El servidor responde YXDOMAIN y aporta el DNAME —y su firma si existe— como explicación. No es NXDOMAIN: el problema no es que falte el nombre original, sino que el resultado calculado no cabe en DNS.

Los nombres usados como destinos de NS, MX, PTR y SRV deben además ser canónicos. La búsqueda de su dirección no puede depender de CNAME o DNAME. El sistema evita colocar indirección dentro de los nombres que necesita para ejecutar su propia infraestructura de autoridad y servicios.

Los límites asignan responsabilidad. El administrador origen debe evitar reglas cíclicas o expansivas. El autoritativo debe expresar el error correcto. El resolvedor debe negar trabajo ilimitado. La conveniencia de un registro no socializa un coste sin techo.

Lo que DNAME preservaba y lo que no

DNAME preserva una relación sintáctica entre descendientes. Puede mantener accesibles nombres antiguos durante una transición. No preserva por sí mismo propiedad, contrato, disponibilidad, claves, certificados ni aceptación de aplicaciones.

Esa separación es valiosa. Obliga a registrar qué operador conserva la zona origen, quién administra el destino y durante cuánto tiempo seguirá vigente la redirección. Impide que una respuesta técnica fluida se convierta en prueba automática de continuidad institucional.

La historia del registro muestra un patrón del Internet: ampliar una función sin borrar el límite de autoridad que la hace auditable. DNAME podía enviar una consulta muy lejos en el árbol. Nunca recibió el derecho de fingir que también había movido la zona.

Fuentes y límites de la evidencia

La arquitectura original de CNAME, zonas y delegaciones está en RFC 1034: https://www.rfc-editor.org/rfc/rfc1034.html

La primera definición de DNAME y sus motivaciones está en RFC 2672: https://www.rfc-editor.org/rfc/rfc2672.html

El riesgo de DNAME con comodines está en RFC 4592: https://www.rfc-editor.org/rfc/rfc4592.html

La semántica terminal de cadenas xNAME está en RFC 6604: https://www.rfc-editor.org/rfc/rfc6604.html

Las reglas actuales de sustitución, síntesis, DNSSEC y errores están en RFC 6672: https://www.rfc-editor.org/rfc/rfc6672.html

Las definiciones actuales de alias y delegación están en RFC 9499: https://www.rfc-editor.org/rfc/rfc9499.html

Los documentos no ofrecen una tasa mundial actual de uso ni un ahorro universal. Sus ejemplos ilustran posibilidades. Resolver mediante DNAME no demuestra que origen y destino tengan el mismo dueño, que la aplicación acepte el alias, que el certificado sea válido o que la autoridad haya sido transferida.