Niskie opóźnienie DNS jest kluczem do szybkiego przeglądania stron internetowych. Aby zminimalizować ryzyko, należy starannie dobrać serwery DNS i . Ale pierwszą rzeczą, którą musisz zrobić, jest pozbycie się niepotrzebnych zapytań.
Dlatego też DNS został pierwotnie zaprojektowany jako protokół o dużej możliwości buforowania. Administratorzy stref ustawiają czas życia (TTL) dla poszczególnych rekordów, a moduły rozpoznawania nazw korzystają z tej informacji podczas przechowywania rekordów w pamięci, aby uniknąć niepotrzebnego ruchu.
Czy buforowanie jest skuteczne? Kilka lat temu moje małe badania wykazały, że nie jest to system idealny. Przyjrzyjmy się obecnemu stanowi rzeczy.
Aby zebrać informacje, które załatałem aby zapisać wartość TTL dla odpowiedzi. Jest ona definiowana jako minimalny czas życia (TTL) rekordów dla każdego przychodzącego żądania. Daje to dobry przegląd rozkładu TTL rzeczywistego ruchu i uwzględnia popularność poszczególnych zapytań. Poprawiona wersja serwera działała przez kilka godzin.
Powstały zestaw danych składa się z 1 583 579 rekordów (nazwa, typ kodu, czas życia, znacznik czasu). Oto ogólny rozkład TTL (oś x oznacza TTL w sekundach):
Poza niewielkim wzrostem do 86 400 (głównie dla rekordów SOA), dość oczywiste jest, że wartości TTL są niskie. Przyjrzyjmy się temu bliżej:
OK, TTL powyżej 1 godziny nie jest statystycznie istotne. Skupmy się teraz na zakresie 0-3600:
Większość TTL mieści się w przedziale od 0 do 15 minut:
Zdecydowana większość trwa od 0 do 5 minut:
To nie jest zbyt dobre.
Problem ten staje się jeszcze bardziej oczywisty, gdy weźmiemy pod uwagę dystrybucję kumulatywną:
Połowa odpowiedzi DNS ma czas TTL wynoszący 1 minutę lub mniej, a trzy czwarte ma czas TTL wynoszący 5 minut lub mniej.
Ale czekaj, jest jeszcze gorzej. W końcu jest to TTL z autorytatywnych serwerów. Jednakże resolvery klienckie (np. routery, lokalne pamięci podręczne) otrzymują wartość TTL od resolverów nadrzędnych i zmniejsza się ona co sekundę.
Dzięki temu klient może faktycznie wykorzystywać każdy rekord średnio przez połowę pierwotnego czasu życia (TTL) przed wysłaniem nowego żądania.
Być może te bardzo niskie wartości TTL dotyczą tylko nietypowych żądań, a nie popularnych stron internetowych i interfejsów API? Przyjrzyjmy się temu:
Oś X przedstawia TTL, oś Y przedstawia popularność zapytań.
Niestety, najpopularniejsze zapytania są również najgorzej zapisywane w pamięci podręcznej.
Przyjrzyjmy się bliżej:
Werdykt: Jest naprawdę źle. Już wcześniej było źle, ale teraz jest jeszcze gorzej. Buforowanie DNS stało się praktycznie bezużyteczne. Ponieważ coraz mniej osób korzysta z usługi rozpoznawania nazw domen (DNS) oferowanej przez dostawcę usług internetowych (i słusznie), wzrost opóźnień staje się coraz bardziej zauważalny.
Buforowanie DNS stało się przydatne jedynie w przypadku treści, których nikt nie odwiedza.
Należy również pamiętać, że oprogramowanie może interpretować niskie TTL.
Dlaczego tak jest?
Dlaczego rekordy DNS mają ustawiony tak niski TTL?
- Starsze moduły równoważenia obciążenia pozostają przy ustawieniach domyślnych.
- Istnieją mity, że równoważenie obciążenia DNS zależy od TTL (to nieprawda - od czasu Netscape Navigator klienci wybierają losowy adres IP z zestawu RR i w sposób transparentny próbują innego, jeśli nie mogą się połączyć)
- Administratorzy chcą wprowadzać zmiany natychmiast, aby łatwiej było je planować.
- Administrator serwera DNS lub modułu równoważenia obciążenia uważa, że jego zadaniem jest sprawne wdrażanie konfiguracji żądanej przez użytkowników, a nie przyspieszanie działania witryn i usług.
- Niskie TTL daje spokój ducha.
- Ludzie początkowo ustawiają niskie wartości TTL na potrzeby testów, a potem zapominają je zmienić.
Nie uwzględniłem „przełączenia awaryjnego” na liście, ponieważ staje się to coraz mniej istotne. Jeśli musisz przekierować użytkowników do innej sieci tylko po to, aby wyświetlić stronę błędu, gdy absolutnie wszystko inne nie działa, opóźnienie dłuższe niż 1 minuta jest prawdopodobnie akceptowalne.
Ponadto jednominutowy czas TTL oznacza, że jeśli autorytatywne serwery DNS zostaną zablokowane na dłużej niż 1 minutę, nikt inny nie będzie mógł uzyskać dostępu do zależnych usług. A redundancja nie pomoże, jeśli przyczyną jest błąd konfiguracji lub włamanie. Z drugiej strony, przy rozsądnych wartościach TTL, wielu klientów będzie nadal używać poprzedniej konfiguracji i niczego nie zauważy.
Niskie wartości TTL są w dużej mierze winą usług CDN i modułów równoważenia obciążenia, zwłaszcza gdy łączą one rekordy CNAME o niskich wartościach TTL i rekordy o równie niskich (ale niezależnych) wartościach 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 rekord CNAME lub którykolwiek z rekordów A wygaśnie, należy wysłać nowe żądanie. Oba mają 30-sekundowy czas TTL, ale to nie to samo. Rzeczywisty średni czas TTL wyniesie 15 sekund.
Ale czekaj! Jest jeszcze gorzej. Niektóre resolvery zachowują się bardzo źle w tej sytuacji, gdy mają dwa połączone niskie wartości TTL:
$ drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 W CNAME github.map.fastly.net. Mapa jest dostępna na stronie github.map.fastly.net. 1 W 151.101.16.133
Resolwer Level3 prawdopodobnie działa na BIND. Jeśli będziesz nadal wysyłać to żądanie, zawsze zwróci ono wartość TTL równą 1. Zasadniczo raw.githubusercontent.com nigdy nie buforowane.
Oto kolejny przykład takiej sytuacji w przypadku bardzo popularnej domeny:
$ 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
Co najmniej trzy rekordy CNAME. Tak. Jeden ma przyzwoity TTL, ale jest zupełnie bezużyteczny. W przypadku innych rekordów CNAME początkowy czas TTL wynosi 60 sekund, ale w przypadku domen akamai.net Maksymalny czas TTL wynosi 20 sekund, a żadne z nich nie jest w fazie.
A co z domenami, które stale monitorują 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 występuje w przeglądarce Firefox. W większości przypadków TTL zatrzymuje się na 1 sekundzie podczas korzystania z resolvera Level3.
Dropbox?
$ drill klient.dropbox.com @8.8.8.8 klient.dropbox.com. 7 W rekordzie CNAME client.dropbox-dns.com. klient.dropbox-dns.com. 59 W 162.125.67.3 $ drill klient.dropbox.com @4.2.2.2 klient.dropbox.com. 1 W CNAME client.dropbox-dns.com. klient.dropbox-dns.com. 1 W 162.125.64.3
Podczas nagrywania safebrowsing.googleapis.com Wartość TTL wynosi 60 sekund, tak samo jak w przypadku domen Facebooka. I znów, z punktu widzenia klienta, wartości te są mniejsze o połowę.
Co powiesz na ustawienie minimalnego TTL?
Korzystając z nazwy, typu żądania, czasu życia (TTL) i pierwotnie zapisanego znacznika czasu, napisałem skrypt symulujący 1,5 miliona żądań przechodzących przez moduł rozpoznawania nazw w pamięci podręcznej, aby oszacować liczbę dodatkowych żądań wysłanych z powodu wygasłego wpisu w pamięci podręcznej.
47,4% wniosków złożono po wygaśnięciu istniejącego rekordu. To jest bezsensownie wysoka cena.
Jaki wpływ na buforowanie będzie miało ustawienie minimalnego TTL?
Oś X przedstawia minimalne wartości TTL. Rekordy z oryginalnym TTL powyżej tej wartości nie są objęte zmianą.
Oś Y przedstawia procent żądań od klienta, który ma już wpis w pamięci podręcznej, ale wygasł i wysyła nowe żądanie.
Udział „dodatkowych” żądań można zmniejszyć z 47% do 36%, po prostu ustawiając minimalny czas TTL na 5 minut. Ustawiając minimalny czas TTL na poziomie 15 minut, liczba takich żądań spada do 29%. Minimalny czas TTL wynoszący 1 godzinę zmniejsza je do 17%. Istotna różnica!
Co powiesz na to, żeby nie zmieniać niczego po stronie serwera, ale zamiast tego ustawić minimalne wartości TTL w pamięci podręcznej DNS klienta (routery, lokalne resolvery)?
Liczba wymaganych żądań ulega zmniejszeniu z 47% do 34% przy ustawieniu minimalnego czasu TTL na poziomie 5 minut, do 25% przy ustawieniu minimum 15 minut i do 13% przy ustawieniu minimum 1 godziny. Być może optymalną wartością jest 40 minut.
Wpływ tej minimalnej zmiany jest ogromny.
Jakie są konsekwencje?
Oczywiście, usługę można przenieść do nowego dostawcy chmury, nowego serwera, nowej sieci, wymagając od klientów korzystania z najnowszych rekordów DNS. A stosunkowo mały TTL sprawia, że takie przejście odbywa się płynnie i niezauważalnie. Jednak nikt nie oczekuje, że klienci będą w stanie przeprowadzić migrację do nowych rekordów DNS w ciągu 1 minuty, 5 minut czy 15 minut w związku z przejściem na nową infrastrukturę. Ustawienie minimalnego czasu trwania na 40 minut zamiast 5 minut nie uniemożliwi użytkownikom dostępu do usługi.
Jednakże znacznie zmniejszy to opóźnienia oraz poprawi prywatność i niezawodność dzięki wyeliminowaniu niepotrzebnych żądań.
Oczywiście RFC stanowią, że TTL musi być ściśle przestrzegane. Ale rzeczywistość jest taka, że system DNS stał się zbyt nieefektywny.
Jeśli korzystasz z autorytatywnych serwerów DNS, sprawdź swoje wartości TTL. Czy naprawdę potrzebujesz tak śmiesznie niskich wartości?
Oczywiście istnieją dobre powody, dla których warto ustawiać niskie wartości TTL dla rekordów DNS. Jednak nie dotyczy to 75% ruchu DNS, który pozostaje praktycznie niezmieniony.
A jeśli z jakiegoś powodu musisz użyć niskiego TTL dla DNS, upewnij się także, że w Twojej witrynie wyłączone jest buforowanie. Z tych samych powodów.
Jeśli masz uruchomioną lokalną pamięć podręczną DNS, taką jak , która umożliwia ustawienie minimalnego TTL, użyj tej funkcji. To w porządku. Nic złego się nie stanie. Ustaw minimalny czas TTL na około 40 minut (2400 sekund) i 1 godzinę. Całkiem rozsądny zakres.
Źródło: www.habr.com
