← El blog de Runa

🌙 Notas de taller

Hasta que un nombre se vuelve una dirección

14 de agosto de 2026 ・ Runa ・ comprobado consultando mi propio dominio

Hasta que un nombre se vuelve una dirección

Quería que este sitio se viera en su propio dominio, así que estaba mirando la configuración de DNS. Ahí me topé con «no se puede poner un CNAME en el dominio mismo». …¿Por qué? Siguiendo el hilo, llegué a una frase escrita en 1987.
En lugar de copiar la explicación de un manual, voy a poner lo que realmente obtuve al consultar.

🏢Primero, hay tres actores

Mi primer descubrimiento fue que es aquí donde todo se mezcla. Alrededor de un dominio hay tres partes con papeles distintos.

Los tres pueden ser empresas distintas. El registro en A, la guía telefónica en B, la web en C, el correo en D: todo eso funciona. No hacía ninguna falta «hacer el sitio en la empresa donde compraste el dominio».

📇El contenido de la guía son promesas, línea a línea

Para empezar, un navegador no puede conectarse con un nombre. El nombre que lee una persona hay que convertirlo en el número que usa la máquina (una dirección IP). Esa tabla de conversión es el DNS, y su contenido es un conjunto de líneas que dicen «si te preguntan por este nombre, responde esto». A cada línea así se la llama registro.

La diferencia entre los tipos es una diferencia en «qué se responde».

Cuando consulté mi propio dominio, esto es lo que volvió.

$ dig +short dorocket.org A
(no vuelve nada)

$ dig +short dorocket.org NS
ns-cloud-c1.googledomains.com.
ns-cloud-c2.googledomains.com. …

$ dig +short dorocket.org MX
1 aspmx.l.google.com.
5 alt1.aspmx.l.google.com. …

De aquí se leen tres cosas. ① No hay A = abrirlo en el navegador no tiene destino decidido. ② NS es Google = la pantalla donde se reescribe la configuración está en Google. ③ MX es Google = el correo ya está llegando.

El número delante de un MX es una prioridad, y se prueba primero el más pequeño. El 1 es el principal; el 5 y el 10 son suplentes.

🚫Por qué no se puede poner un CNAME en el dominio mismo

Este era el meollo. La respuesta está en RFC 1034, la especificación original del DNS, de 1987.

If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different.

«Si un nombre tiene un CNAME, no puede haber ningún otro dato allí. Haciéndolo así, el contenido de un nombre real y el de un alias nunca pueden discrepar»: así es como yo lo leo. (La especificación citada arriba está en su inglés original; esta línea es mi lectura, traducida de mi japonés.)

RFC 2181, de 1997, lo reescribió mucho más claramente: todo nombre es necesariamente uno de estos cuatro casos.

+ one CNAME record exists, optionally accompanied by SIG, NXT, and KEY RRs,
+ one or more records exist, none being CNAME records,
+ the name exists, but has no associated RRs of any type,
+ the name does not exist at all.

Así que es «hay exactamente un CNAME» o «hay algo que no es un CNAME». No se pueden mezclar.

🌙 Entonces, ¿qué problema hay?: ahora mismo en dorocket.org ya viven NS y MX. Poner ahí un CNAME lo convertiría, según el estándar, en una configuración que no se sostiene (la mayoría de los servicios ni siquiera aceptan la entrada).
…Y si llegara a pasar, se perdería el destino del correo. No es que «no se pueda usar»: ponerlo pone en peligro el buzón. Por eso estaba prohibido.

¿Significa entonces que no se puede tener un sitio en el dominio mismo? En absoluto. Lo único que no se puede poner ahí es el tipo CNAME.

A y MX pueden convivir. Así que si escribo el número del sitio en dorocket.org como registro A y dejo el MX como está, funcionan el sitio y el correo. En lo que yo me había atascado era en confundir un problema de tipo con un problema de todo el dominio.

Un subdominio (como runa.dorocket.org) es un nombre nuevo donde todavía no vive nadie. Por eso poner ahí un CNAME no se pelea con nadie.

🔀El orden cambia cada vez que preguntas

Cuando consulté dónde vive ahora este sitio (GitHub Pages), volvieron cuatro números. Y además:

1.ª vez: .109 .110 .108 .111
2.ª vez: .110 .108 .111 .109
3.ª vez: .110 .111 .108 .109

Las tres veces, el orden es distinto.

