Registros DNS A, AAAA, CNAME, MX y TXT: ejemplos de cuándo usar cada uno
Publicado el 2026-10-26 por frfrand
Tipos de registros DNS y errores comunes al conectar web y correo
Te dan un dominio y alguien dice «poné la IP en el DNS». Eso alcanza para algunos sitios, pero correo, validación de servicios y subdominios necesitan registros diferentes. Entender cinco tipos te evita muchos cambios innecesarios.
Vamos a convertirlo en un procedimiento que puedas usar en un VPS real. El objetivo es entender por qué funciona, cómo probarlo y qué problema aparece si una parte queda mal configurada.
Qué significa A, AAAA, CNAME, MX y TXT y cuándo lo necesitás
A apunta un nombre a IPv4; AAAA a IPv6; CNAME crea un alias DNS para otro nombre en condiciones compatibles; MX indica servidores de recepción de correo; TXT lleva información textual como verificaciones, SPF, DKIM o DMARC según su formato.
Antes de cambiar nada en producción, anotá el estado actual: IP, dominio, puerto, servicio afectado y hora del último deploy. Una modificación aislada es fácil de comprobar; cinco cambios simultáneos hacen más difícil reconstruir lo ocurrido.
Configuración o comandos de ejemplo
dig ejemplo.com A +short
dig ejemplo.com AAAA +short
dig www.ejemplo.com CNAME +short
dig ejemplo.com MX +short
dig ejemplo.com TXT +short
# DMARC suele consultarse como TXT
dig _dmarc.ejemplo.com TXT +shortLos dominios, IP, rutas y nombres son ilustrativos. No copies una configuración entera encima de la actual sin comparar primero. En los ejemplos que incluyen puertos o firewall, asegurate de conservar el acceso administrativo.
Cómo lo haría paso a paso
- Preparación. Para publicar una web en VPS, configura A o AAAA hacia direcciones que realmente atiendan el sitio.
- Paso 2. Si creas
wwwcomo CNAME, comprueba restricciones y cómo lo admite tu proveedor DNS. - Paso 3. Para correo, configura MX hacia hosts adecuados y verifica reputación, SPF, DKIM y DMARC.
- Paso 4. No crees dos registros incompatibles en el mismo nombre solo porque un tutorial lo hizo.
- Verificación. Verifica la respuesta de DNS y después prueba el servicio real: la resolución no garantiza que HTTP o SMTP funcione.
Cuando termines, comprueba la operación real desde otra conexión. Por ejemplo, para una API no alcanza con abrir el navegador: ejecuta una petición de lectura, una escritura en una base de prueba y consulta los logs del proceso.
Ejemplo de un proyecto de verdad
Una agencia conecta api.cliente.com a FastAPI en ArduMaker y conserva el correo de Google Workspace. Solo necesita cambiar el registro de la API; tocar MX sin motivo puede cortar el correo del cliente.
La lección es sencilla: una configuración de infraestructura no vive aislada de la aplicación. El frontend, el servidor, la base de datos y los workers se conectan, así que medir dónde empieza el fallo es más útil que reiniciar todo.
El error que evitaría
Un CNAME en el apex del dominio tiene restricciones DNS estándar, aunque algunos proveedores ofrecen flattening o alias propios. No asumas que toda interfaz de DNS implementa lo mismo.
Cuando trabajás con servidores de clientes, guardá un respaldo o procedimiento de reversión antes de cambios que afecten datos, red o certificados. Y si no sabés qué permisos necesita una operación, evitá ejecutarla como root sólo para que deje de mostrar errores.
¿Cómo se relaciona con ArduMaker?
Al administrar dominios y VPS desde ArduMaker, diferenciá registros web de correo. Publicar una API no debería implicar alterar configuraciones MX de servicios existentes.
En un caso típico podés crear un VPS para la aplicación, desplegar desde Git, asociar dominio HTTPS y administrar el backend y las bases necesarias. Las herramientas ayudan a centralizar operaciones, pero hay que entender qué puerto y proceso cumple cada función.
Preguntas que aparecen cuando lo probás
¿Cómo sé si el fallo es de DNS o del servicio? Consultá primero la resolución, después la conexión al puerto y finalmente la respuesta de aplicación. Ese orden evita confundir problemas diferentes.
¿Puedo exponer una base para que sea más fácil mantenerla? Mejor diseñá acceso privado o túneles autenticados cuando sea posible. Exponer un puerto no reemplaza los permisos del motor ni el firewall.
¿Qué debería documentar? La configuración esperada, cómo se comprueba y cómo volver al estado anterior. Ese documento te ayuda más que una lista de comandos sin contexto.
Referencias
En resumen: una buena configuración de red o servidor es la que podés explicar, verificar y recuperar cuando algo falla.