Como funcionam os domínios e o DNS: guia para não programadores

Um domínio é o nome que as pessoas escrevem para chegar ao seu site, como example.com, e o DNS (Domain Name System) é a lista telefónica da internet que traduz esse nome para o sítio onde o seu site realmente está. Aluga o domínio a um registrar e depois acrescenta registos DNS que dizem "o site está ali" e "o email vai para aqui". Ligar um domínio personalizado a uma app é sobretudo uma questão de acrescentar o registo certo no sítio certo e esperar que tenha efeito.

Porque é que isto importa ao construir com IA

Um construtor de apps com IA pode escrever e alojar a sua app, mas o seu domínio fica fora dela — muitas vezes com uma empresa diferente, num painel de controlo cheio de tipos de registo desconhecidos. É aqui que muitos lançamentos param: a app está pronta, mas o domínio mostra um erro, ou o email deixa de funcionar misteriosamente após uma alteração de DNS.

Um pouco de compreensão faz muita diferença. Vai perceber qual registo o seu fornecedor pede, porque é que ainda não funcionou e como evitar estragar aquilo que já depende do seu domínio (como o email).

Uma analogia do dia a dia

Pense na lista de contactos do telemóvel.

Não se lembra do número do seu amigo; toca no nome e o telemóvel procura-o. O DNS faz o mesmo na internet: escreve example.com, e o DNS procura o número (o endereço IP) do servidor a que deve ligar.

• O domínio é o nome do contacto.
• O registrar é a empresa que regista oficialmente que o nome é seu.
• Os registos DNS são os dados guardados sob esse nome: número de telefone, endereço de email, morada.
• Os servidores de nomes são a agenda oficial desse nome.
• A cache é o telemóvel a lembrar-se de um número durante algum tempo. Se o seu amigo mudar de número, alguns telemóveis continuam a ligar para o antigo até a cópia guardada ser atualizada — é isso a "propagação" do DNS.

As partes de um nome de domínio

Tome app.example.com:

Não compra um domínio de forma definitiva; regista-o por um período (normalmente um ano ou mais) e renova-o. Se deixar expirar, outra pessoa pode registá-lo.

Como funciona uma pesquisa DNS

Quando alguém escreve app.example.com:

1. O navegador pergunta a um resolvedor DNS — normalmente gerido pelo fornecedor de internet ou por um serviço público — qual é o endereço.
2. Se o resolvedor tiver uma resposta recente em cache, responde de imediato.
3. Se não tiver, percorre a hierarquia: os servidores raiz indicam-lhe os servidores .com, que o encaminham para os servidores de nomes do seu domínio.
4. Os seus servidores de nomes devolvem o registo que definiu, como um CNAME para o seu fornecedor de alojamento ou um registo A com um endereço IP.
5. O resolvedor guarda a resposta em cache durante o TTL (tempo de vida) do registo e entrega-a ao navegador, que se liga ao servidor.

Tudo isto costuma acontecer em milissegundos.

Tipos de registo DNS que vai realmente usar

Algumas regras que vale a pena conhecer:

• Um CNAME não pode partilhar o nome com outros registos. É por isso que um CNAME normal não pode ir no domínio raiz, que tem sempre registos NS e outros. Muitos fornecedores de DNS oferecem soluções alternativas chamadas ALIAS, ANAME ou CNAME flattening.
• Os registos TXT fazem muito trabalho no email. O SPF indica quem pode enviar email pelo seu domínio; o DKIM publica uma chave para verificar as assinaturas; o DMARC diz aos destinatários o que fazer com emails que falham essas verificações.
• Números MX mais baixos significam prioridade mais alta. O email tenta primeiro o mais baixo.

Propagação e TTL

"Propagação" faz parecer que as alterações se espalham lentamente pela internet. Na prática, acontece cache: os resolvedores guardam uma cópia de cada resposta durante o seu TTL, e só voltam a perguntar quando ela expira. Assim:

• Um registo novo que nunca foi consultado costuma funcionar em minutos.
• Alterar um registo existente demora até ao seu TTL antigo para ser visto em todo o lado.
• Alterar servidores de nomes pode demorar um ou dois dias, porque esses registos ficam em cache durante mais tempo ao nível do TLD.

