Blog

“Se você tem apenas o IP do servidor, falta a parte mais importante para um app em produção: uma URL estável e segura (HTTPS).”

Quando um time de desenvolvimento entrega uma API ou um portal (admin/web), é comum o cliente receber apenas um IP do servidor. Isso funciona para testes rápidos, mas vira um problema no momento de publicar e manter um aplicativo nas lojas.

Na prática, apps iOS/Android e aplicações web modernas precisam conversar com a API via HTTPS (conexão segura). E para ter HTTPS “do jeito certo”, você precisa de um domínio (ou subdomínio), não só um IP.

Neste artigo, você vai aprender como fazer o apontamento de DNS do tipo A (o mais comum quando você recebe um IPv4) e como organizar isso de forma simples — incluindo um passo a passo nos provedores de DNS mais usados.

O que você vai ver aqui:

• Por que não usar IP direto na API do app
• O que é DNS e o que é um Registro A
• Como escolher o subdomínio ideal (sem comprar outro domínio)
• Passo a passo padrão (vale para qualquer provedor)
• Passo a passo por provedor: Registro.br, GoDaddy, Cloudflare, AWS, Google, Microsoft e outros
• O que é “propagação de DNS” (sem complicação)
• Usar o domínio que você já tem vs. comprar outro: prós e contras
• Checklist final (para você não esquecer nada)

Por que não usar só o IP do servidor

Abaixo estão os motivos mais comuns — e os que mais geram retrabalho quando o assunto é publicar app:

1. HTTPS fica difícil (ou inviável) “do jeito correto”
   Para um app usar HTTPS, o servidor precisa apresentar um certificado válido para o endereço acessado (a URL). Certificados para IP são incomuns e, na prática, a maioria das soluções modernas assume um nome (domínio/subdomínio).
2. IP muda com troca de ambiente e isso quebra o app
   Trocar de servidor, migrar de provedor, mudar de infraestrutura, subir um novo balanceador… tudo isso pode mudar o IP. Se o app está “amarrado” no IP, você precisa publicar uma atualização só para trocar a URL.
3. Um domínio te dá estabilidade e organização
   Com domínio, você cria uma estrutura limpa, por exemplo:
4. api.seudominio.com → API do aplicativo
5. admin.seudominio.com → portal administrativo
6. www.seudominio.com → site institucional
7. homolog-api.seudominio.com → ambiente de homologação (se existir)
8. Segurança e boas práticas
   Mesmo que tecnicamente dê para “forçar” exceções, o caminho recomendado é HTTPS com certificado válido.

Conceito rápido: o que é DNS e o que é um Registro A

DNS é como uma “agenda” da internet: ele transforma um nome fácil (ex.: api.seudominio.com) em um endereço de verdade (um IP).

Um Registro A é o tipo de registro DNS que aponta um nome para um IPv4 (o IP tradicional com quatro blocos, como 203.0.113.10).

Se o seu provedor falar em IPv6 (menos comum nesse cenário), o registro equivalente costuma ser o AAAA.

Checklist antes de começar (para evitar erro)

Antes de mexer em DNS, confirme:

1. Qual é o domínio que você vai usar
   Ex.: seudominio.com (normalmente a empresa já tem um).
2. Qual subdomínio você quer criar
   Ex.: api (vai virar api.seudominio.com).
3. Você recebeu um IP IPv4 correto do time técnico
   Ex.: 203.0.113.10 (o desenvolvedor normalmente te passa).
4. Onde o DNS do seu domínio está sendo gerenciado
   Isso é muito importante: às vezes o domínio foi comprado no Registro.br, mas o DNS está no Cloudflare; ou foi comprado na GoDaddy, mas o DNS está na AWS.

Dica: se você não sabe, pergunte internamente “quem administra o DNS do domínio?” ou peça ajuda para quem cuida do site/e-mail.

5. Você entende o impacto
   Adicionar um registro A para um subdomínio novo (ex.: api) normalmente não afeta o site nem o e-mail.
   O risco maior é quando alguém altera registros existentes (MX, TXT, @, www) sem querer.
6. Porta e HTTPS (para apps em produção) Um detalhe que confunde bastante: registro A não configura porta. Ele só liga nome → IP.

O que isso significa?

• O endereço final do app deve ser algo como https://api.seudominio.com (porta 443, padrão do HTTPS).
• Se o servidor estiver usando uma porta diferente, isso precisa ser configurado no servidor/balanceador — e normalmente não é recomendado para apps em produção.

Passo a passo padrão (vale para qualquer provedor)

