DNS sin misterio: registros, servidores de nombres y propagación, administrados por conversación

Publicado el 2026-08-25 por frfrand

Guía práctica de DNS para desarrolladores: qué hace cada tipo de registro, por qué el TTL importa más de lo que parece, cómo funciona la propagación real y cómo administrar todo conversando con una IA mediante el MCP de ArduMaker. Incluye crear_dominio_empresa, ver_estado_ns_dominio, listar_registros_dns, crear_registro_dns y editar_registro_dns.

El DNS es el sistema que más gente toca sin entender del todo, y el que más noches arruina. Alguien cambia un registro un viernes, "no propagó todavía", y el lunes el sitio sigue caído por una razón que nadie mira: el TTL de 86400 que quedó puesto hace dos años.

Esta guía cubre dos cosas a la vez. Primero, cómo funciona realmente el DNS, sin las simplificaciones que después salen caras. Segundo, cómo administrar dominios y registros con el MCP de ArduMaker, pidiéndoselo a una IA en lenguaje natural.

Herramientas cubiertas: crear_dominio_empresa, listar_dominios_empresa, ver_dominio_empresa, eliminar_dominio_empresa, ver_estado_ns_dominio, listar_registros_dns, crear_registro_dns y editar_registro_dns.

Un detalle de forma que evita frustraciones: las herramientas de dominios trabajan con ids numéricos, no con nombres. crear_dominio_empresa y listar_dominios_empresa piden el company_id de la empresa; el resto pide el domain_id que sale de ese listado. No existe "pasale el dominio tienda.com": primero se lista, después se opera sobre el id.

Lo primero que hay que entender: los name servers mandan

Un dominio no "vive" en un solo lugar. Vive donde apuntan sus name servers, y eso se define en el registrador donde lo compraste.

Esta es la fuente de la mitad de los problemas de DNS: alguien edita registros en un panel, no ve ningún cambio, y no se da cuenta de que el dominio todavía apunta a los name servers del registrador anterior. Los registros están perfectos... en un servidor que nadie consulta.

crear_dominio_empresa registra el dominio en la plataforma y crea su zona en Cloudflare. Al hacerlo te devuelve los name servers que tenés que cargar en tu registrador. Ese paso es manual e inevitable: nadie puede cambiar los name servers de tu dominio salvo vos, desde donde lo compraste. Detalle útil: si el dominio ya había estado dado de alta para la misma empresa y se borró, esta llamada lo reactiva en vez de crear un duplicado.

ver_estado_ns_dominio es la herramienta que conviene usar antes de romperse la cabeza. Consulta en vivo contra Cloudflare si el dominio ya está conectado o si sigue pendiente, y actualiza el estado guardado. Cuando alguien dice "cambié el registro y no pasa nada", esta es la primera pregunta que hay que hacerle a la IA: "¿este dominio ya tiene los name servers apuntando bien?".

El cambio de servidores de nombres puede tardar desde minutos hasta 48 horas, según el TLD. Durante ese lapso, parte del mundo te ve en el servidor viejo y parte en el nuevo. No es un error: es cómo funciona.

listar_dominios_empresa y ver_dominio_empresa son el inventario. ver_dominio_empresa trae además el estado en vivo de la zona en Cloudflare, y lo hace en modo best effort: si Cloudflare no contesta, igual te devuelve los datos del dominio con un cloudflare_error explicando por qué falta lo demás. Uso típico y muy poco glamoroso pero valioso: una vez por trimestre, preguntar "¿qué dominios tenemos y cuál es su estado?" y descubrir los dos que vencen el mes que viene y nadie estaba mirando.

eliminar_dominio_empresa da de baja el dominio de la plataforma, y conviene saber exactamente qué hace y qué no, porque suena más grave de lo que es:

• Es un borrado blando y es reversible. Volvés a llamar a crear_dominio_empresa con el mismo nombre y el dominio revive.
• No toca la zona de Cloudflare ni sus registros. El id de la zona se conserva y los registros DNS quedan donde estaban. El sitio y el correo siguen funcionando exactamente igual.
• Lo que perdés es la administración desde ArduMaker, no el servicio. Mientras el dominio esté dado de baja no vas a poder listar ni editar sus registros con estas herramientas.

Y por supuesto, borrarlo acá no cambia nada en tu registrador: los servidores de nombres siguen apuntando adonde apuntaban.

Los registros que vas a usar de verdad

De la larga lista de tipos de registro DNS, en el día a día se usan cinco o seis. Vale la pena conocerlos bien.

A apunta un nombre a una dirección IPv4. Es el más común: midominio.com → 203.0.113.10.

Una precisión importante si el destino es un VPS de ArduMaker: el VPS no tiene IP pública propia. Es un container dentro de un host padre compartido, y la IP que ve internet es la del host. Cada VPS sí tiene un nombre DNS propio del estilo <slug>.arducloud.com, con un A que apunta a esa IP. Por eso, para conectar tu dominio a tu servidor, lo más robusto no suele ser copiar una IP a mano sino poner un CNAME hacia ese nombre: si algún día la máquina cambia de host, el A se corrige solo y vos no tenés que enterarte.

AAAA es lo mismo pero para IPv6. Conviene tenerlo si tu servidor lo soporta; algunas redes móviles lo prefieren.

CNAME apunta un nombre a otro nombre, no a una IP. Sirve para que www.midominio.com siga a midominio.com sin duplicar la IP en dos lugares. Regla que rompe mucha gente: no podés poner un CNAME en la raíz del dominio junto a otros registros. La raíz necesita un A. Si tu proveedor te ofrece "CNAME flattening", lo resuelve por detrás, pero la regla original sigue existiendo.

MX dice qué servidor recibe el correo del dominio. Tiene una prioridad: el número más bajo gana. Si ponés MX apuntando a un servidor y el correo no llega, casi siempre es porque quedó un MX viejo con prioridad menor.

TXT guarda texto libre, y por eso terminó siendo el caballo de batalla de la verificación: SPF, DKIM, DMARC y los códigos de verificación de medio internet viven acá.

NS delega una subzona a otros nameservers. Poco frecuente, pero cuando aparece y está mal, el diagnóstico es confuso.

Con listar_registros_dns pedís la foto completa: "mostrame todos los registros de tienda.com". Es el punto de partida de cualquier diagnóstico serio, y también la forma rápida de documentar una configuración antes de tocarla. De acá salen además los record_id, que son lo que necesita cualquier edición.

crear_registro_dns agrega uno nuevo. "Creá un A para api.midominio.com apuntando al VPS de producción." Acá la IA tiene una ventaja concreta: puede consultar primero el destino real del servidor y usarlo, en vez de que lo copies a mano de un panel a otro, que es donde se cuela el typo. Los parámetros son record_type, name (el subdominio, o vacío para la raíz), content, y opcionalmente proxied, ttl y priority.

editar_registro_dns sobrescribe un registro existente, identificado por su record_id. Y hay un detalle importante: es un reemplazo completo, no una fusión. Si el registro tenía TTL, proxy activado y contenido, y vos solo mandás el contenido nuevo, lo demás se redefine con lo que mandes o con los valores por defecto. Cuando edites, pedile a la IA que primero liste el registro actual y después aplique el cambio manteniendo el resto. Es la diferencia entre un cambio quirúrgico y una sorpresa.

Dos límites que conviene conocer antes de chocárselos

Los registros críticos piden confirmación explícita. Crear o editar un NS, un MX, o un A/AAAA en la raíz del dominio falla con un 409 si no mandás confirmado. No es burocracia: un error en cualquiera de esos tres tumba el sitio o el correo de todo el dominio, y la demora de propagación sigue existiendo aunque lo arregles a los treinta segundos. La herramienta te obliga a decir "sí, sé lo que estoy tocando". El resto de los registros —un A de un subdominio, un TXT de verificación— se crean sin fricción.