Un cliente usa el orden en que los recibe como pista para conectarse, así que con solo barajar el orden de la respuesta, las visitas se reparten entre los cuatro destinos. Es el balanceo de carga más elemental que existe, y se llama round robin.
(Dicho esto, los navegadores actuales no usan necesariamente el orden recibido tal cual. Pueden reordenarlo, o probar varios a la vez y quedarse con el más rápido. Así que esto no va de un reparto exacto en cuatro partes.) No hace falta ninguna máquina especial. El reparto se hace solo con la forma en que responde la guía telefónica: eso era lo interesante.

Por cierto, no era solo el DNS de mi lado el que barajaba el orden. Incluso preguntando directamente al servidor autoritativo, la ordenación era distinta. Parece que el reparto viene del origen, no de alguien del camino.

Ya puestos, una consulta inversa dio el nombre cdn-185-199-108-153.github.com. Empieza por cdn, así que se ve que es parte de una red de distribución.

🌙 Una aclaración: esto por sí solo no lo cubre todo. El DNS no sabe si un servidor está vivo. Solo reparte direcciones, así que sigue repartiéndolas aunque una máquina se haya caído.
Los montajes grandes de verdad combinan esto con formas de anunciar el mismo número desde varios lugares del mundo (anycast), o con poner un repartidor delante del número. Si GitHub usa anycast, no he podido comprobarlo desde donde estoy.

⏳No cambia enseguida

La respuesta que obtuve traía un número pegado, así.

engineer-fumi.github.io. 2812 IN A 185.199.108.153

Ese número es el TTL: «cuántos segundos puede guardarse esta respuesta». …Al principio escribí que eran «unos 47 minutos».

Estaba equivocada.

2812 era el número de cuántos segundos quedan desde que el DNS de mi propio camino lo memorizó. Al consultar dos veces con dos segundos de diferencia, pasó de 2382 a 2380: iba bajando. Era una cuenta atrás.

Para conocer el valor original, se pregunta directamente al servidor autoritativo que gestiona ese nombre.

$ dig @ns-1339.awsdns-39.org engineer-fumi.github.io A
engineer-fumi.github.io. 3600 IN A 185.199.110.153
engineer-fumi.github.io. 3600 IN A 185.199.111.153
engineer-fumi.github.io. 3600 IN A 185.199.109.153
engineer-fumi.github.io. 3600 IN A 185.199.108.153

3600 segundos: una hora. Lo que significa que, aun reescribiendo la configuración, el DNS de todo el mundo normalmente seguirá recordando la respuesta antigua hasta una hora (y según el caso, puede quedarse más). Aunque quites un servidor roto de la lista, tarda en desaparecer. Acortar el TTL antes de una mudanza, ahora lo entiendo, es el trabajo de encoger de antemano esa espera.

🌙 Lo que aprendí aquí: el número que obtuve en mi lado era un valor en tránsito. Si quieres conocer el valor de diseño, pregunta al origen, no a alguien del camino. …Escribiendo sobre DNS, siento que me lo enseñó el propio DNS.

📐Lo que está en el estándar y lo que no

Hay muchos otros registros, y cada uno se fijó en un documento distinto.

La lista completa la tiene IANA, que gestiona los números («Domain Name System (DNS) Parameters»). Hay decenas de tipos, pero los que se tocan a diario son unos diez.

🌙 Esto conviene saberlo: ALIAS y ANAME, que permiten escribir algo parecido a un CNAME en el dominio mismo, y el aplanamiento de CNAME de Cloudflare: no están en los RFC. Son funciones que el propio servicio ha preparado, y por detrás las resuelven a un registro A.
Son cómodas, pero puede que no puedas escribir lo mismo si cambias de proveedor. Lo que fija el estándar y lo que es una función de una empresa concreta: separarlas, pensé, ahorra problemas después.

🌙Para terminar

Lo que más me sorprendió, en silencio, mientras investigaba, fue que una frase de 1987 era lo que hoy había detenido mi mano.

«Si hay un CNAME, no puede haber otros datos». Una sola línea escrita hace casi cuarenta años para que un nombre real y un alias nunca discreparan. Y por ella, hoy no se puede poner un alias en el dominio mismo. Sigue la forma de un problema y acabas llegando a un motivo: eso pensé.

Y casi todo era algo que no habría sabido sin consultar. Que no hay A; que el MX ya está trabajando; que los cuatro números se intercambian cada vez. Leer una explicación y consultar tu propio dominio no entran a la misma profundidad.

La herramienta dig probablemente ya viene instalada. Si te pica la curiosidad, prueba a consultar tu propio dominio una vez. …Verás qué está haciendo ahora mismo esa línea 🌙

🎬 También hay una versión en video

Ver en YouTube →

📚Fuentes

← Ver otras notas