A maioria dos painéis é diferente, mas os campos são praticamente os mesmos.

1. Entre no painel de DNS do seu domínio
   Procure por algo como: “DNS”, “Zona DNS”, “Gerenciar DNS” ou “DNS Records”.
2. Clique para adicionar um novo registro
   Normalmente aparece como “Adicionar”, “Novo registro” ou “Add record”.
3. Selecione o tipo A
   Tipo: A (IPv4)
4. Preencha os campos
   Use o padrão abaixo:
5. Nome/Host: api
6. Aponta para/Valor: SEU_IP_AQUI
7. TTL: 300 (5 min) ou 3600 (1h)

5. Salve
   Alguns provedores pedem confirmação.
6. Aguarde a propagação
   Mesmo depois de salvar, pode levar um tempo para “espalhar” a atualização.
7. Depois disso, configure o HTTPS no servidor (ou com seu time técnico)
   DNS sozinho não cria HTTPS. Ele só aponta o nome para o servidor.
   O HTTPS vem do certificado instalado/configurado no servidor (ou no balanceador/reverso).

Se o desenvolvedor não te passou um IP (e sim um “endereço”)

Às vezes, o time técnico não te passa um IP e sim um endereço parecido com:

• meu-balanceador.alguma-coisa.cloud
• minha-distribuicao.alguma-coisa.cdn

Nesse caso, normalmente o apontamento correto NÃO é um Registro A, e sim:

• CNAME (aponta um nome para outro nome), ou
• ALIAS/ANAME (alguns provedores oferecem “A para nome”, parecido com CNAME, mas compatível com mais cenários).

Se você recebeu um “nome” e não um IP, peça ao time técnico:
“É para apontar por CNAME/ALIAS? Qual é o valor exato?”

(Se você tentar forçar um Registro A sem ter um IP fixo, a chance de dar problema depois é alta.)

Propagação de DNS (sem ser técnico)

“Propagação” é o tempo para a internet inteira enxergar a sua alteração.

O principal fator é o TTL (tempo que alguns servidores guardam a informação em cache). Em geral, alterações de DNS podem aparecer em minutos, mas é normal levar algum tempo para estabilizar.

Se você alterou apenas um registro A de um subdomínio, a chance de impacto é baixa.
Se você trocou servidores DNS (nameservers), o tempo costuma ser maior.

E se o IP mudar no futuro?

Isso acontece bastante quando a empresa troca de servidor, muda de provedor ou recria ambientes.

Como reduzir dor de cabeça:

• Peça um IP fixo (ou “reservado”) para produção, quando possível.
• Use um subdomínio específico para cada ambiente (ex.: homolog-api.seudominio.com).
• Se você sabe que vai trocar o IP em uma data específica, reduza o TTL com antecedência (por exemplo, para 300) para a mudança “pegar” mais rápido.
• Documente internamente quem é responsável por DNS e por renovação do domínio.

O ponto principal é simples: o app deve “conhecer” uma URL estável, e a infraestrutura por trás pode mudar sem obrigar você a publicar uma nova versão do app.

Passo a passo por provedor

A seguir, um passo a passo “traduzido” para os painéis mais comuns. A ideia é que você consiga fazer sozinho, ou orientar alguém do seu time.

1) Registro.br (quando o DNS está no Registro.br)

Use este caminho quando o seu domínio está com os servidores DNS do próprio Registro.br.

1. Acesse sua conta e selecione o domínio.
2. Role até a seção de DNS e procure por “Configurar zona DNS”.
3. Clique em “Nova entrada” (ou opção equivalente).

4. Preencha:

   • Tipo: A
   • Nome: api
   • Valor: SEU_IP_AQUI
   • TTL: 300 ou 3600
5. Salve.

Observação importante: se o seu domínio usa DNS de outro provedor (ex.: Cloudflare), você não vai encontrar a zona para editar no Registro.br — nesse caso, edite onde o DNS realmente está.

2) GoDaddy

1. Entre na sua conta e abra o domínio.
2. Vá em “DNS” (ou “Manage DNS”).
3. Clique em adicionar um novo registro.
4. Tipo: A
5. Host: api
6. Aponta para: SEU_IP_AQUI
7. Salve.

3) Cloudflare

1. Entre no painel do Cloudflare e selecione o seu domínio (site).
2. Vá em “DNS” → “Records”.
3. Clique em “Add record”.
4. Tipo: A
5. Nome: api
6. IPv4: SEU_IP_AQUI
7. Salve.

