Domain Name System (DNS) latence je klíčovou součástí mít dobré on-line zážitek. A aby se minimalizovala latence DNS, hraje důležitou roli pečlivé vybírání serverů DNS a anonymizačních relé.
ale nejlepší způsob, jak minimalizovat latenci, je vyhnout se odesílání zbytečných dotazů. Proto byl DNS od prvního dne navržen jako silně cacheable protokol. Jednotlivé záznamy mají time-to-live (TTL), původně stanovené zóny správci, a resolvery použít tyto informace, aby tyto záznamy v paměti, aby se zabránilo zbytečnému provozu.
je ukládání do mezipaměti efektivní? Rychlá studie, kterou jsem udělal před pár lety, ukázala, že existuje prostor pro zlepšení. Dnes se chci znovu podívat na současný stav věcí.
K tomu, že jsem opravenou Šifrované DNS Server pro ukládání původní TTL odpovědi, definované jako minimální TTL jeho záznamy, pro každou příchozí dotaz. To nám dává dobrý přehled o distribuci TTL v reálném provozu, ale také odpovídá popularitě jednotlivých dotazů.
tato opravená verze byla ponechána běžet několik hodin. Výsledná datová sada se skládá z 1 583 579 (name, qtype, TTL, timestamp) n-tic. Zde je celkový TTL distribuce (na ose X je hodnota TTL v sekundách):
Kromě zanedbatelné narazit na 86,400 (hlavně pro SOA záznamů), je zřejmé, že se TTLs jsou v nízkém rozsahu. Pojďme si přiblížit:
v Pořádku, TTLs nad 1 hodinu jsou statisticky nevýznamné. Pojďme se zaměřit na 0-3,600 rozsah:
A kde se většina TTLs sedět mezi 0 a 15 minut:
drtivá většina je mezi 0 a 5 minut:
to není skvělé. Kumulativní distribuce může problém ještě více objasnit:
Půl Internetu má 1 minutu TTL nebo méně, a tři čtvrtiny mají 5 minut TTL nebo méně.
ale počkejte, to je ve skutečnosti horší. Jedná se o TTL definované autoritativními servery. TTLs načtené z klientských resolverů (například směrovačů, lokálních cache) však získají TTL, které upstream resolvery snižují každou sekundu. Tak, v průměru, skutečná doba trvání klient může použít do mezipaměti položku, než vyžaduje nový dotaz je polovina původní TTL.
možná tyto velmi nízké TTL ovlivňují pouze neobvyklé dotazy a ne populární webové stránky a API. Pojďme se podívat:
bohužel nejoblíbenější dotazy jsou také nejvíce zbytečné do mezipaměti. Pojďme přiblížit:
verdikt: je to opravdu špatné, nebo spíše už to bylo špatné a zhoršilo se to. Ukládání do mezipaměti DNS se stalo téměř zbytečným. S menším počtem lidí, kteří používají DNS resolver svého ISP (z dobrých důvodů), se zvýšená latence stává znatelnější. Ukládání do mezipaměti DNS se stalo užitečným pouze pro obsah, který nikdo nenavštěvuje. Všimněte si také, že software může interpretovat nízké TTLs odlišně.
proč?
proč jsou záznamy DNS nastaveny s tak nízkými TTLs?
- starší vyvažovače zatížení jsou ponechány s výchozím nastavením.
- městská legenda, že vyvažování zátěže založené na DNS závisí na TTLs(není).
- Administrátoři chtějí, aby jejich změny byly aplikovány okamžitě, protože to může vyžadovat méně plánovacích prací.
- Jako DNS nebo zatížení vyrovnávání správce, vaší povinností je efektivně nasadit konfigurace se lidé ptají, a ne, aby se webové stránky a služby rychle.
- nízké TTLs dávají klid.
do tohoto seznamu nezahrnuji „pro převzetí služeb při selhání“, protože se to stává stále méně relevantní. Pokud je záměrem přesměrovat uživatele do jiné sítě jen proto, aby zobrazili stránku fail whale, když je absolutně všechno ostatní v plamenech, je pravděpodobně přijatelné mít více než minutové zpoždění.
Cdn a load-balancery jsou do značné míry na vině, a to zejména, když se spojí záznamy CNAME s krátkými TTLs se záznamy, které mají také krátkou (ale nezávisle) TTLs:
$ drill raw.githubusercontent.comraw.githubusercontent.com. 9 IN CNAME github.map.fastly.net.github.map.fastly.net. 20 IN A 151.101.128.133github.map.fastly.net. 20 IN A 151.101.192.133github.map.fastly.net. 20 IN A 151.101.0.133github.map.fastly.net. 20 IN A 151.101.64.133
nový dotaz musí být zaslány kdykoliv CNAME nebo na kteroukoli záznamy končí. Oba mají 30sekundový TTL, ale nejsou ve fázi. Skutečný průměrný TTL bude 15 sekund.
ale počkejte! Tohle je horší. Některé resolvery se chovají docela špatně v takové situaci low-TTL-CNAME+low-TTL-records:
$ drill raw.githubusercontent.com @4.2.2.2raw.githubusercontent.com. 1 IN CNAME github.map.fastly.net.github.map.fastly.net. 1 IN A 151.101.16.133
Toto je resolver Level3, který, myslím, běží BIND. Pokud budete tento dotaz stále odesílat, vrácený TTL bude vždy 1. V podstatě, raw.githubusercontent.com nikdy nebude uložen do mezipaměti.
zde je další příklad situace low-TTL-CNAME+low-TTL-records s velmi populárním názvem:
$ drill detectportal.firefox.com @1.1.1.1detectportal.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.106a1089.dscd.akamai.net. 10 IN A 104.123.50.88
ne méně než tři záznamy CNAME. AU. Jeden z nich má slušný TTL, ale je to naprosto zbytečné. Ostatní CNAMEs mají původní TTL 60 sekund; akamai.net jména mají maximální TTL 20 sekund a nic z toho není ve fázi.
a co ten, který vaše zařízení Apple neustále volí?
$ drill 1-courier.push.apple.com @4.2.2.21-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.84gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
stejná konfigurace jako Firefox a TTL je při použití resolveru Level3 většinu času přilepená na 1.
a co Dropbox?
$ drill client.dropbox.com @8.8.8.8client.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.2client.dropbox.com. 1 IN CNAME client.dropbox-dns.com.client.dropbox-dns.com. 1 IN A 162.125.64.3
safebrowsing.googleapis.com má TTL 60 sekund. Facebook jména mají 60 sekund TTL. A opět z pohledu klienta by tyto hodnoty měly být sníženy na polovinu.
co takhle nastavit minimální TTL?
Pomocí název, typ dotazu, TTL a časové razítko původně uloženy, jsem napsal skript, který simuluje 1,5+ milionu dotazů prochází caching resolver odhadnout, jak mnoho dotazů, které byly zaslány z důvodu prošlé položky mezipaměti. 47.4% dotazů bylo provedeno po vypršení platnosti existující položky v mezipaměti. To je nepřiměřeně vysoké.
jaký by byl dopad na ukládání do mezipaměti, kdyby bylo nastaveno minimální TTL?
osa X je minimální TTL, která byla nastavena. Záznamy, jejichž původní TTL byl vyšší než tato hodnota, nebyly ovlivněny. Osa Y je procento dotazů provedených klientem, který již měl položku uloženou v mezipaměti, ale byl proveden nový dotaz a položka uložená v mezipaměti vypršela.
počet dotazů klesne ze 47% na 36% pouhým nastavením minimálního TTL 5 minut. Nastavení minimálního TTL 15 minut způsobí, že počet požadovaných dotazů klesne na 29%. Minimální TTL 1 hodina způsobí pokles na 17%. To je podstatný rozdíl!
Co takhle nezměnit nic na straně serveru, ale mít klientské mezipaměti DNS (směrovače, místní resolvery a mezipaměti…) místo toho nastavit minimální TTL?
počet potřebných dotazů kapky z 47% na 34%, a to stanovením minimální TTL 5 minut, k 25% s 15-minutové minimální, a 13% s 1-hodinovou minimální. 40 minut možná sladké místo. Dopad této minimální změny je obrovský.
jaké jsou důsledky?
služba může samozřejmě přejít na nového poskytovatele cloudu, nový server, novou síť, vyžadující, aby klienti používali aktuální záznamy DNS. A s přiměřeně nízkým TTLs pomáhá přechod bez tření. Nicméně, nikdo se stěhuje do nové infrastruktury bude očekávat, že klienti se používat nové DNS záznamy do 1 minuty, 5 minut nebo 15 minut.
nastavení minimálního TTL 40 minut namísto 5 minut nezabrání uživatelům v přístupu ke službě. Drasticky však sníží latenci a zlepší soukromí (více dotazů = více možností sledování) a spolehlivost tím, že se vyhne nepotřebným dotazům.
RFC samozřejmě říkají, že TTLs by měly být přísně respektovány. Realita je však taková, že DNS se stala neefektivní.
Pokud provozujete autoritativní servery DNS, znovu navštivte své TTLs. Opravdu potřebujete, aby byly směšně nízké?
číst: Jak zvolit hodnoty DNS TTL
jistě, existují platné důvody pro použití nízkých DNS TTLs. Ale ne pro 75% Internetu, aby sloužil obsahu, který je většinou neměnný,ale nemá smysl ukládat do mezipaměti. A pokud z jakýchkoli důvodů opravdu potřebujete používat nízké DNS TTLs, ujistěte se také, že mezipaměť nefunguje ani na vašem webu. Ze stejných důvodů.
Pokud používáte lokální mezipaměť DNS, jako je dnscrypt-proxy, která umožňuje nastavit minimální TTLs, použijte tuto funkci. To je v pořádku. Nic špatného se nestane. Nastavte minimální TTL na něco mezi 40 minutami (2400 sekund) a 1 hodinou; to je naprosto rozumný rozsah.
převzato z původního příspěvku, který se objevil na 00f.net