No existe una herramienta para borrar un registro DNS. Y no es un olvido: es la misma decisión de diseño que hace que no se pueda borrar un blog de forma permanente ni eliminar un VPS. Un agente puede crear y puede sobrescribir; borrar, no. Si necesitás eliminar un registro de verdad, es desde el panel, con un humano mirando.

Hay un límite de llamadas por empresa. El presupuesto de API de Cloudflare es compartido entre todos los clientes de ArduMaker, así que las herramientas de registros están limitadas por empresa. Si aparece el límite, se reintenta después de un rato — no es un error de tu configuración.

El TTL: la parte que nadie planifica y todos sufren

El TTL (Time To Live) es cuántos segundos puede guardar en caché un resolver la respuesta que le diste. Es el número que decide cuánto tarda un cambio en verse.

Y acá está la trampa: el TTL que importa no es el que ponés hoy, es el que estaba puesto antes del cambio. Si un registro tenía TTL de 86400 (24 horas) y lo cambiás, los resolvers que ya lo consultaron van a seguir usando el valor viejo hasta que se les venza la caché. Bajar el TTL en el mismo momento del cambio no sirve de nada: llega tarde.

La forma correcta de planear una migración es al revés:

1. Días antes, bajá el TTL del registro a 300 segundos. Este cambio también tarda lo que dure el TTL viejo en propagarse, por eso hay que hacerlo con anticipación.
2. Esperá a que el TTL viejo se haya vencido en todas partes.
3. Hacé la migración. Ahora el cambio se ve en cinco minutos y no en un día.
4. Después, volvé a subir el TTL a un valor normal para no castigar el rendimiento con consultas innecesarias.

Ese es el procedimiento que separa una migración de servidor sin cortes de un fin de semana perdido.

Un detalle de la herramienta: ttl = 1 significa "automático", no un segundo. Es el valor por defecto y deja que Cloudflare elija. Cuando planifiques una migración, poné el número explícito; el resto del tiempo, automático está bien.

Cuando escuchás "todavía no propagó", casi nunca hay algo propagándose. El DNS no empuja cambios hacia afuera: cada resolver los descubre cuando le vence su caché. Es un sistema de expiración, no de distribución. Por eso los tiempos son tan desparejos entre una red y otra.

Una nota sobre el proxy de Cloudflare, que confunde a mucha gente. Si un registro está proxeado (la nube naranja), el mundo ve las IPs de Cloudflare, no la tuya, y el TTL que hayas puesto pasa a ser irrelevante: Cloudflare responde con el suyo. Es lo que querés para un sitio web, y lo que no querés para un registro que apunte a un servidor de correo o a un servicio que no sea HTTP.

Y tiene una consecuencia concreta en ArduMaker: cuando publicás un subdominio de la zona por defecto para un VPS, el registro se crea proxeado. Si después alguien hace un dig y ve IPs de Cloudflare en vez de la del host, no está roto: está funcionando como corresponde.

TÚ: Cambié el A de la web al servidor nuevo hace dos horas y desde casa sigo viendo el sitio viejo.

IA: listar_dominios_empresa(company_id = 3) -> tienda.com -> domain_id 17

ver_estado_ns_dominio(domain_id = 17) -> conectado correctamente a Cloudflare

listar_registros_dns(domain_id = 17) -> id abc123 A tienda.com -> 203.0.113.44 TTL 86400 id def456 A www -> 203.0.113.10 TTL 86400 (IP vieja)

"Dos cosas. Los nameservers están bien, así que no es eso. El A de la raíz ya apunta al servidor nuevo, pero el de www quedó en la IP vieja: si entrás por www.tienda.com vas al servidor anterior.

Y el TTL de ambos es 86400, o sea 24 horas. Aunque corrijamos www ahora, los resolvers que ya lo consultaron van a seguir con el valor cacheado casi todo el día."