Dica para leigos: se aparecer um botão de “proxy” (nuvem), e você não sabe o que é, use “DNS only” e deixe o time técnico configurar o HTTPS no servidor. Se você usar proxy, combine antes com o desenvolvedor porque muda o caminho do tráfego.

4) Amazon AWS (Route 53)

1. Acesse o serviço Route 53.
2. Abra “Hosted zones” e selecione a zona do seu domínio.
3. Clique em “Create record”.
4. Nome do registro: api
5. Tipo: A
6. Valor: SEU_IP_AQUI
7. Salve.

Observação: se sua infraestrutura usa balanceador (ALB/ELB) ou CDN, pode ser que o correto seja Alias/CNAME. Se você recebeu apenas “um IP”, normalmente é porque o time técnico te passou um IP fixo.

5) Google (Google Cloud DNS)

1. Acesse o console do Google Cloud e abra o Cloud DNS.
2. Selecione a zona (managed zone) do domínio.
3. Adicione um novo conjunto de registros (record set).
4. Tipo: A
5. Nome: api (ou api.seudominio.com, dependendo do campo)
6. Valor: SEU_IP_AQUI
7. Salve.

6) Microsoft (Azure DNS)

1. Acesse o portal do Azure e abra “DNS zones”.
2. Selecione a zona do seu domínio.
3. Vá em “Record sets” e clique em “Add”.
4. Nome: api
5. Tipo: A
6. IP: SEU_IP_AQUI
7. Salve.

7) Namecheap (extra)

1. Domain List → Manage.
2. Aba “Advanced DNS”.
3. “Host Records” → “Add New Record”.
4. Tipo: A
5. Host: api
6. Value: SEU_IP_AQUI
7. Salve.

8) Hostinger (extra)

1. Acesse o painel (hPanel).
2. Abra o domínio e procure por “DNS Zone Editor”.
3. Adicione um registro do tipo A.
4. Nome: api
5. Aponta para: SEU_IP_AQUI
6. Salve.

Outros provedores comuns (a lógica é a mesma)

Mesmo que você use outro provedor (UOL, Locaweb, HostGator, etc.), procure por:

• DNS / Zona DNS / DNS Records
• Adicionar registro (A)
• Nome/Host + IP/Valor + TTL

Usar o domínio que você já tem ou comprar outro?

Na maioria dos casos, você NÃO precisa comprar um novo domínio. Um subdomínio resolve.

Exemplo: se a empresa já tem seudominio.com, você cria:

• api.seudominio.com
• admin.seudominio.com

Vantagens de usar o domínio que você já possui

• Custo zero adicional (sem nova assinatura/renovação)
• Menos coisa para administrar
• Mantém padrão e credibilidade do domínio oficial da empresa

Desvantagens (e como evitar)

• Se alguém fizer alterações erradas na zona DNS, pode afetar outras coisas (site/e-mail).
  Solução: mexer apenas no subdomínio novo e não apagar registros existentes.
• Dependência de outro time/fornecedor (marketing/agência) para liberar o acesso.
  Solução: definir um responsável por DNS e um processo simples de aprovação.

Quando faz sentido comprar um domínio separado

• Separar completamente ambientes/serviços (ex.: domínio só para apps)
• Evitar qualquer risco no domínio principal
• Ter um domínio técnico que pode ser administrado pelo time de TI/DevOps

Se optar por outro domínio, o cuidado nº 1 é simples: não deixar vencer.
Se o domínio expirar, o app pode ficar sem comunicação com o backend e você pode perder controle desse endereço.

O que você deve pedir do seu time técnico (ou do desenvolvedor)

Para você apontar o DNS corretamente, normalmente você precisa receber:

• O IP do servidor (IPv4) que ficará “fixo” para produção, quando possível
• Qual subdomínio usar (ex.: api)
• Um endpoint de teste (ex.: /health), para validar depois
• Confirmação de que o HTTPS será configurado assim que o DNS estiver apontado

Checklist final (copia e cola)

Antes de avisar “está pronto”, confirme:

[ ] O subdomínio escolhido (ex.: api.seudominio.com) está correto
[ ] O Registro A foi criado com o IP certo
[ ] Você não alterou registros antigos (especialmente e-mail) sem intenção
[ ] Você aguardou um tempo de propagação
[ ] O time técnico instalou/configurou certificado HTTPS para o subdomínio
[ ] Você testou a URL final em HTTPS

Se você fizer apenas isso, você elimina 90% dos problemas comuns de “API por IP” e garante que seu app e seus portais tenham uma URL estável e segura.