Como conectar o seu próprio domínio ao motor de reservas

O site está pronto. A logo está certa, os markups estão configurados, uma reserva de teste passou no subdomínio da plataforma e alguém da agência já mandou o link para três clientes. Aí chega a pergunta óbvia: por que o endereço ainda carrega o nome de outra empresa? Este guia mostra como conectar o seu próprio domínio ao motor de reservas sem contratar ninguém — o que você está realmente mudando, os dois ou três registros envolvidos, por que o cadeado aparece mais tarde do que você espera e a única configuração que, se tocada, derruba em silêncio o e-mail da empresa.
Você não precisa entender DNS a fundo. Precisa de uma ideia só: o seu nome de domínio é uma placa, e você está virando essa placa para um prédio novo. Todo o resto abaixo é detalhe dessa ideia.
Onde o seu domínio realmente mora
Até três empresas diferentes podem estar envolvidas, e a maioria dos donos de agência conhece só uma. O registrador é onde você comprou o nome e paga a renovação anual — no caso de um .com.br, muitas vezes o próprio Registro.br. O provedor de DNS é onde os registros desse nome são editados: muitas vezes é a mesma empresa do registrador, às vezes não, principalmente se um web designer montou tudo anos atrás e levou o nome para um serviço de DNS separado. A hospedagem do site é onde o seu site atual roda.
Os registros que você vai adicionar vão para o provedor de DNS. Então, antes de qualquer coisa, descubra quem é ele. Entre no painel do registrador e veja os nameservers (servidores DNS) listados no domínio. Se forem do registrador, você edita os registros ali. Se apontarem para outro lugar, é nesse outro lugar que você trabalha. Alguns minutos nisso poupam uma tarde editando registros num painel que ninguém lê.
Domínio raiz ou subdomínio: decida antes de mexer em qualquer coisa
O domínio raiz — também chamado de apex ou domínio "puro" — é suamarca.com.br sem nada na frente. Um subdomínio é qualquer coisa com um rótulo na frente: www.suamarca.com.br, reservas.suamarca.com.br, viagens.suamarca.com.br. A plataforma aceita os dois, e a escolha muda o registro que você adiciona.
O motivo é antigo e não tem negociação. A raiz já carrega os registros que definem o próprio domínio, e o DNS não permite que um CNAME divida o nome com qualquer outra coisa. Por isso a raiz é apontada com um registro A direto para um endereço IP, enquanto um subdomínio é apontado com um CNAME para outro hostname.
| Raiz (suamarca.com.br) | Subdomínio (reservas.suamarca.com.br) | |
|---|---|---|
| Registro que você adiciona | Registro A, apontando para um endereço IP | CNAME, apontando para um hostname da plataforma |
| O que o cliente digita | O endereço mais curto possível | Uma palavra a mais, o que pesa pouco quando o cliente chega por um link |
| Seu site atual | Precisa sair da raiz, ou o site de reservas toma o lugar dele | Fica exatamente onde está |
| E-mail da empresa | Não é afetado, desde que os registros MX fiquem intocados | Não é afetado |
| Serve para | Uma agência cujo site É o site de reservas | Uma agência com site institucional, blog ou CMS que quer manter |
A maioria das agências que já têm site deve começar por um subdomínio. A linha que gera discussão é a segunda: alguns donos acham que subdomínio parece menos estabelecido. É uma opinião justa, e ela pesa menos quando a maior parte dos clientes chega até você por um link no WhatsApp ou no Instagram, e não digitando o endereço.
Os registros que você adiciona e o que cada um faz
A etapa guiada de DNS mostra os valores exatos para o seu domínio. Copie de lá, não de artigo nenhum — incluindo este. O que vem a seguir explica para que serve cada registro, para que a tela faça sentido quando você a vir.
- CNAME, para um subdomínio. Nome: o rótulo que você escolheu, como
reservas. Valor: o hostname da plataforma que a etapa de DNS informa. Ele diz "este nome é um apelido daquele", então, se os servidores da plataforma mudarem, o seu registro continua funcionando sem você mexer. - Registro A, para a raiz. Nome:
@, que a maioria dos painéis de DNS usa para indicar o domínio puro. Valor: o endereço IP que a etapa de DNS informa. Ele diz "este nome mora neste endereço". - TXT, às vezes. Algumas configurações também pedem um registro de verificação: uma sequência longa e aleatória sob um nome que a etapa de DNS especifica. Para o visitante, não faz nada. Serve para provar que quem controla o domínio concordou com a conexão. Se a etapa mostrar um, adicione; se não mostrar, não está faltando nada.
Dois erros explicam a maioria das tentativas que dão errado. O primeiro é digitar o domínio completo no campo Nome. Muitos painéis completam o domínio sozinhos, então reservas.suamarca.com.br digitado ali vira reservas.suamarca.com.br.suamarca.com.br, que não leva a lugar nenhum. Digite só o rótulo. O segundo é deixar um registro antigo no lugar. Se reservas já tem um registro A de um projeto antigo, um CNAME não pode ficar ao lado dele, e alguns painéis mantêm o antigo sem avisar. Apague primeiro o registro antigo daquele nome exato.
Se o seu provedor de DNS oferece uma chave de proxy no registro — o Cloudflare mostra isso como uma nuvem laranja —, deixe em "somente DNS" enquanto conecta. Um proxy responde aos visitantes no lugar da plataforma, o que esconde a plataforma da verificação descrita a seguir.
Por que o cadeado chega por último
É a etapa que faz o dono achar que algo quebrou. Os registros estão salvos, o domínio parece certo e o navegador diz que a conexão não é segura — ou o site nem abre. Nada quebrou. A ordem é simplesmente fixa.
Um certificado TLS, o cadeado, é emitido por uma autoridade certificadora que primeiro precisa confirmar que o domínio aponta mesmo para onde o pedido diz. Ela verifica consultando o nome no DNS público e, na maioria das configurações, fazendo uma requisição ao domínio e esperando que a plataforma responda. Enquanto o seu registro não chegar aos resolvers que essa autoridade usa, a verificação falha, e clicar mais não muda nada. Assim que o registro resolve, a plataforma pede o certificado automaticamente. Você não compra, não envia e não renova certificado nenhum.
Quanto tempo leva para "resolver" depende principalmente do TTL do registro que estava lá antes: o tempo durante o qual outros servidores foram autorizados a lembrar a resposta antiga. Um nome novo em folha costuma aparecer rápido. Um nome que ontem apontava para outro lugar pode continuar respondendo com o endereço antigo por um tempo. Se você sabe que vai substituir um registro existente, baixar o TTL dele um dia antes encurta a espera.
Fora isso, espere e depois confira. Não fique editando o registro — cada edição dá a todo servidor que guardou uma resposta errada mais um motivo para continuar entregando essa resposta. Sites públicos de consulta DNS mostram o que o resto do mundo vê para o seu nome; quando mostrarem o valor da etapa de DNS, o certificado é a próxima coisa a acontecer.
Quanto custa errar
Os erros caros não estão no site de reservas. Estão em tudo o mais que está ligado ao seu domínio.
O pior é trocar os nameservers quando só era preciso adicionar um registro. Trocar os nameservers entrega o domínio inteiro a um novo provedor de DNS, e qualquer registro que não for recriado lá desaparece — inclusive os registros MX que entregam o e-mail da empresa. Uma agência pode perder um dia de e-mails de clientes, confirmações de fornecedores e avisos de alteração de voo das companhias aéreas antes que alguém perceba que a caixa de entrada ficou quieta. Nada na conexão de um site de reservas exige trocar nameservers. Adicione registros; deixe o resto em paz.
O segundo é apontar a raiz para o site de reservas enquanto o site antigo ainda tem páginas que as pessoas usam: uma página de vistos que aparece no Google, uma página de contato impressa no cartão de visita. Esses links agora caem num site de reservas que não tem essas páginas. Ou você muda o site antigo para um subdomínio antes, ou conecta o site de reservas a um subdomínio.
O terceiro só custa nervos: anunciar o endereço novo antes de o cadeado aparecer. Um navegador alertando os clientes contra o seu site no dia em que você o divulgou é uma péssima apresentação. Anuncie depois que o certificado estiver ativo, não depois de salvar o registro.
Mantenha o domínio da plataforma — ele é o seu plano B
O subdomínio da plataforma em que o seu site nasceu não some quando você conecta o seu domínio. Ele não pode ser removido, e isso é proposital.
É o endereço para testar enquanto o domínio próprio se acomoda, e o que continua funcionando se a renovação vencer no registrador ou se alguém editar o DNS por engano. O motor de reservas por trás dos dois endereços é o mesmo, então reservas, clientes e relatórios não se importam com a porta usada. Deixe esse endereço anotado num lugar que não dependa do seu próprio domínio estar no ar.
Ele também define a ordem certa para um site novo, a mesma de lançar uma OTA em um dia: entre no ar pelo subdomínio que o assistente de cadastro cria sem pedir cartão e conecte o seu domínio quando o site valer a pena ser mostrado. O que o site cobre depois que o endereço é seu está em o que um site de viagens white-label realmente entrega.
Checklist: conectar o seu próprio domínio ao motor de reservas
- Descubra quem hospeda o seu DNS. Os nameservers do domínio dizem.
- Escolha entre raiz e subdomínio. Se você tem um site que quer manter, escolha um subdomínio.
- Anote todos os registros existentes, principalmente os MX, antes de mudar qualquer coisa. Um print de tela resolve.
- Apague qualquer registro antigo no nome exato que você vai usar.
- Adicione o registro da etapa de DNS: CNAME para subdomínio, A para a raiz, mais o TXT se a etapa mostrar um. No campo Nome, digite só o rótulo.
- Coloque em "somente DNS" qualquer proxy ativo nesse registro.
- Espere o registro resolver publicamente. Não fique editando.
- Confira o cadeado, faça uma reserva de teste no endereço novo e só então avise os clientes.
Quase tudo nessa lista é espera. A única etapa que pode realmente prejudicar você é a que ela não contém: trocar os nameservers.