DNS sem mistério: registros, nameservers e propagação, administrados por conversação

Publicado em 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.

O DNS é o sistema que mais pessoas mexem sem entender totalmente, e o que mais arruína noites. Alguém muda um registro numa sexta-feira, "ainda não propagou", e na segunda-feira o site continua fora do ar por um motivo que ninguém verifica: o TTL de 86400 que ficou definido há dois anos.

Este guia cobre duas coisas ao mesmo tempo. Primeiro, como o DNS realmente funciona, sem as simplificações que depois saem caras. Segundo, como administrar domínios e registros com o MCP da ArduMaker, pedindo isso a uma IA em linguagem natural.

Ferramentas cobertas: criar_dominio_empresa, listar_dominios_empresa, ver_dominio_empresa, eliminar_dominio_empresa, ver_estado_ns_dominio, listar_registros_dns, criar_registro_dns e editar_registro_dns.

Um detalhe de forma que evita frustrações: as ferramentas de domínios trabalham com ids numéricos, não com nomes. criar_dominio_empresa e listar_dominios_empresa pedem o company_id da empresa; o resto pede o domain_id que sai dessa listagem. Não existe "passe o domínio tienda.com": primeiro se lista, depois se opera sobre o id.

Lo primero que hay que entender: los nameservers mandam

Un domínio não "vive" em um só lugar. Vive para onde apontam seus nameservers, e isso é definido no registrador onde você o comprou.

Esta é a fonte da metade dos problemas de DNS: alguém edita registros em um painel, não vê nenhuma mudança, e não percebe que o domínio ainda aponta para os nameservers do registrador anterior. Os registros estão perfeitos... em um servidor que ninguém consulta.

crear_dominio_empresa registra o domínio na plataforma e cria sua zona no Cloudflare. Ao fazer isso, ele retorna os nameservers que você precisa carregar no seu registrador. Esse passo é manual e inevitável: ninguém pode alterar os nameservers do seu domínio exceto você, a partir de onde o comprou. Detalhe útil: se o domínio já havia sido cadastrado para a mesma empresa e foi excluído, esta chamada o reativa em vez de criar um duplicado.

ver_estado_ns_dominio é a ferramenta que vale a pena usar antes de se quebrar a cabeça. Consulta ao vivo no Cloudflare se o domínio já está conectado ou ainda está pendente, e atualiza o status salvo. Quando alguém diz "mudei o registro e nada acontece", esta é a primeira pergunta que se deve fazer à IA: "este domínio já tem os nameservers apontando corretamente?".

A alteração de nameservers pode demorar de minutos a 48 horas, dependendo do TLD. Durante esse período, parte do mundo te vê no servidor antigo e parte no novo. Não é um erro: é assim que funciona.

listar_dominios_empresa e ver_dominio_empresa são o inventário. ver_dominio_empresa traz também o estado ao vivo da zona no Cloudflare, e o faz em modo best effort: se o Cloudflare não responder, ele ainda te devolve os dados do domínio com um cloudflare_error explicando por que falta o restante. Uso típico e pouco glamoroso, mas valioso: uma vez por trimestre, perguntar "quais domínios temos e qual é o estado deles?" e descobrir os dois que vencem no mês que vem e ninguém estava olhando.

eliminar_dominio_empresa dá baixa no domínio da plataforma, e convém saber exatamente o que faz e o que não faz, porque soa mais grave do que é:

• É um apagamento suave e é reversível. Você volta a chamar crear_dominio_empresa com o mesmo nome e o domínio revive.
• Não toca a zona do Cloudflare nem seus registros. O ID da zona é conservado e os registros DNS ficam onde estavam. O site e o e-mail continuam funcionando exatamente igual.
• O que você perde é a administração desde o ArduMaker, não o serviço. Enquanto o domínio estiver dado de baixa, você não vai conseguir listar nem editar seus registros com estas ferramentas.

E, claro, apagá-lo aqui não muda nada no seu registrador: os nameservers continuam apontando para onde apontavam.

Os registros que você vai usar de verdade

Da longa lista de tipos de registro DNS, no dia a dia se usam cinco ou seis. Vale a pena conhecê-los bem.

A aponta um nome para um endereço IPv4. É o mais comum: midominio.com → 203.0.113.10.

