DNS without mystery: records, nameservers and propagation, managed by conversation

Published on 2026-08-25 by 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.

DNS is the system that most people touch without fully understanding, and the one that ruins the most nights. Someone changes a record on a Friday, "it hasn't propagated yet," and on Monday the site is still down for a reason no one checks: the 86400 TTL that was left in place two years ago.

This guide covers two things at once. First, how DNS actually works, without the simplifications that end up being costly. Second, how to manage domains and records using ArduMaker's MCP, asking an AI in natural language.

Tools covered: 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.

A formatting detail that avoids frustration: domain tools work with numeric IDs, not names. crear_dominio_empresa and listar_dominios_empresa require the company_id of the company; the rest require the domain_id that comes from that listing. There is no "pass the domain tienda.com": first you list, then you operate on the ID.

The first thing to understand: nameservers rule

A domain does not "live" in a single place. It lives where its nameservers point, and that is defined at the registrar where you bought it.

This is the source of half of DNS problems: someone edits records in a panel, sees no change, and does not realize that the domain still points to the previous registrar's nameservers. The records are perfect... on a server that no one queries.

crear_dominio_empresa registers the domain on the platform and creates its zone in Cloudflare. Doing so returns the nameservers that you have to load at your registrar. That step is manual and unavoidable: no one can change your domain's nameservers except you, from where you bought it. Useful detail: if the domain had already been registered for the same company and was deleted, this call reactivates it instead of creating a duplicate.

ver_estado_ns_dominio is the tool worth using before losing your mind. It queries Cloudflare live to check if the domain is already connected or still pending, and updates the saved status. When someone says "I changed the record and nothing happens", this is the first question to ask the AI: "Does this domain already have the nameservers pointing correctly?".

Changing nameservers can take anywhere from minutes to 48 hours, depending on the TLD. During that period, part of the world sees you on the old server and part on the new one. It's not an error: it's how it works.

listar_dominios_empresa and ver_dominio_empresa are the inventory. ver_dominio_empresa also brings the live status of the zone in Cloudflare, and it does so in best effort mode: if Cloudflare doesn't respond, it still returns the domain data with a cloudflare_error explaining why the rest is missing. Typical use, not very glamorous but valuable: once per quarter, ask "what domains do we have and what is their status?" and discover the two that expire next month and nobody was watching.

eliminar_dominio_empresa removes the domain from the platform, and it's worth knowing exactly what it does and doesn't do, because it sounds more serious than it is:

• It's a soft delete and it's reversible. You call crear_dominio_empresa again with the same name and the domain revives.
• It doesn't touch the Cloudflare zone or its records. The zone ID is kept and DNS records stay where they were. The site and email keep working exactly the same.
• What you lose is administration from ArduMaker, not the service. While the domain is removed, you won't be able to list or edit its records with these tools.

And of course, deleting it here doesn't change anything at your registrar: the nameservers keep pointing wherever they pointed.

The records you will actually use

From the long list of DNS record types, five or six are used on a daily basis. It is worth knowing them well.

A points a name to an IPv4 address. It is the most common: midominio.com → 203.0.113.10.

An important detail if the destination is an ArduMaker VPS: the VPS does not have its own public IP. It is a container within a shared parent host, and the IP that the internet sees is that of the host. Each VPS does have its own DNS name in the style <slug>.arducloud.com, with an A record pointing to that IP. Therefore, to connect your domain to your server, the most robust option is usually not to manually copy an IP but to set up a CNAME to that name: if the machine changes hosts one day, the A record corrects itself and you don't have to find out.

AAAA is the same but for IPv6. It is convenient to have it if your server supports it; some mobile networks prefer it.

CNAME points a name to another name, not to an IP. It is used so that www.midominio.com follows midominio.com without duplicating the IP in two places. A rule that many people break: you cannot put a CNAME at the root of the domain alongside other records. The root needs an A record. If your provider offers "CNAME flattening", it solves it behind the scenes, but the original rule still exists.

MX indicates which server receives email for the domain. It has a priority: the lowest number wins. If you set an MX pointing to a server and email doesn't arrive, it's almost always because an old MX with lower priority remained.

TXT stores free text, and that's why it ended up being the workhorse of verification: SPF, DKIM, DMARC, and verification codes from half the internet live here.

NS delegates a subzone to other nameservers. Infrequent, but when it appears and is wrong, the diagnosis is confusing.

With listar_registros_dns you request the full picture: "show me all records for tienda.com". It's the starting point of any serious diagnosis, and also the quick way to document a configuration before touching it. From here come the record_ids, which are what any edit needs.

crear_registro_dns adds a new one. "Create an A for api.midominio.com pointing to the production VPS." Here the AI has a concrete advantage: it can first consult the server's real destination and use it, instead of you copying it manually from one panel to another, where typos creep in. The parameters are record_type, name (the subdomain, or empty for the root), content, and optionally proxied, ttl and priority.

