Nízká latence DNS je klíčem k rychlému procházení internetu. Chcete-li jej minimalizovat, je důležité pečlivě vybrat servery DNS a . Ale prvním krokem je zbavit se zbytečných dotazů.
To je důvod, proč byl DNS původně navržen jako vysoce cacheovatelný protokol. Správci zón nastavují pro jednotlivé záznamy dobu životnosti (TTL) a překladače tyto informace využívají při ukládání záznamů do paměti, aby se zabránilo zbytečnému provozu.
Je ukládání do mezipaměti efektivní? Před pár lety můj malý průzkum ukázal, že to není dokonalé. Pojďme se podívat na současný stav.
Abych sbíral informace, které jsem opravoval pro uložení hodnoty TTL pro odpověď. Je definován jako minimální TTL jeho záznamů pro každý příchozí požadavek. To dává dobrý přehled o TTL rozložení reálného provozu a také zohledňuje oblíbenost jednotlivých požadavků. Opravená verze serveru fungovala několik hodin.
Výsledná datová sada se skládá z 1 583 579 záznamů (název, qtype, TTL, časové razítko). Zde je celková distribuce TTL (osa X je TTL v sekundách):
Kromě menšího nárazu na 86 (většinou pro záznamy SOA) je docela jasné, že TTL jsou v nízkém rozsahu. Podívejme se blíže:
Dobře, TTL větší než 1 hodina nejsou statisticky významné. Pak se zaměřme na rozsah 0–3600:
Většina TTL je od 0 do 15 minut:
Naprostá většina je od 0 do 5 minut:
Není to moc dobré.
Kumulativní distribuce dělá problém ještě jasnějším:
Polovina odpovědí DNS má TTL 1 minutu nebo méně a tři čtvrtiny mají TTL 5 minut nebo méně.
Ale počkat, ve skutečnosti je to horší. Koneckonců, toto je TTL z autoritativních serverů. Klientské překladače (např. routery, místní mezipaměti) však obdrží TTL od upstream resolverů a každou sekundu se snižuje.
Klient tedy může před odesláním nového požadavku skutečně použít každý záznam v průměru za polovinu původního TTL.
Možná se tyto velmi nízké hodnoty TTL vztahují pouze na neobvyklé požadavky a ne na oblíbené webové stránky a rozhraní API? Pojďme se podívat:
Osa X je TTL, osa Y je popularita dotazu.
Bohužel nejoblíbenější dotazy se také nejhůře ukládají do mezipaměti.
Pojďme to přiblížit:
Verdikt: je to opravdu špatné. Už předtím to bylo špatné, ale bylo to ještě horší. Ukládání DNS do mezipaměti se stalo prakticky zbytečným. Čím méně lidí používá DNS resolver svého ISP (z dobrých důvodů), zvýšení latence je znatelnější.
Ukládání do mezipaměti DNS se stalo užitečným pouze pro obsah, který nikdo nenavštěvuje.
Upozorňujeme také, že software může interpretovat nízké TTL.
Proč tomu tak je?
Proč jsou DNS záznamy nastaveny na tak nízké TTL?
- Starší nástroje pro vyrovnávání zatížení byly ponechány s výchozím nastavením.
- Existují mýty, že DNS load balancing závisí na TTL (to není pravda – od dob Netscape Navigatoru si klienti vybírali náhodnou IP adresu ze sady RR a transparentně zkoušeli jinou, pokud se nemohou připojit)
- Správci chtějí změny aplikovat okamžitě, takže je snadnější plánovat.
- Správce serveru DNS nebo nástroje pro vyrovnávání zatížení vidí svůj úkol jako efektivní nasazení konfigurace, kterou uživatelé požadují, a nikoli zrychlení webů a služeb.
- Nízké TTL vám zajistí klid.
- Lidé zpočátku nastavili nízké TTL pro testování a pak je zapomněli změnit.
"Failover" jsem do seznamu nezahrnul, protože je stále méně relevantní. Pokud potřebujete přesměrovat uživatele do jiné sítě jen proto, abyste zobrazili chybovou stránku, když je úplně všechno ostatní nefunkční, je pravděpodobně přijatelné zpoždění delší než 1 minuta.
Jednominutové TTL navíc znamená, že pokud jsou autoritativní servery DNS blokovány déle než 1 minutu, nikdo jiný nebude mít přístup k závislým službám. A redundance nepomůže, pokud je příčinou chyba konfigurace nebo hack. Na druhou stranu s rozumnými TTL bude mnoho klientů nadále používat předchozí konfiguraci a nikdy si ničeho nevšimnou.
Služby CDN a nástroje pro vyrovnávání zátěže jsou z velké části na vině za nízké TTL, zvláště když kombinují CNAME s nízkými TTL a záznamy se stejně nízký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ší platnost záznamu CNAME nebo kteréhokoli ze záznamů A, je nutné odeslat nový požadavek. Oba mají 30 sekund TTL, ale není to totéž. Skutečný průměr TTL bude 15 sekund.
Ale počkej! Je to ještě horší. Některé resolvery se v této situaci chovají velmi špatně se dvěma souvisejícími nízkými TTL:
$ drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 V CNAME github.map.fastly.net. github.map.fastly.net. 1 V A 151.101.16.133
Překladač úrovně 3 pravděpodobně běží na BIND. Pokud budete pokračovat v odesílání tohoto požadavku, vždy se vrátí TTL 1. V podstatě raw.githubusercontent.com se nikdy neukládá do mezipaměti.
Zde 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
Alespoň tři záznamy CNAME. Ano. Jeden má slušné TTL, ale je úplně k ničemu. Ostatní CNAME mají počáteční TTL 60 sekund, ale pro domény akamai.net maximální TTL je 20 sekund a žádná z nich není ve fázi.
A 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 se při použití překladače Level1 většinu času zasekne na 3 sekundě.
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 A 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 V A 162.125.64.3
Na nahrávce safebrowsing.googleapis.com Hodnota TTL je 60 sekund, jako u domén Facebooku. A opět z pohledu klienta jsou tyto hodnoty poloviční.
Co takhle nastavit minimální TTL?
Pomocí názvu, typu požadavku, TTL a původně uloženého časového razítka jsem napsal skript pro simulaci 1,5 milionu požadavků procházejících cachovacím resolverem, abych odhadl objem zbytečných požadavků odeslaných kvůli vypršenému záznamu v mezipaměti.
47,4 % žádostí bylo podáno po vypršení platnosti existujícího záznamu. To je nepřiměřeně vysoké.
Jaký bude mít dopad na ukládání do mezipaměti, pokud bude nastaveno minimální TTL?
Osa X představuje minimální hodnoty TTL. Záznamy se zdrojovými TTL nad touto hodnotou nejsou ovlivněny.
Osa Y je procento požadavků od klienta, který již má záznam v mezipaměti, ale jeho platnost vypršela a odesílá nový požadavek.
Podíl „extra“ požadavků se sníží ze 47 % na 36 % pouhým nastavením minimální TTL na 5 minut. Nastavením minimálního TTL na 15 minut klesne počet těchto požadavků na 29 %. Minimální TTL 1 hodina je snižuje na 17 %. Výrazný rozdíl!
Co takhle neměnit nic na straně serveru, ale místo toho nastavit minimální TTL v mezipaměti DNS klienta (směrovače, místní překladače)?
Počet požadovaných požadavků klesne ze 47 % na 34 % s minimálním TTL 5 minut, na 25 % s minimálně 15 minutami a na 13 % s minimálně 1 hodinou. Optimálních je možná 40 minut.
Dopad této malé změny je obrovský.
Jaké jsou důsledky?
Službu lze samozřejmě přesunout k novému cloudovému poskytovateli, novému serveru, nové síti, což vyžaduje, aby klienti používali nejnovější DNS záznamy. A docela malé TTL pomáhá k hladkému a nepostřehnutelnému přechodu. Ale s přechodem na novou infrastrukturu nikdo neočekává, že klienti migrují na nové DNS záznamy během 1 minuty, 5 minut nebo 15 minut. Nastavení minimální doby TTL na 40 minut místo 5 minut nezabrání uživatelům v přístupu ke službě.
To však výrazně sníží latenci a zlepší soukromí a spolehlivost tím, že se vyhnete zbytečným požadavkům.
Samozřejmě, že RFC říkají, že TTL se musí přísně dodržovat. Ale realita je taková, že systém DNS se stal příliš neefektivním.
Pokud pracujete s autoritativními servery DNS, zkontrolujte své TTL. Opravdu potřebujete tak směšně nízké hodnoty?
Samozřejmě existují dobré důvody pro nastavení malých TTL pro DNS záznamy. Ale ne pro 75 % provozu DNS, který zůstává prakticky nezměněn.
A pokud z nějakého důvodu opravdu potřebujete použít nízké TTL pro DNS, zároveň se ujistěte, že váš web nemá povolenou mezipaměť. Ze stejných důvodů.
Pokud máte spuštěnou lokální DNS cache, jako např která umožňuje nastavit minimální TTL, použijte tuto funkci. Tohle je fajn. Nic zlého se nestane. Nastavte minimální TTL na přibližně 40 minut (2400 sekund) a 1 hodinu. Docela rozumný rozsah.
Zdroj: www.habr.com