Como funciona o cache de DNS para sites por trás de CDN?

Uma empresa que usa uma CDN configurará servidores duplicados em todo o mundo. Esses servidores são conhecidos por todos os servidores CDN.

O mesmo endereço IP que você mencionou aponta para um servidor DNS que faz parte da CDN.

Este servidor DNS apenas encaminhará a solicitação de DNS para outro servidor DNS que será o servidor autoritativo do domínio. Ele pode não dar a resposta final em si (não é obrigatório), então isso se comportará como a hierarquia de servidores DNS usual. A escolha deste servidor autoritativo é influenciada principalmente pela localização geográfica do IP do cliente.

A resposta final para a consulta DNS será um servidor web da empresa que está atendendo ao domínio consultado (pertence ao domínio consultado), que é considerado o "mais próximo".

Para evitar problemas e congestionamento, a resposta do DNS terá um pequeno tempo de vida (TTL), de modo que o processo pode se repetir de tempos em tempos e talvez retornar outro servidor na próxima vez.

Quando se trata da Cloudflare, que é CDN e servidor DNS autoritativo, como os serviços de cache DNS, como o construído no Windows ou outro software de servidor de cache, sabem qual endereço IP pertence a qual domínio?

Eles não precisam saber disso. Todos os caches de DNS, assim como o próprio DNS, apenas mapeiam nomes de domínio para valores (registros 'A') – nunca o contrário.

Se, por exemplo, o software de cache DNS lembrar que 1.2.3.4 aponta para facebook.com e também que o IP é para google.com, bing.com etc., o cache é inútil, então o que estou perdendo?

Não, não é isso que o software de cache DNS lembra. Ele faz o oposto - tanto o cache DNS quanto o sistema DNS como um todo, só se importam que google.comaponte para 1.2.3.4, não que o endereço "aponte" de volta.

As entradas no cache DNS se parecem exatamente com as entradas em servidores DNS autoritativos, com o nome de domínio como chave de pesquisa. (Na verdade, além do Windows, a maioria dos caches DNS são apenas servidores DNS comuns que recebem consultas padrão e as respondem.)

Também não é novidade ter várias entradas DNS resolvendo para o mesmo endereço. (Por exemplo, mesmo sem um CDN, todos têm usado HTTP "hospedagem virtual" para hospedar dezenas ou centenas de sites diferentes nos mesmos servidores - de acordo com centenas de nomes DNS resolvendo para os mesmos endereços de servidor.)

então os serviços de cache DNS armazenam em cache o resultado final de uma consulta DNS, que é o endereço IP do servidor de origem

Sim, em geral, no entanto, quando você está usando um CDN como o Cloudflare, o resultado final dessa consulta DNS não é mais o servidor de origem – é o servidor CDN.

Com a Cloudflare em particular, a tabela de registros DNS que você vê no "painel de controle" da Cloudflare não são, na verdade, os registros DNS que a Cloudflare oferece aos usuários. Assim que você habilitar o proxy para um nome de domínio, os servidores DNS autoritativos da Cloudflare começarão a responder com os próprios endereços IP da CDN em vez dos que você digitou.

(Outros CDNs funcionam da mesma maneira, pois o objetivo de usar um CDN é que seus clientes conversem com ele. Por exemplo, o superuser.comdomínio usa o Fastly CDN para que ele sempre resolva para endereços IP de nós Fastly próximos.)

O objetivo de TTLs curtos com CDNs, portanto, não é proteção, mas balanceamento de carga (o servidor autoritativo do CDN responde dinamicamente com os "melhores" nós no momento, tanto em termos de carga quanto de geolocalização).

Quando várias entradas DNS resolvem para o mesmo endereço IP, como google.com e facebook.com, ambas resolvem para 1.2.3.4, qual elemento/componente na rede é responsável por levar o usuário ao site correto?

Na verdade, é o cliente e o servidor, não a rede.

Cada cliente HTTP especifica o domínio solicitado como parte da solicitação HTTP – esse é o cabeçalho "Host" em HTTP/1.1 (ou o pseudo-cabeçalho ":authority" em HTTP/2). Os servidores Web ou proxies reversos mapeiam o valor do Host recebido para o <VirtualHost> correspondente ou configuração semelhante.

(Você pode ver todos os cabeçalhos de solicitação usando as F12"Ferramentas do desenvolvedor" em um navegador - abra a guia "Rede" para começar a coletar dados, volte para o navegador e pressione F5 para recarregar a página da Web e volte para a "Rede" seção.)

Da mesma forma, os clientes TLS também especificam o domínio solicitado como a extensão "Indicação do nome do servidor" no TLS ClientHello para que o servidor possa enviar o certificado correto.

Em geral, cada protocolo tem sua própria maneira de fazer isso, e nem todos os protocolos realmente distinguem nomes de domínio diferentes. (Por exemplo, o SSH não fornece essas informações ao servidor, pois o objetivo não é se conectar a um "domínio", mas à própria máquina.)

Mas a rede (na camada IP) não se importa com domínios (ou sites) – seu único trabalho é entregar pacotes para 1.2.3.4, e se o endereço IP for o mesmo, o servidor de destino também será o mesmo . ("Servidor de destino" sendo o frontend de proxy reverso da CDN, neste caso.)