CDN: Como é possível que meu DNS forneça um IP diferente, dependendo da localização dos visitantes?

Question

Eu encontrei esta explicação como funciona um CDN. Mas há uma coisa que realmente não entendo. Vamos supor que eu configurei vários servidores DNS no meu local e eles usam os domínios do servidor de nomes dns1.example.com , dns2.example.com e dns3.example.com . Esses servidores DNS são capazes de fornecer um IP de servidor, dependendo da localização dos visitantes (ping, banco de dados geográficos, idioma do navegador ou qualquer outro). Agora eu atualizo as configurações deste servidor de nomes para o meu domínio www.example.org no registro.

Agora, a primeira solicitação em www.example.org com um TTL expirado tenta resolver o domínio. Ele pergunta:

1. o local .hosts / DNS, se o TTL expirou:
2. os provedores de internet DNS, se o TTL expirou:
3. o DNS raiz, se o TTL expirou:
4. meu local dns1.example.com

Mas se eu entendi correto, o novo IP é então adicionado a todos esses caches de servidor de nomes até que o TTL expire novamente. Então, como é possível enviar outros IPs ao visitante dependendo de sua localização?

Em esta resposta theandym disse que a solicitação é "encaminhada", mas não acho que seja assim que um CDN funciona, porque "encaminhamento" significa alongar o caminho de transmissão, resultando em um tempo de carregamento maior. Ou um CDN requer um TTL zero para o domínio?

Update1
Por meio de esta pergunta , encontrei O documento do Google descreve como eles otimizaram o desempenho do CDN. Não explicou como o CDN funciona em geral, mas havia explicações interessantes como as seguintes:

Thereafter, whenever a client attempts to fetch content hosted on the CDN, the client is redirected to the node determined to have the least latency to its prefix. This redirection however is based on the prefix corresponding to the IP address of the DNS nameserver that resolves the URL of the content on the client’s behalf, which is typically co-located with the client.

Isso significa que o Google verifica primeiro a latência de todos os prefixos de IP e define uma tabela de resolução de DNS (?) para todos os prefixos disponíveis. E se um visitante tiver o IP 198.51.100.231 , o IP do servidor do Google é usado, isso é definido para o prefixo 198.51.100.0 . Mas novamente: como o DNS do Google sabe qual IP o visitante está usando? A maioria dos visitantes resolve o domínio do Google através de seu provedor de internet e, com isso, a resolução é feita através desses servidores DNS externos ou não?

Como um exemplo adicional: se eu iniciar uma resolução de DNS para o domínio facebook.com com diferentes ferramentas on-line (hospedadas em diferentes países), elas serão resolvidas para diferentes IPs com diferentes domínios, como:

• 31.13.92.36 Reverse: edge-star-mini-shv-01-frt3.facebook.com
• 31.13.76.68 Reverso: edge-star-mini-shv-01-sea1.facebook.com
• 31.13.69.228 Reverso: edge-star-mini-shv-01-iad3.facebook.com
• 157.240.2.35 Reverso: edge-star-mini-shv-01-ort2.facebook.com

Depois disso, pensei que poderia depender da localização do servidor DNS usada pelo visitante, mas tentei o meu (Deutsche Telekom, Alemanha), o Google (8.8.8.8) e o principal da França (Orange) e todos eles retornou para facebook.com do IP 31.13.92.36 .

    

Answer 1

Ok, parece que agora posso dar uma resposta aproximada à minha própria pergunta. Anurag Bhatia diz que existem dois métodos como um CDN funciona:

DNS

Have DNS to do the magic i.e when users from network ISP A lookup for cdn.website.com, they should get a unicast IP address of Cache A in return, similarly for users coming from ISP B network, Cache B’s unicast IP should return.

Digamos que temos um servidor com o IP 1.2.3.4 localizado nos EUA e um servidor de cache com o IP 2.3.4.5 localizado na Alemanha. Agora, um visitante tenta resolver o domínio example.org . Se ele não mudou suas configurações de rede, ele usa o servidor DNS de seu provedor de serviços de Internet (ISP). E este ISP pede agora dns1.example.com (o servidor de nomes do domínio) para o IP. Agora depende da localização do ISP. Se estiver localizado na Alemanha, o dns1.example.com retornará 2.3.4.5 e, se estiver localizado nos EUA, ele retornará 1.2.3.4 .

Mas pode haver uma desvantagem com esse método: Toda vez que um usuário altera suas configurações de rede e usa um EDNS0 (veja IETF draft) provedor de DNS incompatível (por exemplo, um servidor DNS central da empresa) o dns1.example.com irá responder novamente com o IP mais próximo desses locais DNS, mas desta vez o visitante é provavelmente em um local diferente, causando uma latência maior.

Os provedores de DNS estão transmitindo informações sobre o usuário para o servidor DNS autoritativo. Assim, o servidor DNS autoritativo pode responder com o IP ao lado do local do usuário:

Today, if you’re using OpenDNS or Google Public DNS and visiting a website or using a service provided by one of the participating networks or CDNs in the Global Internet Speedup then a truncated version of your IP address will be added into the DNS request. The Internet service or CDN will use this truncated IP address to make a more informed decision in how it responds so that you can be connected to the most optimal server.

...

; EDNS: version: 0, flags:; udp: 512
; CLIENT-SUBNET: 130.89.89.0/24/21

Anycast

Have routing to route to nearest cache node based on “anycast routing” concept. Here Cache A, Cache B and Cache C will use same identical IP address and routing will take care of reaching the closest one.

Eu realmente não entendo o Anycast por causa do BGP, etc., mas eu acho que a explicação adicional do Anurag Bhatia dá uma idéia de como isso funciona:

1. Optimization is based on BGP routing and announcement with little role of DNS.
2. This setup is very hard to build up and scale since for anycast to work perfectly at global level, one needs lot’s and lot’s of peering and consistent transit providers at each location. If any of peers leaks a route to upstream or other peers, there can be lot of unexpected traffic on a given cluster due to break of anycast.
3. This setup has no dependency on DNS recursor and hence Google DNS or OpenDNS works just fine.
4. This saves a significant amount of IP addresses since same pools are used at multiple locations.

Anycast também tem uma desvantagem: o roteamento é flexível. Enquanto no início de uma sessão TCP o nó de destino pode estar localizado na rede A, ele pode mudar para a rede B. Portanto, Anycast será usado na prática apenas para UDP. O UDP é um protocolo sem sessão.

A maioria dos CDNs está usando DNS para tráfego HTTP / HTTPS e Anycast para solicitações DNS.