La baixa latència de DNS és clau per a una navegació ràpida per Internet. Per minimitzar-ho, és important seleccionar amb cura els servidors DNS i . Però el primer pas és desfer-se de consultes inútils.
És per això que el DNS es va dissenyar originalment com un protocol molt cacheable. Els administradors de la zona estableixen un temps de vida (TTL) per a entrades individuals i els resolutors utilitzen aquesta informació quan emmagatzemen entrades a la memòria per evitar trànsit innecessari.
És eficaç la memòria cau? Fa un parell d'anys, la meva petita investigació va demostrar que no era perfecte. Fem una ullada a l'estat actual de les coses.
Per recollir la informació que he pegat per desar el valor TTL per a la resposta. Es defineix com el TTL mínim dels seus registres per a cada sol·licitud entrant. Això ofereix una bona visió general de la distribució TTL del trànsit real i també té en compte la popularitat de les sol·licituds individuals. La versió pegada del servidor va funcionar durant diverses hores.
El conjunt de dades resultant consta de 1 registres (nom, qtype, TTL, marca de temps). Aquí teniu la distribució general de TTL (l'eix X és TTL en segons):
A part d'un petit cop a 86 (sobretot per a registres SOA), és bastant clar que els TTL es troben en el rang baix. Fem una ullada més de prop:
D'acord, els TTL superiors a 1 hora no són estadísticament significatius. A continuació, centrem-nos en el rang 0−3600:
La majoria de TTL són de 0 a 15 minuts:
La gran majoria són de 0 a 5 minuts:
No és gaire bo.
La distribució acumulada fa que el problema sigui encara més evident:
La meitat de les respostes DNS tenen un TTL d'1 minut o menys, i tres quartes parts tenen un TTL de 5 minuts o menys.
Però espera, en realitat és pitjor. Després de tot, això és TTL de servidors autoritzats. Tanmateix, els solucionadors de clients (per exemple, encaminadors, memòria cau local) reben un TTL dels solucionadors amunt i disminueix cada segon.
Així, el client pot utilitzar cada entrada per, de mitjana, la meitat del TTL original abans d'enviar una nova sol·licitud.
Potser aquests TTL tan baixos només s'apliquen a sol·licituds inusuals i no a llocs web i API populars? Fem una ullada:
L'eix X és TTL, l'eix Y és la popularitat de la consulta.
Malauradament, les consultes més populars també són les pitjors per a la memòria cau.
Ampliem:
Veredicte: és molt dolent. Abans ja era dolent, però encara va empitjorar. La memòria cau DNS s'ha tornat pràcticament inútil. A mesura que menys persones utilitzen el solucionador DNS del seu ISP (per bones raons), l'augment de la latència es fa més notable.
La memòria cau DNS s'ha tornat útil només per al contingut que ningú visita.
Tingueu en compte també que el programari pot interpretar TTL baixos.
Per què?
Per què s'estableixen els registres DNS amb un TTL tan baix?
- Els equilibradors de càrrega heretats es van deixar amb la configuració predeterminada.
- Hi ha mites que l'equilibri de càrrega de DNS depèn del TTL (això no és cert: des dels dies de Netscape Navigator, els clients han triat una adreça IP aleatòria d'un conjunt de RR i n'han provat una altra de manera transparent si no es poden connectar)
- Els administradors volen aplicar els canvis immediatament, de manera que és més fàcil planificar.
- L'administrador d'un servidor DNS o equilibrador de càrrega considera que la seva tasca és desplegar de manera eficient la configuració que demanen els usuaris i no accelerar els llocs i els serveis.
- Els TTL baixos us donen tranquil·litat.
- La gent inicialment estableix uns TTL baixos per a la prova i després s'obliden de canviar-los.
No he inclòs el "failover" a la llista perquè cada cop és menys rellevant. Si necessiteu redirigir els usuaris a una altra xarxa només per mostrar una pàgina d'error quan absolutament tota la resta està trencada, probablement s'accepta un retard de més d'1 minut.
A més, un TTL d'un minut significa que si els servidors DNS autoritzats es bloquegen durant més d'1 minut, ningú més podrà accedir als serveis dependents. I la redundància no ajudarà si la causa és un error de configuració o un pirateig. D'altra banda, amb TTL raonables, molts clients continuaran utilitzant la configuració anterior i mai no notaran res.
Els serveis CDN i els equilibradors de càrrega són en gran part els culpables dels TTL baixos, especialment quan combinen CNAME amb TTL baixos i registres amb TTL igualment baixos (però independents):
$ drill raw.githubusercontent.com raw.githubusercontent.com. 9 IN CNAME github.map.fastly.net. github.map.fastly.net. 20 IN A 151.101.128.133 github.map.fastly.net. 20 IN A 151.101.192.133 github.map.fastly.net. 20 IN A 151.101.0.133 github.map.fastly.net. 20 IN A 151.101.64.133
Sempre que caduqui el CNAME o qualsevol dels registres A, s'ha d'enviar una nova sol·licitud. Tots dos tenen un TTL de 30 segons, però no és el mateix. El TTL mitjà real serà de 15 segons.
Però espera! És encara pitjor. Alguns solucionadors es comporten molt malament en aquesta situació amb dos TTL baixos associats:
$ drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 A CNAME github.map.fastly.net. github.map.fastly.net. 1 EN A 151.101.16.133
El solucionador de nivell 3 probablement s'executa a BIND. Si continueu enviant aquesta sol·licitud, sempre es retornarà un TTL d'1. raw.githubusercontent.com mai es guarda a la memòria cau.
Aquí teniu un altre exemple d'aquesta situació amb un domini molt popular:
$ drill detectportal.firefox.com @1.1.1.1 detectportal.firefox.com. 25 IN CNAME detectportal.prod.mozaws.net. detectportal.prod.mozaws.net. 26 IN CNAME detectportal.firefox.com-v2.edgesuite.net. detectportal.firefox.com-v2.edgesuite.net. 10668 IN CNAME a1089.dscd.akamai.net. a1089.dscd.akamai.net. 10 IN A 104.123.50.106 a1089.dscd.akamai.net. 10 IN A 104.123.50.88
Almenys tres registres CNAME. Ai. Un té un TTL decent, però és completament inútil. Altres CNAME tenen un TTL inicial de 60 segons, però per als dominis akamai.net el TTL màxim és de 20 segons i cap d'ells està en fase.
Què passa amb els dominis que enquesten constantment els dispositius Apple?
$ drill 1-courier.push.apple.com @4.2.2.2 1-courier.push.apple.com. 1253 IN CNAME 1.courier-push-apple.com.akadns.net. 1.courier-push-apple.com.akadns.net. 1 IN CNAME gb-courier-4.push-apple.com.akadns.net. gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.84 gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
El mateix problema que el Firefox i el TTL s'enganxaran a 1 segon la major part del temps quan s'utilitzi la resolució de nivell 3.
Dropbox?
$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 A CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 EN A 162.125.67.3 $ drill client.dropbox.com @4.2.2.2 client.dropbox.com. 1 A CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 EN A 162.125.64.3
A la gravació safebrowsing.googleapis.com El valor TTL és de 60 segons, com els dominis de Facebook. I, de nou, des del punt de vista del client, aquests valors es redueixen a la meitat.
Què tal establir un TTL mínim?
Utilitzant el nom, el tipus de sol·licitud, el TTL i la marca de temps emmagatzemada originalment, vaig escriure un script per simular 1,5 milions de sol·licituds que passaven per una solució de memòria cau per estimar el volum de sol·licituds innecessàries enviades a causa d'una entrada de memòria cau caducada.
El 47,4% de les sol·licituds es van fer després d'haver caducat un registre existent. Això és excessivament alt.
Quin serà l'impacte en la memòria cau si s'estableix el TTL mínim?
L'eix X són els valors mínims de TTL. Els registres amb TTL d'origen per sobre d'aquest valor no es veuen afectats.
L'eix Y és el percentatge de sol·licituds d'un client que ja té una entrada a la memòria cau, però que ha caducat i està fent una nova sol·licitud.
La quota de sol·licituds "extra" es redueix del 47% al 36% simplement establint el TTL mínim a 5 minuts. En establir el TTL mínim a 15 minuts, el nombre d'aquestes sol·licituds baixa al 29%. Un TTL mínim d'1 hora els redueix al 17%. Diferència important!
Què tal no canviar res al costat del servidor, sinó establir el TTL mínim a la memòria cau DNS del client (encaminadors, resolutors locals)?
El nombre de sol·licituds requerides baixa del 47% al 34% amb un TTL mínim de 5 minuts, al 25% amb un mínim de 15 minuts i al 13% amb un mínim d'1 hora. Potser 40 minuts són òptims.
L'impacte d'aquest petit canvi és enorme.
Quines són les conseqüències?
Per descomptat, el servei es pot traslladar a un nou proveïdor de núvol, un nou servidor, una nova xarxa, requerint que els clients utilitzin els últims registres DNS. I un TTL bastant petit ajuda a fer aquesta transició de manera suau i imperceptible. Però amb la transició a una nova infraestructura, ningú espera que els clients migrin a nous registres DNS en 1 minut, 5 minuts o 15 minuts. Establir el TTL mínim a 40 minuts en lloc de 5 minuts no impedirà que els usuaris accedeixin al servei.
Tanmateix, això reduirà significativament la latència i millorarà la privadesa i la fiabilitat evitant sol·licituds innecessàries.
Per descomptat, els RFC diuen que s'ha de seguir estrictament el TTL. Però la realitat és que el sistema DNS s'ha tornat massa ineficient.
Si esteu treballant amb servidors DNS autoritzats, comproveu els vostres TTL. Realment necessiteu valors tan ridículament baixos?
Per descomptat, hi ha bones raons per establir TTL petits per als registres DNS. Però no pel 75% del trànsit DNS que es manté pràcticament sense canvis.
I si per algun motiu realment necessiteu utilitzar TTL baixos per a DNS, al mateix temps, assegureu-vos que el vostre lloc no tingui la memòria cau activada. Per les mateixes raons.
Si teniu una memòria cau DNS local en funcionament, com ara que us permet establir TTL mínims, utilitzeu aquesta funció. Això està bé. No passarà res dolent. Estableix el TTL mínim a aproximadament 40 minuts (2400 segons) i 1 hora. Un rang força raonable.
Font: www.habr.com