Domain IP Lookup

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

Infraestrutura e operações

O que é um servidor de origem? Diferença para uma CDN

4 min de leitura

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.

ComponenteResponsabilidade típica
DNSPublica a resposta pública de roteamento do hostname
Borda da CDNGuarda conteúdo em cache e atende as conexões de usuários próximos
Proxy reversoRecebe as requisições e as encaminha a um upstream
OrigemGera 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.