editar_registro_dns overwrites an existing record, identified by its record_id. And there’s an important detail: it’s a full replacement, not a merge. If the record had TTL, proxy enabled, and content, and you only send the new content, the rest is reset to what you sent or to the default values. When editing, ask the AI to first list the current record and then apply the change while preserving the rest. That’s the difference between a surgical change and a surprise.

Two limits worth knowing before hitting them

Critical records require explicit confirmation. Creating or editing an NS, an MX, or an A/AAAA at the root of the domain fails with a 409 if you don’t include confirmado. It’s not bureaucracy: a mistake in any of those three can bring down the site or email for the entire domain, and propagation delay still applies even if you fix it in thirty seconds. The tool forces you to say “yes, I know what I’m touching.” The rest of the records —an A on a subdomain, a verification TXT— are created without friction.

There is no tool to delete a DNS record. And it’s not an oversight: it’s the same design decision that prevents permanently deleting a blog or removing a VPS. An agent can create and can overwrite; it cannot delete. If you truly need to remove a record, you must do it from the panel, with a human watching.

There is a call limit per company. The Cloudflare API budget is shared among all ArduMaker customers, so logging tools are limited per company. If the limit appears, retry after a while — it is not an error in your configuration.

The TTL: the part nobody plans and everyone suffers

The TTL (Time To Live) is how many seconds a resolver can cache the response you gave it. It's the number that decides how long a change takes to appear.

And here's the trap: the TTL that matters isn't the one you set today, it's the one that was set before the change. If a record had a TTL of 86400 (24 hours) and you change it, resolvers that already queried it will keep using the old value until their cache expires. Lowering the TTL at the same time as the change doesn't help: it's too late.

The right way to plan a migration is backwards:

1. Days before, lower the record's TTL to 300 seconds. This change also takes as long as the old TTL to propagate, which is why you have to do it in advance.
2. Wait for the old TTL to expire everywhere.
3. Perform the migration. Now the change appears in five minutes instead of a day.
4. Afterwards, raise the TTL back to a normal value so you don't hurt performance with unnecessary queries.

That's the procedure that separates a server migration without downtime from a lost weekend.

A tool detail: ttl = 1 means "automatic", not one second. It's the default value and lets Cloudflare choose. When planning a migration, set the explicit number; the rest of the time, automatic is fine.

When you hear "it hasn't propagated yet," there is almost never anything propagating. DNS does not push changes outward: each resolver discovers them when its cache expires. It is an expiration system, not a distribution system. That is why times are so uneven between one network and another.

A note about Cloudflare's proxy, which confuses many people. If a record is proxied (the orange cloud), the world sees Cloudflare's IPs, not yours, and the TTL you set becomes irrelevant: Cloudflare responds with its own. It is what you want for a website, and what you do not want for a record pointing to a mail server or to a service that is not HTTP.

And it has a concrete consequence in ArduMaker: when you publish a subdomain of the default zone for a VPS, the record is created proxied. If someone then runs a dig and sees Cloudflare IPs instead of the host's IP, it is not broken: it is working as intended.

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 before touching production DNS

1. List the current records and save them. If something goes wrong, you want to be able to return exactly to the previous state, not reconstruct it from memory. And it is doubly important here: since editing is a complete replacement, the previous list is your only copy of the original state.
2. Verify the nameservers first. It is free and rules out the most common cause.
3. Check the TTL before touching the content. It defines your actual risk window.
4. Review if there are duplicate or orphan records. A forgotten www, an old MX with low priority.
5. Change one thing at a time. If you move the A and MX together and something fails, you won't know which one was the cause.
6. Do not make DNS changes on a Friday afternoon, unless you like working on Saturdays.

Frequently asked questions

How long does a DNS change take to propagate? As long as the TTL the record had before the change, plus the cache time of each intermediate resolver. With a TTL of 300, it's minutes; with 86400, up to a day.

Can I put a CNAME at the root of my domain? The standard does not allow it if there are other records at the root, and there always are. Use an A record, or the provider's "CNAME flattening" if it offers it.

Why is my email not arriving even though the MX is correct? Check if another MX with lower priority remained, and if the record is proxied by Cloudflare, which is not appropriate for email. SPF, DKIM, and DMARC records are another matter, and another guide in this series.

Can AI delete my records by mistake? No: there is no tool to delete a DNS record. It can create and it can overwrite, and overwriting a critical record —NS, MX, or a root A/AAAA— requires explicit confirmation. The real risk is not deletion but overwriting, because it is a complete replacement: that is why it is worth asking it to list the current state before changing anything.

What happens if I unsubscribe a domain from the platform? Less than it seems. It is a soft deletion, reversible by subscribing it again with the same name, and it does not touch the Cloudflare zone nor its records: the site and email keep working. What you lose meanwhile is the ability to manage it from ArduMaker.

Why do tools ask for a domain_id and not the domain name? Because the name is not unique at platform level and the id is. It is listed first with listar_dominios_empresa and then operated on.

How do I connect the MCP? By adding https://mcp.ardumaker.com/mcp in a client compatible with the MCP protocol and authorizing it with your account.

Part of the series of guides on the ArduMaker MCP tools.