Cómo funcionan los dominios y el DNS: guía para no desarrolladores

Un dominio es el nombre que la gente escribe para llegar a tu web, como example.com, y el DNS (Domain Name System) es el directorio de internet que traduce ese nombre a la ubicación real de tu web. Alquilas el dominio a un registrador y luego añades registros DNS que dicen «la web está allí» y «el correo va por aquí». Conectar un dominio propio a una app consiste sobre todo en añadir el registro correcto en el lugar correcto y esperar a que surta efecto.

Por qué importa cuando construyes con IA

Un creador de apps con IA puede escribir y alojar tu app, pero tu dominio vive fuera de ella —a menudo con una empresa distinta, en un panel de control lleno de tipos de registro desconocidos—. Aquí es donde muchos lanzamientos se atascan: la app está lista, pero el dominio muestra un error, o el correo deja de funcionar misteriosamente tras un cambio de DNS.

Un poco de comprensión te ahorra mucho: sabrás qué registro pide tu host, por qué aún no funciona y cómo evitar romper lo que ya depende de tu dominio (como el correo).

Una analogía cotidiana

Piensa en la lista de contactos de tu móvil.

No recuerdas el número de tu amigo; tocas su nombre y el teléfono lo busca. El DNS hace lo mismo en internet: escribes example.com y el DNS busca el número (la dirección IP) del servidor al que conectarse.

• El dominio es el nombre del contacto.
• El registrador es la empresa que registra oficialmente que ese nombre es tuyo.
• Los registros DNS son los datos guardados bajo ese nombre: teléfono, correo, dirección.
• Los servidores de nombres son la agenda oficial de ese nombre.
• La caché es tu móvil recordando un número durante un tiempo. Si tu amigo cambia de número, algunos móviles seguirán llamando al antiguo hasta que se refresque su copia guardada: eso es la «propagación» del DNS.

Las partes de un nombre de dominio

En app.example.com:

No compras un dominio para siempre; lo registras por un periodo (normalmente un año o más) y lo renuevas. Si lo dejas caducar, otra persona puede registrarlo.

Cómo funciona una búsqueda DNS

Cuando alguien escribe app.example.com:

1. El navegador pregunta a un resolutor DNS —normalmente gestionado por su proveedor de internet o un servicio público— la dirección.
2. Si el resolutor tiene una respuesta reciente en caché, responde al instante.
3. Si no, baja por la jerarquía: los servidores raíz lo dirigen a los servidores de .com, que lo dirigen a los servidores de nombres de tu dominio.
4. Tus servidores de nombres devuelven el registro que configuraste, como un CNAME a tu host o un registro A con una dirección IP.
5. El resolutor guarda la respuesta durante el TTL (tiempo de vida) del registro y se la entrega al navegador, que se conecta al servidor.

Todo esto suele ocurrir en milisegundos.

Tipos de registros DNS que usarás

Algunas reglas que conviene conocer:

• Un CNAME no puede compartir nombre con otros registros. Por eso un CNAME estándar no puede ir en el dominio raíz, que siempre tiene registros NS y otros. Muchos proveedores de DNS ofrecen soluciones alternativas llamadas ALIAS, ANAME o CNAME flattening.
• Los registros TXT hacen mucho trabajo del correo. SPF indica quién puede enviar correo por tu dominio; DKIM publica una clave para verificar firmas; DMARC indica a los receptores qué hacer con el correo que no supera esas comprobaciones.
• Un número MX más bajo significa mayor prioridad. El correo prueba primero el más bajo.

Propagación y TTL

«Propagación» suena a que los cambios se extienden lentamente por internet. Lo que pasa en realidad es caché: los resolutores guardan una copia de cada respuesta durante su TTL y solo vuelven a preguntar cuando expira. Así que:

• Un registro nuevo que nunca se ha consultado a menudo funciona en minutos.
• Cambiar un registro existente tarda hasta su TTL antiguo en verse en todas partes.
• Cambiar los servidores de nombres puede tardar hasta uno o dos días, porque esos registros se guardan en caché durante más tiempo a nivel de TLD.

