Nízká latence DNS je klíčovým faktorem pro rychlé fungování internetu. Abychom ji minimalizovali, je důležité pečlivě vybírat DNS servery a . Ale nejprve je třeba zbavit se zbytečných dotazů.
Proto byl DNS původně navržen jako silně cachovaný protokol. Správci zón nastavují čas života (TTL) pro jednotlivé záznamy, a resolver'y tuto informaci používají k ukládání záznamů do paměti, aby se vyhnuli zbytečnému provozu.
Je caching efektivní? Před pár lety jsem provedl malý výzkum, který ukázal, že to není dokonalé. Pojďme se podívat na aktuální stav.
Pro shromáždění informací jsem upravil pro zachování hodnoty TTL pro odpověď. Ta je určena jako minimální TTL jeho záznamů pro každý příchozí dotaz. To poskytuje dobrý přehled o rozložení TTL skutečného provozu a také zohledňuje popularitu jednotlivých dotazů. Upravená verze serveru fungovala několik hodin.
Výsledný datový soubor se skládá z 1 583 579 záznamů (name, qtype, TTL, timestamp). Zde je celkové rozložení TTL (osa X je TTL v sekundách):
Pokud nepočítáme drobný vrchol na 86 400 (většinou pro záznamy SOA), je docela jasné, že TTL se nacházejí v nízkém rozsahu. Podívejme se blíže:
Dobře, TTL přes 1 hodinu jsou statisticky nevýznamné. Takže se zaměřme na rozsah 0−3600:
Většina TTL od 0 do 15 minut:
Drtivá většina od 0 do 5 minut:
To není moc dobré.
Kumulativní rozložení dělá problém ještě zřetelnějším:
V polovině DNS odpovědí TTL činí 1 minutu nebo méně, a u tří čtvrtin je 5 minut nebo méně.
Ale počkejte, ve skutečnosti je to ještě horší. Vždyť to jsou TTL od autoritativních serverů. Avšak klientské resolvery (např. routery, místní cache) získávají TTL od nadřazených resolverů, a ten se každou sekundu zkracuje.
Takže klient může ve skutečnosti používat každý záznam v průměru polovinu původního TTL, po čemž odešle nový dotaz.
Možná, že tyto velmi nízké TTL se týkají pouze neobvyklých dotazů, nikoli populárních webových stránek a API? Pojďme se podívat:
Osa X je TTL, osa Y je popularita dotazů.
Bohužel, nejpopulárnější dotazy jsou také ty, které se nejhůře cachují.
Přiblížíme:
Verdikt: je to skutečně špatné. Už to bylo špatné, a teď je to ještě horší. DNS caching se stal téměř k ničemu. Protože stále méně lidí používá DNS resolver svého poskytovatele (z vážných důvodů), zpoždění se stává více viditelným.
DNS caching se stal užitečným pouze pro obsah, který nikdo nenavštěvuje.
Také mějte na paměti, že software může interpretovat nízké TTL.
Proč tomu tak je?
Proč je pro DNS záznamy nastavena tak nízká TTL?
- Zastaralé load balancery zůstaly s výchozími nastaveními.
- Kolují mýty, že load balancing přes DNS závisí na TTL (to není pravda – od dob Netscape Navigatoru si klienti vybírají náhodnou IP adresu ze sady RR a transparentně zkouší jinou, pokud se nemohou připojit)
- Administrátoři chtějí aplikovat změny okamžitě, protože je to tak jednodušší pro plánování.
- Administrátor DNS serveru nebo load balancer vidí svou úlohu v efektivním nasazení konfigurace, kterou uživatelé požadují, nikoli v zrychlování webových stránek a služeb.
- Nízké TTL poskytují duševní klid.
- Lidé původně nastavují nízké TTL pro testování a pak na to zapomínají změnit.
Nezahrnul jsem do seznamu 'zpracování selhání', protože to je stále méně aktuální. Pokud je třeba přesměrovat uživatele do jiné sítě pouze pro zobrazení chybové stránky, když je vše ostatní úplně rozbité, pravděpodobně je přijatelná prodleva delší než 1 minuta.
Kromě toho minutové TTL znamená, že pokud budou autoritativní DNS servery zablokovány více než na 1 minutu, nikdo jiný nebude schopen přistupovat k závislým službám. A redundance nepomůže, pokud je příčinou chyba konfigurace nebo hack. Na druhou stranu, při rozumných TTL mnoho klientů stále použije předchozí konfiguraci a nikdy si ničeho nevšimnou.
Na nízkých TTL se výrazně podílejí CDN služby a load balancery, zvláště když spojují CNAME s malými TTL a záznamy s podobně malými (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
Kdykoli vyprší CNAME nebo některá z A záznamů, je nutné odeslat nový dotaz. Oba mají TTL 30 sekund, ale neodpovídají si. Skutečný průměrný TTL bude 15 sekund.
Ale počkejte! Je to ještě horší. Některé resolvery se v této situaci se dvěma propojenými nízkými TTL chovají velmi špatně:
$ drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 IN CNAME github.map.fastly.net. github.map.fastly.net. 1 IN A 151.101.16.133
Resolver Level3 pravděpodobně běží na BIND. Pokud budete pokračovat v odesílání tohoto dotazu, vždy se vrátí TTL rovné 1. V podstatě, raw.githubusercontent.com nikdy není mezipaměť.
Tady je další příklad takové situace s velmi populární 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
Nejméně tři CNAME záznamy. Ach. U jednoho je slušný TTL, ale to je naprosto k ničemu. U dalších CNAME je prvotní TTL 60 sekund, ale pro domény akamai.net maximální TTL činí 20 sekund a ani jeden z nich není ve fázi.
Co domény, které neustále dotazují zařízení 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
Stejný problém jako u Firefoxu a TTL většinu času uvízne na 1 sekundě při použití resolveru Level3.
Dropbox?
$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 IN A 162.125.67.3 $ drill 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
U záznamu safebrowsing.googleapis.com je TTL 60 sekund, jako u domén Facebooku. A z pohledu klienta se tyto hodnoty zmenšují na polovinu.
Jak je to s nastavením minimálního TTL?
S použitím názvu, typu dotazu, TTL a původně uloženého časového razítka jsem napsal skript pro simulaci 1,5 milionu dotazů procházejících kešovacím resolverem za účelem vyhodnocení objemu zbytečných dotazů odeslaných kvůli vypršení platnosti existujícího záznamu v keši.
47,4 % dotazů bylo provedeno po vypršení platnosti existujícího záznamu. To je neodůvodněně vysoké.
Jaký vliv bude mít nastavení minimálního TTL na kešování?
Osa X jsou minimální hodnoty TTL. Záznamy s původními TTL nad tuto hodnotu nejsou ovlivněny.
Osa Y je procento požadavků od klienta, který již má uložený záznam v cache, ale jeho platnost vypršela a provádí nový požadavek.
Podíl "nadbytečných" požadavků se snižuje z 47 % na 36 % jednoduchým nastavením minimálního TTL na 5 minut. Při nastavení minimálního TTL na 15 minut klesá počet těchto požadavků na 29 %. Minimální TTL na 1 hodinu snižuje jejich počet na 17 %. Významný rozdíl!
Co kdybychom na straně serveru nic nezměnili, ale místo toho nastavili minimální TTL v klientských DNS cache (routery, místní resolver)?
Počet požadovaných požadavků klesá z 47 % na 34 % při nastavení minimálního TTL na 5 minut, na 25 % při minimálně 15 minutách a na 13 % při minimálně 1 hodině. Možná je optimální hodnota 40 minut.
Dopad této minimální změny je obrovský.
Jaké jsou důsledky?
Samozřejmě, službu lze převést k novému cloudovému poskytovateli, na nový server, do nové sítě, což vyžaduje, aby klienti používali poslední DNS záznamy. A dostatečně nízký TTL pomáhá realizovat tento přechod hladce a nenápadně. Ale při přechodu na novou infrastrukturu nikdo neočekává, že klienti přejdou na nové DNS záznamy během 1 minuty, 5 minut nebo 15 minut. Nastavení minimální doby životnosti na 40 minut místo 5 minut nebrání uživatelům v přístupu k službě.
To však výrazně sníží zpoždění a zvýší soukromí a spolehlivost, což předejde zbytečným požadavkům.
Samozřejmě, RFC říká, že je třeba striktně dodržovat TTL. Ale realita je taková, že systém DNS se stal příliš neefektivním.
Pokud pracujete s autoritativními DNS servery, prosím zkontrolujte své TTL. Opravu potřebujete tak směšně nízké hodnoty?
Samozřejmě, existují pádné důvody pro nastavení nízkých TTL pro DNS záznamy. Ale ne pro 75 % DNS provozu, který se prakticky nemění.
A pokud z nějakých důvodů opravdu potřebujete používat nízké TTL pro DNS, zároveň se ujistěte, že na vašem webu není zapnuto cachování. Z týchž důvodů.
Pokud máte spuštěnou místní DNS cache, jako je , který umožňuje nastavovat minimální TTL, využijte tuto funkci. Je to v pořádku. Nic špatného se nestane. Nastavte minimální TTL přibližně mezi 40 minutami (2400 sekund) a 1 hodinou. Naprosto rozumný rozsah.
Zdroj: habr.com
