LucaTheHacker
Non proprio. In generale punti alla location più vicina, ma non permette di sfruttare la cache degli operatori, perché Cloudflare quando effettua la ricorsione non trasmette la subnet del client (come descritto nel post).
Alcune CDN quindi si basano sull'indirizzo IP usato da Cloudflare stesso e restituiscono un server più distante.
Considera poi che in questi ultimi mesi la location di Milano (MXP) di CF ha avuto parecchi problemi (https://forum.fibra.click/d/12747-ah-cloudflare)
Esempietto: dogvgb9ujhybx.cloudfront.net è un dominio utilizzato dagli ebook reader Kindle.
Provo a risolverlo con i DNS di Eolo, ottengo 99.86.162.169, che è localizzato a Milano (https://db-ip.com/99.86.162.169) e pinga circa 15ms, con TTL 247.
Ecco un traceroute (vedi MXP alla fine):
traceroute to 99.86.162.169 (99.86.162.169), 30 hops max, 60 byte packets
1 Router.lan (***) 0.413 ms 0.281 ms 0.240 ms
2 pppoe-server.net.ngi.it (81.174.0.21) 11.076 ms 10.997 ms 13.106 ms
3 * * *
4 99.83.65.130 (99.83.65.130) 18.049 ms 18.966 ms 18.878 ms
5 150.222.229.37 (150.222.229.37) 32.193 ms 150.222.229.45 (150.222.229.45) 18.803 ms 18.696 ms
6 52.119.152.145 (52.119.152.145) 17.149 ms 52.119.152.147 (52.119.152.147) 12.020 ms 52.119.152.199 (52.119.152.199) 11.791 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 server-99-86-162-169.mxp64.r.cloudfront.net (99.86.162.169) 20.463 ms 18.702 ms 18.628 ms
Provo a risolverlo con Cloudflare, ottengo 13.224.89.13, che è localizzato a Zurigo (https://db-ip.com/13.224.89.13) e pinga circa 30ms, con TTL 241 (quindi attraversa 6 ulteriori hop).
Ecco un traceroute (vedi che passa da Cogent andando all'estero).
traceroute to 13.224.89.13 (13.224.89.13), 30 hops max, 60 byte packets
1 Router.lan (***) 0.522 ms 0.255 ms 0.239 ms
2 pppoe-server.net.ngi.it (81.174.0.21) 7.157 ms 7.072 ms 6.986 ms
3 * * *
4 be4262.nr51.b019138-1.mil01.atlas.cogentco.com (149.14.134.97) 14.293 ms 14.054 ms 13.978 ms
5 be2330.rcr21.mil01.atlas.cogentco.com (154.25.9.189) 15.047 ms 14.949 ms 14.732 ms
6 be2196.ccr52.zrh02.atlas.cogentco.com (154.54.61.89) 17.249 ms be2195.ccr51.zrh02.atlas.cogentco.com (154.54.61.81) 26.720 ms be2196.ccr52.zrh02.atlas.cogentco.com (154.54.61.89) 26.476 ms
7 be2395.rcr51.b021037-0.zrh02.atlas.cogentco.com (130.117.50.26) 27.725 ms be2387.rcr51.b021037-0.zrh02.atlas.cogentco.com (130.117.49.166) 26.794 ms be2395.rcr51.b021037-0.zrh02.atlas.cogentco.com (130.117.50.26) 26.673 ms
8 amazon.demarc.cogentco.com (149.14.213.58) 33.146 ms amazon.demarc.cogentco.com (149.14.213.50) 22.014 ms 21.829 ms
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 server-13-224-89-13.zrh50.r.cloudfront.net (13.224.89.13) 34.015 ms 35.254 ms 34.031 ms
Questi 6 ulteriori hop potrebbero essere congestionati; inoltre Cogent può essere più facilmente impattato essendo il principale transit verso l'estero.
Con questo non sto dicendo che automaticamente usare DNS diversi dagli operatori porti a download più lenti, anzi!
Però non si può neanche affermare il contrario e nel caso di alcune CDN come Akamai e Cloudfront che si basano sull'IP del DNS resolver, usare DNS non dell'operatore (o senza EDNS-SUBNET) può portarti lontano da contenuti che in realtà sono vicini.