Un truco útil: antes de un cambio planificado, reduce el TTL del registro (por ejemplo, a unos pocos minutos), espera a que pase el TTL antiguo y haz entonces el cambio.

Un ejemplo práctico: conectar una app de reservas a tu dominio

Tienes tupeluqueria.com. Tu web actual y tu correo de Google Workspace ya usan ese dominio. Has construido una app de reservas y quieres que esté en reservas.tupeluqueria.com.

1. Busca dónde se gestiona tu DNS. Puede ser tu registrador o un proveedor de DNS distinto. Tus registros NS te lo indican.
2. Añade un CNAME para reservas apuntando al destino que te da tu host de la app.
3. Añade cualquier registro TXT que tu host pida para demostrar la propiedad, si lo usa.
4. No toques los registros MX ni los TXT del correo. El correo seguirá funcionando porque no los has tocado.
5. Verifica en tu host cuando el DNS se haya actualizado. El host emite entonces un certificado HTTPS para reservas.tupeluqueria.com.
6. Prueba desde un móvil con datos móviles, que usa un resolutor y una caché distintos a tu wifi de casa.

Si quisieras la app en el dominio raíz tupeluqueria.com, necesitarías registros A o la función ALIAS/flattening de tu proveedor de DNS, y sustituirías tu web actual en ese dominio. Para más pasos, consulta cómo conectar un dominio propio.

Errores comunes y malentendidos

• «El dominio y el alojamiento son lo mismo». El dominio es el nombre; el alojamiento es donde se ejecuta la app. El DNS los une.
• Usar un registro A cuando el host pidió un CNAME (o al revés). Sigue exactamente las instrucciones del host.
• Errores tipográficos en el destino. Un carácter incorrecto en el destino de un CNAME hace fallar la verificación.
• Cambiar de servidores de nombres sin copiar los registros. Mover el DNS a un nuevo proveedor sin recrear los registros MX y TXT es una forma clásica de romper el correo.
• Activar el proxy cuando no debes. Algunos proveedores de DNS, como Cloudflare, pueden hacer de proxy del tráfico. Algunos hosts exigen que el registro esté en «solo DNS» para emitir certificados.
• Borrar registros TXT «desconocidos». Suelen ser de verificación o de seguridad del correo de los que depende algo.
• Dejar que el dominio caduque. Activa la renovación automática y mantén al día la tarjeta de pago.

Qué pedirle a tu creador de apps con IA

El DNS vive fuera de tu código, así que se trata más de qué preguntar sobre él:

• «¿Qué registro DNS exacto necesito para app.midominio.com? Tipo, nombre y valor.»
• «¿Este cambio afectará a mi correo?»
• «Mi dominio muestra un error tras añadir el registro. ¿Qué debo revisar?»
• «Añade la URL canónica correcta y las redirecciones para que www y sin www no muestren la web por duplicado.»
• «Configura el envío de correo desde mi dominio. ¿Qué registros SPF, DKIM y DMARC necesitaré?» Consulta cómo enviar correos desde tu app.

Dominios propios en Mythex

Cada app publicada en Mythex recibe una dirección tunombre.mythex.app. En Pro puedes usar tu propio dominio en su lugar: compra uno dentro de Mythex (el registro se factura aparte, y el DNS de los dominios comprados se gestiona por ti), o conecta uno que ya tengas añadiendo un CNAME desde un subdominio como app.example.com a la dirección tunombre.mythex.app de tu app, y luego haz clic en Verificar. El HTTPS se emite automáticamente. Si tu DNS está en Cloudflare, pon ese registro en «solo DNS». Se recomiendan subdominios; los dominios raíz dependen de que tu proveedor de DNS admita ALIAS o flattening. La documentación de dominios propios recorre cada paso, y los precios muestran lo que incluye Pro.

Preguntas