Saltar al contenido
Blog

Cómo conectar tu propio dominio a un motor de reservas

Redacción de Tekravel

La web está lista. El logo es el correcto, los márgenes están configurados, una reserva de prueba pasó sin problemas en el subdominio de la plataforma y alguien en la oficina ya envió el enlace a tres clientes. Entonces llega la pregunta obvia: ¿por qué la dirección sigue llevando el nombre de otro? Esta guía explica cómo conectar tu propio dominio a un motor de reservas sin contratar a nadie: qué estás cambiando de verdad, los dos o tres registros que intervienen, por qué el candado aparece más tarde de lo que esperas y el único ajuste que, si lo tocas, rompe en silencio el correo de la empresa.

No necesitas entender DNS a fondo. Te basta una idea: tu nombre de dominio es un cartel indicador y lo estás orientando hacia un edificio nuevo. Todo lo demás es el detalle de esa idea.

Dónde vive realmente tu dominio

Pueden intervenir hasta tres empresas distintas, y la mayoría de los dueños de agencia solo conoce una. El registrador es donde compraste el nombre y pagas la renovación anual. El proveedor de DNS es donde se editan los registros de ese nombre: a menudo la misma empresa que el registrador, a veces no, sobre todo si hace años un diseñador web lo montó todo y trasladó el nombre a un servicio de DNS aparte. El alojamiento web es donde funciona tu web actual.

Los registros que vas a añadir van al proveedor de DNS. Así que, antes que nada, averigua quién es. Entra en el panel del registrador y mira los servidores de nombres (nameservers) que figuran en el dominio. Si pertenecen al registrador, editas los registros allí. Si apuntan a otro sitio, ese otro sitio es donde trabajas. Unos minutos aquí ahorran una tarde editando registros en un panel que nadie consulta.

Dominio raíz o subdominio: decide antes de tocar nada

El dominio raíz (apex, o dominio desnudo) es tumarca.es sin nada delante. Un subdominio es cualquier cosa con un prefijo: www.tumarca.es, reservas.tumarca.es, viajes.tumarca.es. La plataforma acepta ambos, pero la elección cambia el registro que añades.

El motivo es antiguo y no se negocia. El dominio raíz ya lleva los registros que definen el propio dominio, y el DNS no permite que un CNAME comparta nombre con ningún otro registro. Por eso un dominio raíz se apunta con un registro A directamente a una dirección IP, mientras que un subdominio se apunta con un CNAME a otro nombre de host.

Raíz (tumarca.es)Subdominio (reservas.tumarca.es)
Registro que añadesRegistro A hacia una dirección IPCNAME hacia un nombre de host de la plataforma
Lo que teclea el clienteLa dirección más corta posibleUna palabra más, que importa menos cuando el cliente llega por un enlace
Tu web actualTiene que salir de la raíz, o la web de reservas la sustituyeSe queda exactamente donde está
Correo de la empresaIntacto mientras no toques los registros MXIntacto
Encaja conUna agencia cuya web ES la web de reservasUna agencia con web corporativa, blog o CMS que quiere conservar

La mayoría de las agencias que ya tienen web deberían empezar con un subdominio. La fila discutible es la segunda: algunos dueños sienten que un subdominio parece menos consolidado. Es una opinión razonable, y pesa menos cuando la mayoría de los clientes llega desde un enlace de WhatsApp o Instagram en lugar de teclear la dirección.

Los registros que añades y para qué sirve cada uno

El paso guiado de DNS muestra los valores exactos para tu dominio. Cópialos de ahí, no de ningún artículo, este incluido. Lo que sigue explica para qué sirve cada registro, para que la pantalla tenga sentido cuando la veas.

  • CNAME, para un subdominio. Nombre: el prefijo elegido, por ejemplo reservas. Valor: el nombre de host de la plataforma que te da el paso de DNS. Dice «este nombre es un alias de aquel», así que, si los servidores de la plataforma cambian de sitio, tu registro sigue funcionando sin que lo toques.
  • Registro A, para un dominio raíz. Nombre: @, que la mayoría de los paneles DNS usan para indicar el dominio desnudo. Valor: la dirección IP que te da el paso de DNS. Dice «este nombre vive en esta dirección».
  • TXT, a veces. Algunos entornos de alojamiento piden además un registro de verificación: una cadena larga y aleatoria bajo un nombre que indica el paso de DNS. No hace nada por los visitantes. Demuestra que quien controla el dominio aceptó la conexión. Si el paso lo muestra, añádelo; si no, no falta nada.

Dos errores explican la mayoría de los intentos fallidos. El primero es escribir el dominio completo en el campo Nombre. Muchos paneles añaden tu dominio automáticamente, así que reservas.tumarca.es escrito ahí se convierte en reservas.tumarca.es.tumarca.es, que no lleva a ninguna parte. Escribe solo el prefijo. El segundo es dejar un registro antiguo en su sitio. Si reservas ya tiene un registro A de un proyecto anterior, un CNAME no puede convivir con él, y algunos paneles conservan el viejo sin avisar. Borra primero el registro antiguo de ese nombre exacto.

Si tu proveedor de DNS ofrece un interruptor de proxy en el registro —Cloudflare lo muestra como una nube naranja—, ponlo en modo solo DNS mientras conectas. Un proxy responde a los visitantes en nombre de la plataforma y la oculta de la comprobación que se describe a continuación.

