Niskie opóźnienie DNS to kluczowy czynnik dla szybkiej pracy w internecie. Aby je zminimalizować, ważne jest staranne dobranie serwerów DNS oraz . Jednak najpierw należy pozbyć się zbędnych zapytań.
Właśnie dlatego DNS został pierwotnie stworzony jako mocno buforowany protokół. Administratorzy stref ustalają czas życia (TTL) dla poszczególnych rekordów, a resolverzy wykorzystują te informacje podczas przechowywania rekordów w pamięci, aby uniknąć zbędnego ruchu.
Czy buforowanie jest skuteczne? Kilka lat temu moje małe badanie pokazało, że nie jest idealne. Przyjrzyjmy się aktualnej sytuacji.
Aby zebrać informacje, załatałem w celu zachowania wartości TTL dla odpowiedzi. Określa się ją jako minimalne TTL jego rekordów dla każdego nadchodzącego zapytania. Daje to dobry przegląd rozkładu TTL rzeczywistego ruchu, a także uwzględnia popularność poszczególnych zapytań. Załatana wersja serwera działała przez kilka godzin.
Ostateczny zestaw danych składa się z 1 583 579 rekordów (name, qtype, TTL, timestamp). Oto ogólny rozkład TTL (oś X to TTL w sekundach):
Oprócz niewielkiego wzgórza na poziomie 86 400 (głównie dla rekordów SOA), dość oczywiste jest, że TTL znajduje się w niskim zakresie. Przyjrzyjmy się dokładniej:
Dobrze, TTL powyżej 1 godziny nie jest statystycznie istotne. Skupmy się więc na zakresie 0-3600:
Większość TTL od 0 do 15 minut:
Zdecydowana większość od 0 do 5 minut:
To nie jest zbyt dobrze.
Kumulacyjny rozkład jeszcze bardziej uwidacznia problem:
W połowie odpowiedzi DNS TTL wynosi 1 minutę lub mniej, a w trzech czwartych — 5 minut lub mniej.
Ale poczekaj, w rzeczywistości jest jeszcze gorzej. To TTL od serwerów autorytatywnych. Jednak resolverzy klienccy (np. routery, lokalne bufory) otrzymują TTL od wyższych resolverów, co zmniejsza się co sekundę.
W ten sposób klient w rzeczywistości może korzystać z każdego rekordu średnio przez połowę oryginalnego TTL, po czym składa nowe zapytanie.
Może te bardzo niskie TTL dotyczą tylko nietypowych zapytań, a nie popularnych stron internetowych i API? Przyjrzyjmy się:
Oś X to TTL, oś Y to popularność zapytań.
Niestety, najpopularniejsze zapytania są również najgorzej buforowane.
Przybliżmy:
Werdykt: rzeczywiście jest źle. Już wcześniej było źle, a teraz jest jeszcze gorzej. Kaflowanie DNS stało się praktycznie bezużyteczne. Ponieważ coraz mniej osób korzysta z resolvera DNS swojego dostawcy (z uzasadnionych powodów), opóźnienia stały się bardziej zauważalne.
Kaflowanie DNS stało się przydatne tylko dla treści, do których nikt nie zagląda.
Zauważ również, że oprogramowanie może niski TTL.
Dlaczego tak?
Dlaczego dla rekordów DNS ustalany jest tak mały TTL?
- Przestarzałe load balancery pozostały z ustawieniami domyślnymi.
- W kręgach krążą mity, że równoważenie obciążenia na poziomie DNS zależy od TTL (to nieprawda – od czasów Netscape Navigator klienci losowo wybierają adres IP z zestawu RR i próbuja innego, jeśli nie mogą się połączyć)
- Administratorzy chcą stosować zmiany natychmiastowo, ponieważ tak łatwiej jest planować.
- Administrator serwera DNS lub load balancera widzi swoją rolę w skutecznym wdrażaniu konfiguracji, której żądają użytkownicy, a nie w przyspieszaniu działania stron i usług.
- Niskie TTL dają spokój ducha.
- Ludzie początkowo ustalają niskie TTL w celu testowania i zapominają je później zmienić.
Nie włączyłem w listę «odporności na awarie», ponieważ staje się to coraz mniej aktualne. Jeśli trzeba przekierować użytkowników do innej sieci tylko w celu wyświetlenia strony z błędem, gdy wszystko inne zawiodło, to opóźnienie większe niż 1 minuta jest zapewne dopuszczalne.
Ponadto, minutowy TTL oznacza, że jeśli autorytatywne serwery DNS będą zablokowane przez więcej niż 1 minutę, nikt inny nie będzie mógł uzyskać dostępu do zależnych usług. I redundancja nie pomoże, jeśli przyczyną jest błąd konfiguracji lub włamanie. Z drugiej strony, przy rozsądnych TTL wielu klientów będzie kontynuować korzystanie z poprzedniej konfiguracji i nigdy niczego nie zauważą.
W niskich TTL w dużej mierze są winne usługi CDN i load balancery, szczególnie gdy łączą CNAME z małymi TTL i rekordy z równie małymi (ale niezależnymi) 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
Za każdym razem, gdy wygasa CNAME lub jeden z rekordów A, trzeba wysłać nowe zapytanie. Oba mają 30-sekundowy TTL, ale nie są zgodne. Rzeczywisty średni TTL będzie wynosił 15 sekund.
Ale chwileczkę! Jest jeszcze gorzej. Niektóre resolver'y zachowują się bardzo źle w takiej sytuacji z dwoma połączonymi niskimi TTL:
$ 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 prawdopodobnie działa na BIND. Jeśli będziesz nadal wysyłać to zapytanie, zawsze zostanie zwrócony TTL równy 1. W zasadzie, raw.githubusercontent.com nigdy nie jest buforowany.
Oto kolejny przykład takiej sytuacji z bardzo popularną domeną:
$ 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
Nie mniej niż trzy rekordy CNAME. Ojej. Jeden ma przyzwoity TTL, ale to zupełnie bezużyteczne. W pozostałych CNAME pierwotny TTL wynosi 60 sekund, ale dla domen akamai.net maksymalny TTL wynosi 20 sekund, a żaden z nich nie jest zsynchronizowany.
A co z domenami, które ciągle sprawdzają urządzenia 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
Ten sam problem, co w Firefoksie, a TTL przez większość czasu utknie na 1 sekundzie przy użyciu resolver'a 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
W rekordzie safebrowsing.googleapis.com wartość TTL wynosi 60 sekund, jak w przypadku domen Facebooka. I znowu, z perspektywy klienta, te wartości są zmniejszane o połowę.
A co z ustawieniem minimalnego TTL?
Używając nazwy, rodzaju zapytania, TTL oraz początkowo zapisanej znacznika czasowej, napisałem skrypt do symulacji 1,5 miliona zapytań przechodzących przez buforujący resolver, aby ocenić ilość niepotrzebnych zapytań wysyłanych z powodu przestarzałej lokalizacji bufora.
47,4% zapytań zostało dokonanych po wygaśnięciu istniejącego rekordu. To nieuzasadnione wysokie.
Jakie będą konsekwencje dla buforowania, jeśli ustalony zostanie minimalny TTL?
Oś X to minimalne wartości TTL. Rekordy z początkowym TTL wyższym niż ta wartość nie są dotknięte.
Oś Y to procent zapytań od klienta, który ma już zbuforowany rekord, ale jego okres ważności wygasł i wysyła nowe zapytanie.
Procent 'zbędnych' zapytań spada z 47% do 36% przy prostej instalacji minimalnego TTL wynoszącego 5 minut. Ustalając minimalny TTL na 15 minut, liczba tych zapytań spada do 29%. Minimalny TTL wynoszący 1 godzinę zmniejsza je do 17%. Znacząca różnica!
Co powiesz na to, aby nie zmieniać nic na serwerze, a zamiast tego ustawić minimalne TTL w klienckich pamięciach DNS (routery, lokalne resolverzy)?
Liczba wymaganych zapytań zmniejsza się z 47% do 34% przy minimalnym TTL wynoszącym 5 minut, do 25% przy minimum 15 minut i do 13% przy minimum 1 godziny. Możliwe, że optymalna wartość to 40 minut.
Wpływ tej minimalnej zmiany jest ogromny.
Jakie są konsekwencje?
Oczywiście, można przenieść usługę do nowego dostawcy chmurowego, na nowy serwer, nową sieć, wymuszając na klientach użycie najnowszych rekordów DNS. A wystarczająco niski TTL pomaga przeprowadzić tę zmianę płynnie i niewidocznie. Ale przechodząc na nową infrastrukturę, nikt nie oczekuje, że klienci przejdą na nowe rekordy DNS w ciągu 1, 5 lub 15 minut. Ustawienie minimalnego czasu życia na 40 minut zamiast 5 minut nie przeszkodzi użytkownikom w dostępie do usługi.
Jednak pozwoli to znacznie skrócić opóźnienia i zwiększyć prywatność oraz niezawodność, unikając zbędnych zapytań.
Oczywiście, RFC mówi, że należy ściśle przestrzegać TTL. Ale rzeczywistość jest taka, że system DNS stał się zbyt nieefektywny.
Jeśli pracujesz z autorytatywnymi serwerami DNS, sprawdź swoje TTL. Czy naprawdę potrzebujesz takich absurdalnie niskich wartości?
Oczywiście, istnieją ważne powody ustalania małych TTL dla rekordów DNS. Ale nie dla 75% ruchu DNS, który praktycznie się nie zmienia.
I jeśli z jakiegoś powodu naprawdę musisz stosować niskie TTL dla DNS, upewnij się, że na twojej stronie nie włączono buforowania. Z tych samych powodów.
Jeśli masz działającą lokalną pamięć podręczną DNS, taką jak , który pozwala ustawić minimalne TTL, korzystaj z tej funkcji. To w porządku. Nic złego się nie wydarzy. Ustaw minimalne TTL na około 40 minut (2400 sekund) do 1 godziny. Całkiem rozsądny zakres.
Źródło: habr.com
