Como apontar um domínio para sua hospedagem

Você comprou um domínio, tem um site, API ou painel no ar e quer que meusite.com.br abra a sua aplicação em vez de um endereço técnico. O que liga as duas pontas é o DNS: você diz, num painel, para onde cada nome deve apontar.

O processo é o mesmo em qualquer hospedagem: a hospedagem informa um destino (um nome ou um IP), e você cria o registro correspondente na zona DNS do domínio. Quem controla essa zona é o seu registrador ou o provedor de DNS que você escolheu, não a hospedagem.

Onde ficam os registros DNS do meu domínio?#

Os registros ficam nos servidores de nomes (nameservers) do domínio. Se você nunca mudou nada, eles são os do próprio registrador (Registro.br, GoDaddy, Namecheap e outros). Se você delegou o DNS a um provedor como a Cloudflare, é lá que você edita, e o painel do registrador deixa de valer para registros.

Para descobrir quem manda na zona, rode:

dig NS meusite.com.br +short

Os nomes que aparecem (por exemplo ns1.exemplo-dns.com) indicam o painel onde criar os registros. Se você só tem o nslookup:

nslookup -type=NS meusite.com.br

Se quiser entender o que cada tipo faz, veja o que são registros DNS.

Registro A, AAAA ou CNAME: qual usar?#

• A: aponta um nome para um endereço IPv4 (203.0.113.10).
• AAAA: o equivalente para IPv6.
• CNAME: aponta um nome para outro nome (app.hospedagem.exemplo). Quem resolve segue o nome até achar o IP.

A regra prática: se a hospedagem te deu um nome, use CNAME; se deu um IP, use A. O CNAME é melhor quando o IP pode mudar, porque a hospedagem troca o IP sem você mexer no DNS.

A restrição que pega todo mundo: pela RFC 1034, quando existe um CNAME num nome, nenhum outro dado deve existir nele. O domínio raiz (meusite.com.br, sem prefixo) sempre tem registros NS e SOA, então não aceita CNAME. Para a raiz, use A, ou um provedor com CNAME flattening (ou um registro equivalente, que alguns provedores chamam de ALIAS ou ANAME), que resolve o nome do destino por você e devolve IPs.

Como apontar um domínio, passo a passo#

1. Pegue o destino no painel da hospedagem: um nome para CNAME ou um IP para A.

2. Abra a zona DNS no registrador (ou no provedor de DNS, se você delegou).

3. Crie o registro. Exemplo para o subdomínio app:

   Tipo	Nome (host)	Valor	TTL
   CNAME	app	destino-da-hospedagem.exemplo	300

   E para a raiz e o www:

   Tipo	Nome (host)	Valor	TTL
   A	@	203.0.113.10	300
   CNAME	www	meusite.com.br.	300

4. Remova conflitos: um registro A ou AAAA antigo no mesmo nome impede o CNAME, e o painel costuma recusar a criação.

5. Salve e aguarde a propagação.

Alguns painéis pedem o nome completo (app.meusite.com.br) e outros só o prefixo (app). Se o painel concatenar o domínio sozinho e você digitar o nome completo, o resultado vira app.meusite.com.br.meusite.com.br, um erro clássico. Os valores 203.0.113.10 e destino-da-hospedagem.exemplo acima são fictícios: use os que a sua hospedagem mostrar.

Como verificar que o domínio está apontando?#

Consulte o registro direto, sem depender do cache do navegador:

dig app.meusite.com.br CNAME +short
dig meusite.com.br A +short

Para ver o que um resolvedor público enxerga, consulte um servidor específico:

dig @1.1.1.1 app.meusite.com.br +short

Se a resposta bate com o destino que você configurou, o DNS está certo. Depois teste no navegador, de preferência em aba anônima, e com curl -I https://app.meusite.com.br para ver o status HTTP. O certificado HTTPS é outra etapa: em geral, a hospedagem só consegue emitir o TLS depois que o domínio resolve para ela.

Quanto tempo leva para valer?#

O DNS usa cache. Cada resolvedor guarda a resposta antiga pelo TTL do registro (em segundos). Se o registro antigo tinha TTL de 3600, alguns usuários continuam vendo o destino antigo por até uma hora. Um nome novo costuma valer em minutos, a menos que alguém o tenha consultado antes de ele existir: nesse caso, o resolvedor guarda a resposta "não existe" por um tempo definido no SOA da zona.

Antes de uma migração, reduza o TTL do registro atual para 300, espere o TTL antigo expirar, faça a troca e só depois volte o valor para algo maior.

Quais são os erros mais comuns?#

• CNAME na raiz: o painel recusa ou o site some. Use A ou ALIAS.
• Nome duplicado: app.meusite.com.br.meusite.com.br, por digitar o domínio onde o painel já completa.
• Registro conflitante: um A antigo no mesmo nome do CNAME.
• Nameservers errados: você edita no registrador, mas o domínio está delegado a outro provedor. Confira com dig NS.
• Esquecer o www: meusite.com.br abre e www.meusite.com.br dá erro, ou o contrário. Crie os dois.
• Erro de domínio inexistente: veja DNS_PROBE_FINISHED_NXDOMAIN para diagnosticar.

Para o conceito por trás de tudo isso, leia o que é DNS e como usar um domínio personalizado.

Como fazer isso na Square Cloud#

Na Square Cloud, o destino que você recebe é sempre um nome, não um IP: ao adicionar o domínio, o painel pede um CNAME para cname.squareweb.app e um TXT de validação. É a regra prática deste guia (recebeu um nome, crie um CNAME), e há um motivo: a plataforma não oferece IP fixo, então um registro A ficaria desatualizado.

Para o domínio raiz, o seu provedor de DNS precisa aceitar CNAME na raiz (flattening ou ALIAS). Para o www, o recomendado é redirecionar para o domínio principal. Depois de criar os registros no registrador, acompanhe a validação no painel em tempo real. Com o domínio validado, o TLS é emitido automaticamente, sem você gerar certificado. Domínios com acento (Punycode) são aceitos, e há purge de cache.

O domínio continua registrado em seu nome, e a zona fica no seu registrador ou provedor de DNS. O domínio personalizado está disponível a partir do plano Standard (a partir de R$ 44,99 por mês). Em todo plano, cada aplicação web já tem um subdomínio *.squareweb.app com HTTPS, útil para testar antes de apontar. Veja os detalhes em domínios personalizados e, se vários apps vão atender o mesmo domínio, em load balancing.