Nízka latencia DNS je kľúčom k rýchlemu prehliadaniu internetu. Aby ste to minimalizovali, je dôležité starostlivo vybrať servery DNS a . Prvým krokom je však zbaviť sa zbytočných otázok.
To je dôvod, prečo bol DNS pôvodne navrhnutý ako vysoko cacheovateľný protokol. Správcovia zón nastavujú čas trvania (TTL) pre jednotlivé záznamy a resolvery používajú tieto informácie pri ukladaní záznamov do pamäte, aby sa vyhli zbytočnej premávke.
Je ukladanie do vyrovnávacej pamäte efektívne? Pred pár rokmi môj malý výskum ukázal, že to nie je dokonalé. Poďme sa pozrieť na súčasný stav.
Na zhromažďovanie informácií, ktoré som opravil na uloženie hodnoty TTL pre odpoveď. Je definovaný ako minimálny TTL jeho záznamov pre každú prichádzajúcu požiadavku. To dáva dobrý prehľad o rozdelení TTL reálnej prevádzky a zohľadňuje aj obľúbenosť jednotlivých požiadaviek. Opravená verzia servera fungovala niekoľko hodín.
Výsledný súbor údajov pozostáva z 1 583 579 záznamov (názov, qtype, TTL, časová pečiatka). Tu je celkové rozdelenie TTL (os X je TTL v sekundách):
Okrem menšieho nárazu na 86 (väčšinou pre záznamy SOA) je celkom jasné, že TTL sú v nízkom rozsahu. Poďme sa na to pozrieť bližšie:
Dobre, TTL väčšie ako 1 hodina nie sú štatisticky významné. Potom sa zamerajme na rozsah 0–3600:
Väčšina TTL je od 0 do 15 minút:
Prevažná väčšina je od 0 do 5 minút:
Nie je to veľmi dobré.
Kumulatívna distribúcia robí problém ešte zrejmejším:
Polovica odpovedí DNS má TTL 1 minútu alebo menej a tri štvrtiny majú TTL 5 minút alebo menej.
Ale počkajte, v skutočnosti je to horšie. Koniec koncov, toto je TTL od autoritatívnych serverov. Klientske prekladače (napr. smerovače, lokálne vyrovnávacie pamäte) však dostávajú TTL z upstreamových prekladačov a znižuje sa každú sekundu.
Klient tak môže pred odoslaním novej požiadavky skutočne použiť každý záznam v priemere za polovicu pôvodného TTL.
Možno sa tieto veľmi nízke hodnoty TTL vzťahujú iba na neobvyklé požiadavky a nie na obľúbené webové stránky a rozhrania API? Poďme sa pozrieť:
Os X je TTL, os Y je popularita dopytu.
Bohužiaľ, najobľúbenejšie dopyty sa zároveň najhoršie ukladajú do vyrovnávacej pamäte.
Poďme si priblížiť:
Verdikt: je to naozaj zlé. Už predtým to bolo zlé, ale ešte horšie. Ukladanie DNS do vyrovnávacej pamäte sa stalo prakticky zbytočným. Čím menej ľudí používa DNS resolver svojho ISP (z dobrých dôvodov), zvýšenie latencie sa stáva zreteľnejším.
Ukladanie do vyrovnávacej pamäte DNS sa stalo užitočným iba pre obsah, ktorý nikto nenavštevuje.
Upozorňujeme tiež, že softvér môže interpretovať nízke TTL.
Prečo je to?
Prečo sú DNS záznamy nastavené na tak nízke TTL?
- Staršie nástroje na vyrovnávanie záťaže boli ponechané s predvolenými nastaveniami.
- Existujú mýty, že DNS load balancing závisí od TTL (to nie je pravda – od čias Netscape Navigatora si klienti vyberali náhodnú IP adresu zo sady RR a transparentne skúšali inú, ak sa nemôžu pripojiť)
- Správcovia chcú zmeny aplikovať okamžite, takže plánovanie je jednoduchšie.
- Správca servera DNS alebo nástroja na vyvažovanie záťaže považuje za svoju úlohu efektívne nasadenie konfigurácie, ktorú používatelia požadujú, a nie zrýchlenie stránok a služieb.
- Nízke hodnoty TTL vám poskytujú pokoj.
- Ľudia si spočiatku nastavili nízke TTL na testovanie a potom ich zabudli zmeniť.
"Failover" som do zoznamu nezahrnul, pretože je čoraz menej relevantný. Ak potrebujete presmerovať používateľov na inú sieť, aby ste zobrazili chybovú stránku, keď je úplne všetko ostatné pokazené, oneskorenie dlhšie ako 1 minúta je pravdepodobne prijateľné.
Okrem toho jednominútová TTL znamená, že ak sú autoritatívne servery DNS zablokované na viac ako 1 minútu, nikto iný nebude mať prístup k závislým službám. A redundancia nepomôže, ak je príčinou chyba konfigurácie alebo hack. Na druhej strane, s primeranými TTL budú mnohí klienti naďalej používať predchádzajúcu konfiguráciu a nikdy si nič nevšimnú.
Služby CDN a nástroje na vyrovnávanie záťaže sú z veľkej časti zodpovedné za nízke hodnoty TTL, najmä ak kombinujú CNAME s nízkymi TTL a záznamy s rovnako nízkymi (ale nezávislými) TTL:
$ 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
Vždy, keď platnosť záznamu CNAME alebo ktoréhokoľvek zo záznamov A vyprší, je potrebné odoslať novú žiadosť. Obaja majú 30 sekúnd TTL, ale nie je to to isté. Skutočný priemer TTL bude 15 sekúnd.
Ale počkaj! Je to ešte horšie. Niektoré prekladače sa v tejto situácii správajú veľmi zle s dvomi súvisiacimi nízkymi TTL:
$ drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 V CNAME github.map.fastly.net. github.map.fastly.net. 1 IN A 151.101.16.133
Prekladač úrovne 3 pravdepodobne beží na BIND. Ak budete pokračovať v odosielaní tejto žiadosti, vždy sa vráti TTL 1. V podstate raw.githubusercontent.com sa nikdy neukladá do vyrovnávacej pamäte.
Tu je ďalší príklad takejto situácie s veľmi populárnou doménou:
$ 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
Aspoň tri záznamy CNAME. Áno. Jeden má slušné TTL, ale je to úplne zbytočné. Ostatné CNAME majú počiatočné TTL 60 sekúnd, ale pre domény akamai.net maximálna TTL je 20 sekúnd a žiadna z nich nie je vo fáze.
A čo domény, ktoré neustále vyhľadávajú zariadenia 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
Rovnaký problém ako Firefox a TTL sa pri použití prekladača úrovne 1 väčšinu času zasekne na 3 sekundu.
Dropbox?
$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 V CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 V 162.125.67.3 $ vrták client.dropbox.com @4.2.2.2 client.dropbox.com. 1 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 IN A 162.125.64.3
Pri nahrávaní safebrowsing.googleapis.com Hodnota TTL je 60 sekúnd, ako napríklad domény Facebooku. A opäť z pohľadu klienta sú tieto hodnoty polovičné.
Čo tak nastaviť minimálne TTL?
Pomocou názvu, typu požiadavky, TTL a pôvodne uloženej časovej pečiatky som napísal skript na simuláciu 1,5 milióna požiadaviek prechádzajúcich cez cache resolver, aby som odhadol objem zbytočných požiadaviek odoslaných z dôvodu expirovaného záznamu vo vyrovnávacej pamäti.
47,4 % žiadostí bolo podaných po uplynutí platnosti existujúceho záznamu. To je neprimerane vysoké.
Aký bude vplyv na ukladanie do vyrovnávacej pamäte, ak sa nastaví minimálne TTL?
Os X predstavuje minimálne hodnoty TTL. Záznamy so zdrojovými TTL nad touto hodnotou nie sú ovplyvnené.
Os Y predstavuje percento požiadaviek od klienta, ktorý už má položku uloženú vo vyrovnávacej pamäti, ale jej platnosť vypršala a vytvára novú požiadavku.
Podiel „extra“ požiadaviek sa zníži zo 47 % na 36 % jednoduchým nastavením minimálneho TTL na 5 minút. Nastavením minimálneho TTL na 15 minút počet týchto požiadaviek klesne na 29 %. Minimálne TTL 1 hodina ich znižuje na 17 %. Veľký rozdiel!
Čo tak nemeniť nič na strane servera, ale namiesto toho nastaviť minimálne TTL v klientskych DNS cache (smerovače, lokálne prekladače)?
Počet požadovaných požiadaviek klesne zo 47 % na 34 % s minimálnou TTL 5 minút, na 25 % s minimálnou dobou 15 minút a na 13 % s minimálnou 1 hodinou. Optimálnych je asi 40 minút.
Vplyv tejto malej zmeny je obrovský.
Aké sú dôsledky?
Službu je samozrejme možné presunúť k novému poskytovateľovi cloudu, k novému serveru, k novej sieti, čo od klientov vyžaduje používanie najnovších DNS záznamov. A pomerne malý TTL pomáha urobiť takýto prechod hladko a nepostrehnuteľne. S prechodom na novú infraštruktúru však nikto neočakáva, že klienti migrujú na nové DNS záznamy do 1 minúty, 5 minút alebo 15 minút. Nastavenie minimálneho TTL na 40 minút namiesto 5 minút nezabráni používateľom v prístupe k službe.
To však výrazne zníži latenciu a zlepší súkromie a spoľahlivosť tým, že sa vyhnete zbytočným požiadavkám.
Samozrejme, RFC hovoria, že TTL sa musí prísne dodržiavať. Ale realita je taká, že systém DNS sa stal príliš neefektívnym.
Ak pracujete s autoritatívnymi servermi DNS, skontrolujte svoje TTL. Naozaj potrebujete také smiešne nízke hodnoty?
Samozrejme, existujú dobré dôvody na nastavenie malých TTL pre DNS záznamy. Nie však pre 75 % prevádzky DNS, ktorá zostáva prakticky nezmenená.
A ak z nejakého dôvodu naozaj potrebujete použiť nízke TTL pre DNS, zároveň sa uistite, že váš web nemá povolené ukladanie do vyrovnávacej pamäte. Z rovnakých dôvodov.
Ak máte spustenú lokálnu vyrovnávaciu pamäť DNS, ako napr ktorá vám umožňuje nastaviť minimálne hodnoty TTL, použite túto funkciu. Toto je fajn. Nič zlé sa nestane. Nastavte minimálne TTL na približne 40 minút (2400 sekúnd) a 1 hodinu. Celkom rozumný rozsah.
Zdroj: hab.com