Niskie opóźnienie DNS jest kluczem do szybkiego przeglądania Internetu. Aby go zminimalizować, ważne jest, aby dokładnie wybrać serwery DNS i . Ale pierwszym krokiem jest pozbycie się bezużytecznych zapytań.
Właśnie dlatego DNS został pierwotnie zaprojektowany jako protokół o dużej możliwości buforowania. Administratorzy stref ustawiają czas życia (TTL) dla poszczególnych wpisów, a programy rozpoznawania nazw korzystają z tej informacji podczas przechowywania wpisów w pamięci, aby uniknąć niepotrzebnego ruchu.
Czy buforowanie jest skuteczne? Kilka lat temu moje małe badania wykazały, że nie jest doskonały. Przyjrzyjmy się obecnemu stanowi rzeczy.
Aby zebrać informacje, załatałem aby zapisać wartość TTL dla odpowiedzi. Jest zdefiniowany jako minimalny TTL jego rekordów dla każdego przychodzącego żądania. Daje to dobry przegląd rozkładu TTL rzeczywistego ruchu, a także uwzględnia popularność poszczególnych żądań. Poprawiona wersja serwera działała kilka godzin.
Wynikowy zestaw danych składa się z 1 583 579 rekordów (nazwa, typ q, TTL, znacznik czasu). Oto ogólny rozkład TTL (oś X to TTL w sekundach):
Oprócz niewielkiego wzrostu przy 86 (głównie dla rekordów SOA), jest całkiem jasne, że TTL są w niskim zakresie. Przyjrzyjmy się bliżej:
OK, TTL większe niż 1 godzina nie są istotne statystycznie. Następnie skupmy się na zakresie 0-3600:
Większość TTL wynosi od 0 do 15 minut:
Zdecydowana większość to czas od 0 do 5 minut:
To nie jest zbyt dobre.
Dystrybucja skumulowana sprawia, że problem jest jeszcze bardziej oczywisty:
Połowa odpowiedzi DNS ma TTL wynoszący 1 minutę lub mniej, a trzy czwarte ma TTL wynoszący 5 minut lub mniej.
Ale czekaj, w rzeczywistości jest gorzej. W końcu jest to TTL z autorytatywnych serwerów. Jednakże klienckie programy tłumaczące (np. routery, lokalne pamięci podręczne) otrzymują wartość TTL od nadrzędnych programów tłumaczących i zmniejsza się ona z każdą sekundą.
Zatem klient może faktycznie wykorzystać każdy wpis średnio o połowę pierwotnego TTL przed wysłaniem nowego żądania.
Być może te bardzo niskie TTL dotyczą tylko nietypowych żądań, a nie popularnych witryn i interfejsów API? Przyjrzyjmy się:
Oś X to TTL, oś Y to popularność zapytań.
Niestety, najpopularniejsze zapytania są również najgorsze do buforowania.
Powiększmy:
Werdykt: jest naprawdę źle. Już wcześniej było źle, ale stało się jeszcze gorzej. Buforowanie DNS stało się praktycznie bezużyteczne. Ponieważ mniej osób korzysta z narzędzia do rozpoznawania nazw DNS swojego dostawcy usług internetowych (z dobrych powodów), wzrost opóźnienia staje się bardziej zauważalny.
Buforowanie DNS stało się przydatne tylko w przypadku treści, których nikt nie odwiedza.
Należy również pamiętać, że oprogramowanie może interpretować niskie wartości TTL.
Dlaczego tak jest?
Dlaczego rekordy DNS są ustawione na tak niski TTL?
- Starsze moduły równoważenia obciążenia pozostawiono z ustawieniami domyślnymi.
- Krążą mity, że równoważenie obciążenia DNS zależy od TTL (nie jest to prawdą – od czasów Netscape Navigator klienci wybierali losowy adres IP z zestawu RR i w przejrzysty sposób próbowali innego, jeśli nie mogli się połączyć)
- Administratorzy chcą natychmiast zastosować zmiany, więc łatwiej jest planować.
- Administrator serwera DNS lub modułu równoważenia obciążenia postrzega swoje zadanie jako efektywne wdrażanie konfiguracji żądanej przez użytkowników, a nie przyspieszanie witryn i usług.
- Niskie TTL zapewniają spokój ducha.
- Ludzie początkowo ustawiają niskie TTL do testów, a potem zapominają je zmienić.
Nie umieściłem na liście „przełączenia awaryjnego”, ponieważ staje się ono coraz mniej istotne. Jeśli chcesz przekierować użytkowników do innej sieci, aby wyświetlić stronę błędu, gdy absolutnie wszystko inne jest zepsute, prawdopodobnie dopuszczalne jest opóźnienie większe niż 1 minuta.
Dodatkowo jednominutowy 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 nadmiarowość 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 korzystać z poprzedniej konfiguracji i nigdy niczego nie zauważy.
Usługi CDN i moduły równoważenia obciążenia są w dużej mierze odpowiedzialne za niskie TTL, zwłaszcza gdy łączą CNAME z niskimi TTL i rekordy z równie niskimi (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 CNAME lub którykolwiek z rekordów A wygaśnie, należy wysłać nowe żądanie. Oba mają 30-sekundowy TTL, ale to nie to samo. Rzeczywisty średni TTL wyniesie 15 sekund.
Ale poczekaj! Jest jeszcze gorzej. Niektóre resolwery zachowują się bardzo źle w tej sytuacji z dwoma powiązanymi niskimi wartościami TTL:
$ ćwicz raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 W CNAME github.map.fastly.net. github.map.fastly.net. 1 W 151.101.16.133
Program rozpoznawania nazw poziomu 3 prawdopodobnie działa na BIND. Jeśli będziesz nadal wysyłać to żądanie, zawsze zostanie zwrócony TTL równy 1. Zasadniczo, 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
Co najmniej trzy rekordy CNAME. Aj. Jeden ma przyzwoity TTL, ale jest zupełnie bezużyteczny. Inne rekordy CNAME mają początkowy TTL wynoszący 60 sekund, ale w przypadku domen akamai.net maksymalny TTL wynosi 20 sekund i żaden z nich nie jest w fazie.
A co z domenami, które stale odpytują 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 przypadku przeglądarki Firefox i TTL, przez większość czasu przy korzystaniu z narzędzia do rozwiązywania problemów poziomu 1 zatrzymuje się na 3 sekundę.
Dropbox?
$ drążenie klient.dropbox.com @8.8.8.8 klient.dropbox.com. 7 W CNAME klient.dropbox-dns.com. klient.dropbox-dns.com. 59 W wiertarce 162.125.67.3 $ klient.dropbox.com @ 4.2.2.2 klient.dropbox.com. 1 W CNAME klient.dropbox-dns.com. klient.dropbox-dns.com. 1 W 162.125.64.3
Na nagraniu safebrowsing.googleapis.com Wartość TTL wynosi 60 sekund, podobnie jak domeny Facebooka. I znowu, z punktu widzenia klienta, wartości te zmniejszają się o połowę.
A co powiesz na ustawienie minimalnego TTL?
Używając nazwy, typu żądania, czasu TTL i oryginalnie zapisanego znacznika czasu, napisałem skrypt symulujący 1,5 miliona żądań przechodzących przez moduł rozpoznawania pamięci podręcznej w celu oszacowania liczby niepotrzebnych żą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 nieracjonalnie wysokie.
Jaki wpływ na buforowanie będzie miało ustawienie minimalnego TTL?
Oś X to minimalne wartości TTL. Nie ma to wpływu na nagrania ze źródłowym TTL powyżej tej wartości.
Oś Y to procent żądań od klienta, który ma już wpis w pamięci podręcznej, ale jego ważność wygasła i wysyła nowe żądanie.
Udział „dodatkowych” żądań zmniejsza się z 47% do 36% poprzez proste ustawienie minimalnego TTL na 5 minut. Ustawiając minimalny TTL na 15 minut, liczba tych żądań spada do 29%. Minimalny czas TTL wynoszący 1 godzinę zmniejsza je do 17%. Znacząca różnica!
A może nie zmieniać niczego po stronie serwera, ale zamiast tego ustawić minimalną wartość TTL w pamięciach podręcznych DNS klientów (routery, lokalne programy tłumaczące)?
Liczba wymaganych żądań spada z 47% do 34% przy minimalnym TTL wynoszącym 5 minut, do 25% przy minimum 15 minut i do 13% przy minimum 1 godzinie. Być może optymalne będzie 40 minut.
Wpływ tej małej 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 dość mały TTL pomaga dokonać takiego przejścia płynnie i niezauważalnie. Jednak po przejściu na nową infrastrukturę nikt nie oczekuje, że klienci przeprowadzą migrację do nowych rekordów DNS w ciągu 1 minuty, 5 minut czy 15 minut. Ustawienie minimalnego TTL na 40 minut zamiast 5 minut nie uniemożliwi użytkownikom dostępu do usługi.
Jednak znacznie zmniejszy to opóźnienia oraz poprawi prywatność i niezawodność poprzez uniknięcie niepotrzebnych żądań.
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 współpracujesz z autorytatywnymi serwerami DNS, sprawdź swoje TTL. Czy naprawdę potrzebujesz tak śmiesznie niskich wartości?
Oczywiście istnieją dobre powody, aby ustawić małe wartości TTL dla rekordów DNS. Ale nie dla 75% ruchu DNS, który pozostaje praktycznie niezmieniony.
A jeśli z jakiegoś powodu naprawdę musisz używać niskich TTL dla DNS, jednocześnie upewnij się, że Twoja witryna nie ma włączonego buforowania. Z tych samych powodów.
Jeśli masz uruchomioną lokalną pamięć podręczną DNS, np która umożliwia ustawienie minimalnych wartości TTL, użyj tej funkcji. Jest okej. Nic złego się nie stanie. Ustaw minimalny TTL na około 40 minut (2400 sekund) i 1 godzinę. Całkiem rozsądny zakres.
Źródło: www.habr.com