Por qué el candado llega al final

Este es el paso que hace pensar a los dueños que algo se ha roto. Los registros están guardados, el dominio parece correcto y el navegador dice que la conexión no es segura, o la web ni siquiera abre. Nada está roto. Simplemente, el orden es fijo.

Un certificado TLS, el candado, lo emite una autoridad de certificación que antes tiene que confirmar que el dominio apunta de verdad adonde dice la solicitud. Lo comprueba consultando el nombre en el DNS público y, en la mayoría de los entornos, enviando una petición al dominio y esperando que responda la plataforma. Hasta que tu registro llega a los resolutores que usa esa autoridad, la comprobación falla, y por mucho que hagas clic no cambia nada. En cuanto el registro resuelve, la plataforma solicita el certificado automáticamente. No lo compras, no lo subes y no lo renuevas.

Cuánto tarda en «resolver» depende sobre todo del TTL del registro que había antes: el tiempo durante el cual se permitió a otros servidores recordar la respuesta anterior. Un nombre totalmente nuevo suele aparecer rápido. Un nombre que ayer apuntaba a otro sitio puede seguir respondiendo con la dirección antigua durante un rato. Si sabes que vas a sustituir un registro existente, bajar su TTL el día anterior acorta la espera.

Si no, espera y luego comprueba. No sigas editando el registro: cada edición da a los servidores que guardaron en caché una respuesta equivocada un motivo más para seguir sirviéndola. Las webs públicas de consulta DNS muestran lo que ve el resto del mundo para tu nombre; cuando muestren el valor del paso de DNS, lo siguiente será el certificado.

Lo que cuesta equivocarse

Los errores caros no están en la web de reservas. Están en todo lo demás que cuelga de tu dominio.

El peor es cambiar los servidores de nombres cuando solo hacía falta añadir un registro. Mover los servidores de nombres entrega todo el dominio a un nuevo proveedor de DNS, y cualquier registro que no se vuelva a crear allí desaparece, incluidos los registros MX que entregan el correo de la empresa. Una agencia puede perder un día entero de correos de clientes, confirmaciones de proveedores y avisos de cambios de horario de las aerolíneas antes de que alguien note que la bandeja de entrada se ha quedado muda. Nada en la conexión de una web de reservas exige mover los servidores de nombres. Añade registros; deja el resto en paz.

El segundo es apuntar la raíz a la web de reservas mientras la web antigua todavía tiene páginas que la gente usa: una página de visados que posiciona en Google, una página de contacto impresa en las tarjetas de visita. Esos enlaces acaban ahora en una web de reservas que no las tiene. O trasladas primero la web antigua a un subdominio, o conectas la web de reservas a un subdominio.

El tercero solo cuesta nervios: anunciar la nueva dirección antes de que aparezca el candado. Un navegador que aleja a tus clientes de tu web el mismo día que la promocionas es una mala presentación. Anúnciala cuando el certificado esté activo, no cuando guardes el registro.

Conserva el dominio de la plataforma: es tu red de seguridad

El subdominio de la plataforma con el que arrancó tu web no desaparece cuando conectas tu propio dominio. No se puede eliminar, y es a propósito.

Es la dirección desde la que probar mientras el dominio propio se asienta, y la que sigue funcionando si vence una renovación en el registrador o alguien edita el DNS por error. El motor de reservas detrás de ambas direcciones es el mismo: a las reservas, los clientes y los informes les da igual por qué puerta se entró. Apunta esa dirección en un sitio que no dependa de que tu dominio funcione.

También marca el orden correcto para una web nueva, el mismo que al lanzar una OTA en un día: sal en vivo en el subdominio que el asistente de alta crea sin pedir tarjeta y conecta tu dominio cuando la web merezca enseñarse. Lo que cubre la web una vez que la dirección es tuya está en lo que te da de verdad una web de viajes de marca blanca.

Lista de control: conectar tu propio dominio a un motor de reservas

  1. Averigua quién aloja tu DNS. Los servidores de nombres del dominio te lo dicen.
  2. Elige raíz o subdominio. Si tienes una web que quieres conservar, elige subdominio.
  3. Anota todos los registros existentes, sobre todo los MX, antes de cambiar nada. Una captura de pantalla basta.
  4. Borra cualquier registro antiguo con el nombre exacto que vas a usar.
  5. Añade el registro del paso de DNS: CNAME para un subdominio, A para una raíz, más TXT si el paso lo muestra. Escribe solo el prefijo en el campo Nombre.
  6. Pon cualquier proxy de ese registro en modo solo DNS.
  7. Espera a que el registro resuelva públicamente. No lo sigas editando.
  8. Comprueba el candado, haz una reserva de prueba en la nueva dirección y luego avisa a los clientes.

Casi toda esta lista es esperar. El único paso que de verdad puede hacerte daño es el que no aparece en ella: mover los servidores de nombres.

Redacción de Tekravel

Mesa de tecnología de viajes

La mesa de tecnología de viajes de Tekravel escribe para el sector: propietarios de agencias, consolidadores y los desarrolladores que los integran. Cada artículo se comprueba contra la plataforma que describe antes de publicarse.