Un registro A asocia un nombre DNS con una dirección IPv4. Por ejemplo, www.example.com puede resolver a 203.0.113.20. El registro no conoce la ruta de una web, el protocolo HTTP ni una carpeta concreta: example.com/app no es un nombre que pueda apuntarse mediante A.
La entrada correcta depende de la zona autoritativa y del nombre que se quiera publicar. Un error en el nombre puede hacer que la raíz funcione mientras el subdominio siga sin resolver.
Nombre, zona y dirección
En el dominio raíz, algunos paneles representan el nombre como @; otros dejan el campo vacío o escriben el dominio completo. Para www, el nombre suele ser el subdominio y el valor es una IPv4. La interfaz puede ocultar parte del nombre, por lo que conviene comprobar el FQDN que realmente publica.
Una dirección IPv4 debe tener un formato válido y corresponder al servidor que atiende ese nombre. Apuntar al servidor correcto no configura por sí solo el sitio virtual, el certificado ni las redirecciones.
Raíz, subdominios y varios destinos
Es posible que el dominio raíz y www tengan registros distintos. También pueden existir varios A para repartir consultas entre direcciones. Ese mecanismo no equivale automáticamente a un balanceador con comprobación de salud: un resolver puede conservar una dirección en caché aunque el servidor deje de responder.
Si un servicio depende de una única dirección, documenta el propósito de cada entrada y evita duplicados creados por migraciones anteriores. Un A adicional puede dirigir parte del tráfico a un entorno que no está preparado.
TTL, caché y cambio de IP
El TTL indica cuánto tiempo puede conservarse una respuesta en caché, sujeto al comportamiento del resolver. Al cambiar la IP, algunos usuarios consultarán el valor nuevo y otros seguirán viendo el anterior hasta que expire su caché. No existe una hora universal en la que todos los resolvers cambien a la vez.
Antes de migrar, reduce el TTL con antelación si la política del proveedor lo permite y vuelve a aumentarlo cuando el cambio esté confirmado. Guarda la dirección anterior y define cuándo se puede restaurar.
A frente a AAAA y CNAME
A publica IPv4. AAAA publica IPv6. CNAME crea un alias hacia otro nombre y no debe confundirse con un valor que contenga una URL o una dirección en el campo equivocado. La elección depende de si se controla una dirección o se quiere seguir el nombre canónico de otro servicio.
Autoridad y comprobación
El panel donde editas la zona no siempre es el servidor autoritativo que responde al público. Comprueba los nameservers delegados y compara la respuesta autoritativa con la de varios resolvers. Si solo se consulta desde el mismo equipo, la caché puede ocultar el cambio.
Errores habituales
Los fallos más frecuentes son escribir una ruta en el valor, usar una IPv6 en un registro A, editar una zona que no está delegada, olvidar el punto final en un nombre según el panel o cambiar la IP sin revisar certificados, correo y subdominios. Un registro A solo resuelve la relación nombre-IPv4.
Qué revisar después de cambiar una dirección IP
Comprueba raíz y subdominios, respuestas desde varios resolvers, servicio HTTP, HTTPS, correo y aplicaciones que usen nombres internos. Documenta el TTL y la hora del cambio. Si el sitio no responde, separa un problema DNS de otro del servidor: que el nombre resuelva no demuestra que la aplicación esté configurada.
El mismo nombre puede tener varias respuestas
Un dominio puede publicar más de un A para distribuir consultas o mantener varias direcciones. El resolver puede devolverlas en un orden variable y el cliente no recibe una comprobación automática de salud. Si una dirección deja de servir, el registro no desaparece por sí solo.
En el dominio raíz, el proveedor puede sintetizar respuestas o combinar A y AAAA. Revisa la zona autoritativa para saber qué se publica realmente y comprueba que una dirección IPv6 no se haya introducido por error en el tipo A.
Qué ocurre al cambiar de servidor
Prepara el nuevo servidor antes de modificar la dirección: virtual host, certificado, firewall, aplicación y datos deben estar listos. Reduce TTL con antelación solo si la autoridad de la zona lo permite y conserva la IP anterior durante el periodo de transición. Algunos clientes seguirán usando la respuesta cacheada.
Verificación posterior del cambio
Comprueba resolución autoritativa y desde varios resolvers, raíz y subdominios, HTTP/HTTPS, correo y servicios de terceros. Si el nombre ya resuelve a la IP nueva pero la web falla, el problema está en el servidor o la aplicación, no en la ruta DNS. Un A relaciona nombre e IPv4; no configura el sitio ni sus rutas.
TTL no es tiempo de propagación fijo
El TTL se aplica a la respuesta que un resolver guarda en caché, pero pueden existir caches intermedias, consultas negativas y reglas propias del proveedor. Si se reduce demasiado, aumentan las consultas autoritativas y no todos los clientes cambiarán al mismo instante. Usa un valor razonable para la transición y comprueba el resultado desde redes diferentes.
Los registros A también pueden coexistir con un CNAME en nombres distintos, pero un mismo nombre no debe recibir configuraciones contradictorias. Revisa la zona completa para evitar que una entrada antigua siga dirigiendo parte del tráfico.
Diagnóstico de una resolución incorrecta
Compara la respuesta autoritativa, la respuesta del resolver y la conexión a la dirección devuelta. Si varios resolvers muestran la misma IP antigua, la caché puede explicar el resultado; si la autoridad ya publica la IP nueva y solo falla el servicio, revisa servidor web, firewall y configuración del host.