Um truque útil: antes de uma alteração planeada, reduza o TTL do registo (por exemplo, para alguns minutos), espere que o TTL antigo passe, e só então faça a alteração.

Um exemplo prático: ligar uma app de reservas ao seu domínio

É dono de oseusalao.com. O seu site atual e o email do Google Workspace já usam esse domínio. Construiu uma app de reservas e quer que fique em reservas.oseusalao.com.

1. Descubra onde o DNS é gerido. Pode ser no seu registrar ou num fornecedor de DNS separado. Os seus registos NS indicam-no.
2. Acrescente um CNAME para reservas a apontar para o destino que o seu fornecedor de alojamento lhe der.
3. Acrescente qualquer registo TXT que o fornecedor peça para provar a propriedade, se usar um.
4. Não mexa nos registos MX nem nos TXT do email. O email continua a funcionar porque não lhes tocou.
5. Verifique no seu fornecedor quando o DNS estiver atualizado. O fornecedor emite então um certificado HTTPS para reservas.oseusalao.com.
6. Teste num telemóvel com dados móveis, que usa um resolvedor e uma cache diferentes da rede Wi-Fi de casa.

Se quisesse a app no domínio raiz oseusalao.com, precisaria de registos A ou da funcionalidade ALIAS/flattening do seu fornecedor de DNS — e estaria a substituir o seu site atual nesse endereço. Para mais passos, veja como ligar um domínio personalizado.

Erros e ideias erradas comuns

• "O domínio e o alojamento são a mesma coisa." O domínio é o nome; o alojamento é onde a app corre. O DNS liga-os.
• Usar um registo A quando o fornecedor pediu um CNAME (ou o contrário). Siga exatamente as instruções do fornecedor.
• Erros de digitação no destino. Um único carácter errado num destino de CNAME faz falhar a verificação.
• Mudar os servidores de nomes sem copiar os registos. Mudar o DNS para um novo fornecedor sem recriar os registos MX e TXT é uma forma clássica de estragar o email.
• Usar proxy quando não deve. Alguns fornecedores de DNS, como a Cloudflare, podem fazer proxy do tráfego. Alguns fornecedores de alojamento exigem que o registo esteja em "apenas DNS" para poderem emitir certificados.
• Apagar registos TXT "desconhecidos". Muitas vezes são registos de verificação ou de segurança do email de que algo depende.
• Deixar o domínio expirar. Ative a renovação automática e mantenha o cartão de pagamento atualizado.

O que pedir ao seu construtor de IA

O DNS fica fora do seu código, por isso esta secção é mais sobre o que perguntar sobre ele:

• "Qual é o registo DNS exato de que preciso para app.omeudominio.pt — tipo, nome e valor?"
• "Esta alteração vai afetar o meu email?"
• "O meu domínio mostra um erro depois de acrescentar o registo. O que devo verificar?"
• "Acrescente o URL canónico e os redirecionamentos corretos para que www e sem www não mostrem ambos o site."
• "Configure o envio de email a partir do meu domínio — de que registos SPF, DKIM e DMARC vou precisar?" Veja como enviar emails a partir da sua app.

Domínios personalizados no Mythex

Cada app publicada no Mythex recebe um endereço o-seu-nome.mythex.app. No plano Pro, pode usar o seu próprio domínio: pode comprar um dentro do Mythex (o registo é faturado à parte, e o DNS dos domínios comprados é gerido por si), ou ligar um que já possua, acrescentando um CNAME de um subdomínio, como app.example.com, para o endereço o-seu-nome.mythex.app da sua app, e depois clicar em Verificar. O HTTPS é emitido automaticamente. Se o seu DNS estiver na Cloudflare, defina esse registo como "apenas DNS". Recomendam-se subdomínios; os domínios raiz dependem do suporte ALIAS ou flattening do seu fornecedor de DNS. A documentação de domínios personalizados explica cada passo, e os preços mostram o que o plano Pro inclui.

Perguntas