Por que uma consulta mostra a CDN, e não a origem
Visitante
consulta o domínio
Borda da CDN
104.21.x.x
é isto que o DNS retorna
Servidor de origem
IP real, nunca exposto
O que é um servidor de origem? Diferença para uma CDN
Um servidor de origem é o sistema que fornece o conteúdo original do site ou as respostas da aplicação a um intermediário, como uma CDN, um proxy reverso ou um balanceador de carga. O visitante pode se conectar a esse intermediário, e não diretamente à origem. O intermediário pode guardar conteúdo em cache, encerrar o TLS, filtrar o tráfego, distribuir as requisições ou proteger a origem contra a exposição direta. Essa arquitetura explica por que uma consulta de domínio para IP muitas vezes retorna um endereço pertencente a uma CDN ou a um proxy, e não à máquina onde os dados da aplicação estão armazenados. A resposta do DNS público identifica o ponto de entrada publicado, e não necessariamente cada componente interno por trás dele.
O caminho da requisição por um intermediário
Um caminho de requisição típico começa com o DNS resolvendo o hostname público para um endereço de borda. O navegador do usuário se conecta à CDN ou ao proxy, que então decide se pode servir uma resposta em cache ou se deve encaminhar a requisição para uma origem. A origem pode ser uma máquina virtual, uma plataforma de contêineres, um balanceador de carga na nuvem ou um serviço de hospedagem gerenciada. Pode haver várias camadas entre a borda pública e a aplicação. Cada camada tem configurações próprias de saúde, roteamento e segurança, de modo que uma consulta DNS bem-sucedida apenas confirma o endereço publicado do ponto de entrada; ela não confirma que o proxy consegue alcançar a origem.
| Componente | Responsabilidade típica |
|---|---|
| DNS | Publica a resposta pública de roteamento do hostname |
| Borda da CDN | Guarda conteúdo em cache e atende as conexões de usuários próximos |
| Proxy reverso | Recebe as requisições e as encaminha a um upstream |
| Origem | Gera ou armazena a resposta original da aplicação |
Manter a origem atrás de um intermediário pode reduzir a exposição direta e centralizar os controles, mas o desenho depende de uma configuração correta. Sempre que possível, a origem deve aceitar tráfego apenas das redes de proxy pretendidas ou de caminhos autenticados, e os administradores devem evitar publicar sem querer o endereço direto da origem por meio de registros DNS ou de infraestrutura de aplicação sem relação com o assunto. Ao mesmo tempo, a origem precisa continuar monitorada e acessível pelo proxy. Uma lista de permissão mal configurada pode bloquear o tráfego legítimo da borda, enquanto uma queda da origem pode fazer o domínio público falhar mesmo com o DNS e a borda da CDN saudáveis.
Por que uma consulta de IP não identifica a origem
Uma consulta DNS retorna os registros que os resolvedores têm permissão para ver. Se o domínio aponta para uma CDN, essas respostas são os endpoints públicos da CDN. A origem pode nem ser divulgada pelo DNS, e uma ferramenta de consulta não deve afirmar que um IP de borda é a origem. As informações de propriedade do endereço podem ajudar a identificar um provedor de infraestrutura, mas ainda assim não revelam a topologia completa do backend. Em trabalhos de segurança ou de resposta a incidentes, trate essas evidências com cuidado: endereços de borda compartilhados podem atender muitos domínios, e suposições baseadas em um único endereço podem atribuir um serviço à entidade errada.
- Use o DNS para identificar o ponto de entrada público, e não para presumir a arquitetura do backend.
- Verifique os painéis da CDN e do proxy reverso para conferir a conectividade e a saúde da origem.
- Proteja o acesso à origem com controles de rede e de autenticação documentados.
- Evite expor origens privadas ou administrativas no DNS público sem querer.
- Descreva os IPs observados com precisão, como respostas do DNS público em um dado momento.
Diagnostique de fora para dentro
Se os usuários não conseguem acessar um site, verifique primeiro o DNS público, depois teste a conexão e o certificado da borda e, por fim, inspecione a saúde entre o proxy e a origem e os logs da aplicação. Um endereço público válido com um erro de proxy muitas vezes aponta para algo além do DNS. Se apenas algumas regiões falham, compare as respostas dos resolvedores e a saúde da CDN por localização. Se todas as regiões falham depois de uma mudança de registro, verifique se o novo destino do DNS corresponde à configuração esperada pelo provedor. Esse método em camadas restringe o problema sem contornar proteções nem tentar descobrir infraestruturas ocultas que você não administra.
Para ver a arquitetura relacionada, leia como as CDNs roteiam com o DNS e por que as CDNs escondem os IPs de origem. A ferramenta de consulta de domínio pública é útil para verificar o endereço que o DNS anuncia no momento. Para diagnosticar uma origem, use a telemetria da sua própria hospedagem e do proxy, em vez de tratar a resolução de nomes pública como um mapa completo do desenho interno do serviço.
A origem é um papel da aplicação, e não um endereço específico
As equipes às vezes descrevem uma origem como o IP de um único servidor, mas as implantações modernas podem ter vários pools de origem, balanceadores de carga privados, aplicações serverless ou serviços de armazenamento atrás de uma mesma CDN. O papel de origem é definido por quem fornece o conteúdo ao intermediário, e não por uma máquina permanente. Uma origem pode mudar ou escalar enquanto o DNS público continua anunciando a mesma borda. Ao documentar uma arquitetura, nomeie cada fronteira: hostname público, borda da CDN, endpoint de origem e backend da aplicação. Isso ajuda quem responde a incidentes a pedir os logs certos ao responsável certo. Se uma resposta falha na borda, compare os diagnósticos da borda com a saúde da origem e os IDs de requisição, em vez de presumir que um endereço do DNS público identifica o componente com falha.
Precisa conferir os endereços DNS públicos de um domínio? Use a ferramenta Domain IP Lookup.
Leitura relacionada
Por que uma consulta mostra a CDN, e não a origem
Visitante
consulta o domínio
Borda da CDN
104.21.x.x
é isto que o DNS retorna
Servidor de origem
IP real, nunca exposto
O que é um proxy reverso? Um guia prático de DNS e web
Entenda como um proxy reverso fica entre clientes e servidores, como o DNS direciona os usuários até ele e como ele oferece suporte a roteamento, TLS e segurança.
Três papéis, muitas vezes três empresas diferentes
Como funciona a delegação de DNS: registrador e provedor
Veja como as zonas pai delegam domínios a servidores de nomes autoritativos e por que editar registros no provedor de DNS errado não tem efeito público.
Dois esquemas de endereçamento, lado a lado
IPv4
192.0.2.10
32 bits, ~4,3 bilhões de endereços, esgotado
IPv6
2606:4700::6810:84e5
128 bits, 340 undecilhões de endereços
O esgotamento do IPv4 e a lenta marcha rumo ao IPv6
O mundo ficou sem novos endereços IPv4 há anos. Veja o que realmente manteve tudo funcionando desde então e por que a transição ainda não terminou.