Uma precisão importante se o destino for um VPS da ArduMaker: o VPS não tem IP pública própria. É um container dentro de um host pai compartilhado, e o IP que a internet vê é o do host. Cada VPS tem um nome DNS próprio do estilo <slug>.arducloud.com, com um A que aponta para esse IP. Por isso, para conectar seu domínio ao seu servidor, o mais robusto geralmente não é copiar um IP manualmente, mas sim colocar um CNAME para esse nome: se um dia a máquina mudar de host, o A se corrige sozinho e você não precisa ficar sabendo.

AAAA é a mesma coisa, mas para IPv6. Convém ter se o seu servidor suportar; algumas redes móveis preferem.

CNAME aponta um nome para outro nome, não para um IP. Serve para que www.midominio.com siga midominio.com sem duplicar o IP em dois lugares. Regra que muita gente quebra: não é possível colocar um CNAME na raiz do domínio junto com outros registros. A raiz precisa de um A. Se o seu provedor oferecer "CNAME flattening", ele resolve por trás dos panos, mas a regra original continua existindo.

MX diz qual servidor recebe o e-mail do domínio. Tem uma prioridade: o número mais baixo vence. Se você apontar um MX para um servidor e o e-mail não chegar, quase sempre é porque ficou um MX antigo com prioridade menor.

TXT guarda texto livre, e por isso acabou se tornando o cavalo de batalha da verificação: SPF, DKIM, DMARC e os códigos de verificação de metade da internet vivem aqui.

NS delega uma subzona para outros nameservers. Pouco frequente, mas quando aparece e está errado, o diagnóstico é confuso.

Com listar_registros_dns você pede a foto completa: "mostre todos os registros de tienda.com". É o ponto de partida de qualquer diagnóstico sério, e também a forma rápida de documentar uma configuração antes de mexer nela. Daqui saem também os record_id, que são o que qualquer edição precisa.

crear_registro_dns adiciona um novo. "Crie um A para api.midominio.com apontando para o VPS de produção." Aqui a IA tem uma vantagem concreta: pode consultar primeiro o destino real do servidor e usá-lo, em vez de você copiá-lo manualmente de um painel para outro, onde o erro de digitação se esconde. Os parâmetros são record_type, name (o subdomínio, ou vazio para a raiz), content, e opcionalmente proxied, ttl e priority.

editar_registro_dns sobrescreve um registro existente, identificado por seu record_id. E há um detalhe importante: é uma substituição completa, não uma mesclagem. Se o registro tinha TTL, proxy ativado e conteúdo, e você enviar apenas o novo conteúdo, o restante será redefinido com o que você enviar ou com os valores padrão. Ao editar, peça à IA que primeiro liste o registro atual e depois aplique a mudança mantendo o restante. É a diferença entre uma mudança cirúrgica e uma surpresa.

Dois limites que vale a pena conhecer antes de esbarrar neles

Registros críticos exigem confirmação explícita. Criar ou editar um NS, um MX, ou um A/AAAA na raiz do domínio falha com um 409 se você não enviar confirmado. Não é burocracia: um erro em qualquer um desses três derruba o site ou o e-mail de todo o domínio, e o atraso de propagação continua existindo mesmo que você conserte em trinta segundos. A ferramenta obriga você a dizer "sim, sei o que estou tocando". O restante dos registros — um A de um subdomínio, um TXT de verificação — são criados sem atrito.

Não existe uma ferramenta para excluir um registro DNS. E não é um esquecimento: é a mesma decisão de design que impede excluir um blog permanentemente ou eliminar um VPS. Um agente pode criar e sobrescrever; excluir, não. Se precisar remover um registro de verdade, é pelo painel, com um humano olhando.

Há um limite de chamadas por empresa. O orçamento da API da Cloudflare é compartilhado entre todos os clientes da ArduMaker, então as ferramentas de registros são limitadas por empresa. Se o limite aparecer, tente novamente depois de um tempo — não é um erro da sua configuração.

O TTL: a parte que ninguém planeja e todos sofrem

O TTL (Time To Live) é quantos segundos um resolver pode guardar em cache a resposta que você deu. É o número que decide quanto tempo demora para uma mudança ser vista.

E aqui está a armadilha: o TTL que importa não é o que você coloca hoje, é o que estava definido antes da mudança. Se um registro tinha TTL de 86400 (24 horas) e você o altera, os resolvers que já o consultaram continuarão usando o valor antigo até que o cache expire. Baixar o TTL no mesmo momento da mudança não adianta nada: chega tarde.

A forma correta de planejar uma migração é ao contrário:

1. Dias antes, baixe o TTL do registro para 300 segundos. Essa mudança também demora o tempo que o TTL antigo levar para se propagar, por isso deve ser feita com antecedência.
2. Espere até que o TTL antigo tenha expirado em todos os lugares.
3. Faça a migração. Agora a mudança é vista em cinco minutos e não em um dia.
4. Depois, volte a subir o TTL para um valor normal para não prejudicar o desempenho com consultas desnecessárias.

Esse é o procedimento que separa uma migração de servidor sem interrupções de um fim de semana perdido.

Um detalhe da ferramenta: ttl = 1 significa "automático", não um segundo. É o valor padrão e deixa que o Cloudflare escolha. Quando planejar uma migração, coloque o número explícito; o resto do tempo, automático está bem.

Quando você ouve "ainda não propagou", quase nunca há algo se propagando. O DNS não envia mudanças para fora: cada resolvedor as descobre quando seu cache expira. É um sistema de expiração, não de distribuição. Por isso os tempos são tão desiguais entre uma rede e outra.

Uma nota sobre o proxy da Cloudflare, que confunde muita gente. Se um registro está proxificado (a nuvem laranja), o mundo vê os IPs da Cloudflare, não o seu, e o TTL que você definiu se torna irrelevante: a Cloudflare responde com o dela. É o que você quer para um site, e o que não quer para um registro que aponta para um servidor de e-mail ou para um serviço que não seja HTTP.

E isso tem uma consequência concreta no ArduMaker: quando você publica um subdomínio da zona padrão para um VPS, o registro é criado proxificado. Se depois alguém fizer um dig e vir IPs da Cloudflare em vez da do host, não está quebrado: está funcionando como deveria.

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 o DNS de produção

1. Liste os registros atuais e salve-os. Se algo der errado, você quer poder voltar exatamente ao estado anterior, não reconstruí-lo de memória. E é duplamente importante aqui: como a edição é uma substituição completa, a listagem prévia é sua única cópia do estado original.
2. Verifique os nameservers primeiro. É grátis e descarta a causa mais comum.
3. Olhe o TTL antes de tocar no conteúdo. Define sua janela real de risco.
4. Revise se há registros duplicados ou órfãos. Um www esquecido, um MX antigo com prioridade baixa.
5. Mude uma coisa por vez. Se mover o A e o MX juntos e algo falhar, você não saberá qual foi.
6. Não faça alterações de DNS na sexta-feira à tarde, a menos que goste de trabalhar aos sábados.

Perguntas frequentes

Quanto tempo demora para propagar uma alteração de DNS? O tempo que durar o TTL que o registro tinha antes da alteração, mais o tempo de cache de cada resolvedor intermediário. Com TTL de 300 são minutos; com 86400, até um dia.

Posso colocar um CNAME na raiz do meu domínio? O padrão não permite se houver outros registros na raiz, e sempre há. Use um A, ou o "CNAME flattening" do provedor, se ele oferecer.

Por que meu e-mail não chega mesmo com o MX correto? Verifique se ficou algum outro MX com prioridade mais baixa, e se o registro está proxied pelo Cloudflare, o que não é adequado para e-mail. Os registros SPF, DKIM e DMARC são outra história, e de outro guia desta série.

A IA pode apagar meus registros por erro? Não: não existe uma ferramenta para apagar um registro DNS. Ela pode criar e pode sobrescrever, e sobrescrever um registro crítico —NS, MX, ou um A/AAAA da raiz— exige confirmação explícita. O risco real não é a exclusão, mas a sobrescrita, porque é uma substituição completa: por isso vale o costume de pedir que ela liste o estado atual antes de mudar qualquer coisa.

O que acontece se eu der baixa em um domínio da plataforma? Menos do que parece. É uma exclusão suave, reversível reativando-o com o mesmo nome, e não toca na zona do Cloudflare nem em seus registros: o site e o e-mail continuam funcionando. O que você perde enquanto isso é a capacidade de gerenciá-lo pelo ArduMaker.

Por que as ferramentas pedem um domain_id e não o nome do domínio? Porque o nome não é único no nível da plataforma e o id é. Primeiro lista-se com listar_dominios_empresa e depois se opera.

Como conecto o MCP? Adicionando https://mcp.ardumaker.com/mcp em um cliente compatível com o protocolo MCP e autorizando com sua conta.

Parte da série de guias sobre as ferramentas do MCP do ArduMaker.