TÚ: Corregí www y bajá los TTL.

IA: editar_registro_dns(domain_id = 17, record_id = "def456", record_type = "A", name = "www", content = "203.0.113.44", ttl = 300) -> ok

editar_registro_dns(domain_id = 17, record_id = "abc123", record_type = "A", name = "tienda.com", content = "203.0.113.44", ttl = 300) -> 409: es un A en la raíz del dominio. Un error acá tumba el sitio entero. Reenviar con confirmado.

"El de www ya está. El de la raíz me pidió confirmación porque es un registro crítico: solo le estoy cambiando el TTL, el contenido queda igual. ¿Confirmo?"

TÚ: Confirmá.

IA: editar_registro_dns(domain_id = 17, record_id = "abc123", record_type = "A", name = "tienda.com", content = "203.0.113.44", ttl = 300, confirmado = True)

"Listo, ambos en TTL 300. Los que nunca visitaron el sitio lo ven bien ya mismo; los que tenían la respuesta vieja en caché la van a soltar dentro de las próximas horas.

Para la próxima migración: bajá el TTL unos días antes y el cambio se ve en cinco minutos."

Checklist antes de tocar el DNS de producción

1. Lista los registros actuales y guárdalos. Si algo sale mal, querés poder volver exactamente al estado anterior, no reconstruirlo de memoria. Y es doblemente importante acá: como la edición es un reemplazo completo, el listado previo es tu única copia del estado original.
2. Verificá los nameservers primero. Es gratis y descarta la causa más común.
3. Mirá el TTL antes de tocar el contenido. Define tu ventana real de riesgo.
4. Revisá si hay registros duplicados o huérfanos. Un www olvidado, un MX viejo con prioridad baja.
5. Cambiá una cosa por vez. Si movés el A y el MX juntos y algo falla, no sabés cuál fue.
6. No hagas cambios de DNS un viernes a la tarde, salvo que te guste trabajar los sábados.

Preguntas frecuentes

¿Cuánto tarda en propagar un cambio de DNS? Lo que dure el TTL que tenía el registro antes del cambio, más el tiempo de caché de cada resolver intermedio. Con TTL de 300 son minutos; con 86400, hasta un día.

¿Puedo poner un CNAME en la raíz de mi dominio? El estándar no lo permite si hay otros registros en la raíz, y siempre los hay. Usá un A, o el "CNAME flattening" del proveedor si lo ofrece.

¿Por qué mi correo no llega aunque el MX esté bien? Revisá si quedó otro MX con prioridad más baja, y si el registro está proxeado por Cloudflare, que no corresponde para correo. Los registros SPF, DKIM y DMARC son harina de otro costal, y de otra guía de esta serie.

¿La IA puede borrar mis registros por error? No: no existe una herramienta para borrar un registro DNS. Puede crear y puede sobrescribir, y sobrescribir un registro crítico —NS, MX, o un A/AAAA de la raíz— le exige confirmación explícita. El riesgo real no es el borrado sino la sobrescritura, porque es un reemplazo completo: por eso vale la costumbre de pedirle que liste el estado actual antes de cambiar nada.

¿Qué pasa si doy de baja un dominio de la plataforma? Menos de lo que parece. Es un borrado blando, reversible dándolo de alta otra vez con el mismo nombre, y no toca la zona de Cloudflare ni sus registros: el sitio y el correo siguen andando. Lo que perdés mientras tanto es poder administrarlo desde ArduMaker.

¿Por qué las herramientas piden un domain_id y no el nombre del dominio? Porque el nombre no es único a nivel plataforma y el id sí. Se lista primero con listar_dominios_empresa y se opera después.

¿Cómo conecto el MCP? Agregando https://mcp.ardumaker.com/mcp en un cliente compatible con el protocolo MCP y autorizándolo con tu cuenta.

Parte de la serie de guías sobre las herramientas del MCP de ArduMaker.