opóźnienie systemu nazw domen (DNS) jest kluczowym elementem dobrego doświadczenia online. Aby zminimalizować opóźnienia DNS, ważną rolę odgrywa starannie dobrane serwery DNS i przekaźniki anonimizacji.
ale najlepszym sposobem na zminimalizowanie opóźnień jest uniknięcie wysyłania bezużytecznych zapytań na początek. Dlatego DNS został zaprojektowany, od pierwszego dnia, jako protokół, który można buforować. Poszczególne rekordy mają czas życia (TTL), pierwotnie ustalony przez administratorów stref, a resolvery wykorzystują te informacje do przechowywania tych rekordów w pamięci, aby uniknąć niepotrzebnego ruchu.
czy buforowanie jest efektywne? Szybkie badanie, które przeprowadziłem kilka lat temu, wykazało, że jest miejsce na poprawę. Dzisiaj chcę spojrzeć na nowy stan rzeczy.
aby to zrobić, poprawiłem zaszyfrowany serwer DNS, aby przechowywać oryginalny TTL odpowiedzi, zdefiniowany jako minimalny TTL jej rekordów, dla każdego przychodzącego zapytania. Daje nam to dobry przegląd dystrybucji TTL ruchu w świecie rzeczywistym, ale również stanowi o popularności poszczególnych zapytań.
ta poprawiona wersja została uruchomiona przez kilka godzin. Powstały zestaw danych składa się z 1 583 579 krotek (nazwa, qtype, TTL, znacznik czasu). Oto ogólny rozkład TTL (oś X jest TTL w sekundach):
poza znikomym skokiem na poziomie 86,400 (głównie dla rekordów SOA), jest dość oczywiste, że TTL są w niskim zakresie. Przybliżmy:
dobrze, TTL powyżej 1 godziny są statystycznie nieistotne. Skupmy się na zakresie 0-3,600:
i gdzie większość TTL znajduje się między 0 a 15 minutami:
zdecydowana większość trwa od 0 do 5 minut:
to nie jest świetne. Rozkład skumulowany może jeszcze bardziej oczywista kwestia:
połowa Internetu ma 1-minutowy TTL lub mniej, a trzy czwarte ma 5-minutowy TTL lub mniej.
ale czekaj, to jest rzeczywiście gorsze. Są to TTL zdefiniowane przez autorytatywne serwery. Jednak TTL pobrane z resolverów klienckich (na przykład routery, lokalne pamięci podręczne) otrzymują TTL, który upstream resolvers maleje co sekundę. Tak więc, średnio rzeczywisty czas, w którym Klient może użyć buforowanego wpisu przed wymaganiem nowego zapytania, wynosi połowę oryginalnego TTL.
może te bardzo niskie TTL wpływają tylko na rzadkie zapytania, a nie Popularne strony internetowe i API. Przyjrzyjmy się:
Niestety najpopularniejsze zapytania są również najbardziej bezsensowne do cache ’ u. Przybliżmy:
werdykt: jest naprawdę źle, a raczej już było źle i jest coraz gorzej. Buforowanie DNS stało się prawie bezużyteczne. Przy mniejszej liczbie osób używających resolvera DNS swojego dostawcy usług internetowych (z dobrych powodów), zwiększone opóźnienie staje się bardziej zauważalne. Buforowanie DNS stało się przydatne tylko dla treści, których nikt nie odwiedza. Należy również zauważyć, że oprogramowanie może interpretować niskie TTL inaczej.
dlaczego?
Dlaczego rekordy DNS są ustawiane z tak niskim TTL?
- starsze load balancers są pozostawione z ustawieniami domyślnymi.
- miejska legenda, że równoważenie obciążenia oparte na DNS zależy od TTLs(nie).
- Administratorzy chcą, aby ich zmiany zostały wprowadzone natychmiast, ponieważ może to wymagać mniej pracy planowania.
- jako administrator DNS lub load-balancer Twoim obowiązkiem jest sprawne wdrażanie konfiguracji, o którą proszą ludzie, a nie szybkie tworzenie stron internetowych i usług.
- niskie TTL dają spokój ducha.
nie umieszczam na tej liście 'do przełączania awaryjnego’, ponieważ stało się to coraz mniej istotne. Jeśli intencją jest przekierowanie użytkowników do innej sieci tylko po to, aby wyświetlić stronę fail whale, gdy Wszystko inne jest w ogniu, prawdopodobnie dopuszczalne jest opóźnienie o więcej niż jedną minutę.
CDN I load-balancers są w dużej mierze winne, zwłaszcza gdy łączą rekordy CNAME z krótkimi TTL z rekordami również mającymi krótkie (ale niezależne) TTL:
$ 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
nowe zapytanie musi zostać wysłane za każdym razem, gdy CNAME lub którykolwiek z rekordów A wygaśnie. Oba mają 30-sekundowy TTL, ale nie są w fazie. Rzeczywista średnia TTL będzie 15 sekund.
ale czekaj! Jest gorzej. Niektóre resolvery zachowują się bardzo źle w sytuacji 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
jest to resolver Level3, który, jak sądzę, działa w BIND. Jeśli nadal wysyłasz to zapytanie, zwracany TTL będzie zawsze równy 1. Zasadniczo, raw.githubusercontent.com nigdy nie będzie buforowany.
oto kolejny przykład sytuacji low-TTL-CNAME+low-TTL-records, z bardzo popularną nazwą:
$ 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
nie mniej niż trzy rekordy CNAME. AUĆ. Jeden z nich ma przyzwoity TTL, ale jest całkowicie bezużyteczny. Inne CNAMEs mają oryginalny TTL 60 sekund; the akamai.net nazwy mają maksymalnie TTL 20 sekund i nic z tego nie jest w fazie.
a co powiesz na taki, który twoje urządzenia Apple stale sondują?
$ 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
ta sama konfiguracja co Firefox i TTL jest przyklejony do 1 przez większość czasu podczas używania resolvera Level3.
a co z Dropboxem?
safebrowsing.googleapis.com ma TTL 60 sekund. Nazwy Facebooka mają 60-sekundowy TTL. I jeszcze raz, z punktu widzenia klienta, wartości te powinny zostać zmniejszone o połowę.
co powiesz na ustawienie minimalnego TTL?
korzystając z nazwy, typu zapytania, TTL i znacznika czasu początkowo zapisanego, napisałem skrypt, który symuluje ponad 1,5 miliona zapytań przechodzących przez resolver buforowania, aby oszacować, ile zapytań zostało wysłanych z powodu wygasłego wpisu pamięci podręcznej. 47.4% zapytań zostało wykonanych po wygaśnięciu istniejącego, buforowanego wpisu. Jest to nieracjonalnie wysokie.
Jaki byłby wpływ na buforowanie, gdyby ustawiono minimalny TTL?
oś X jest minimalnym ustawionym TTL. Rekordy, których pierwotny TTL był wyższy niż ta wartość, nie uległy zmianie. Oś Y to procent zapytań wykonanych przez Klienta, który miał już wpis w pamięci podręcznej, ale zostało wykonane nowe zapytanie i wpis w pamięci podręcznej wygasł.
liczba zapytań spada z 47% do 36% po prostu ustawiając minimum TTL na 5 minut. Ustawienie minimalnego TTL wynoszącego 15 minut powoduje spadek liczby wymaganych zapytań do 29%. Minimalny TTL wynoszący 1 godzinę sprawia, że spada do 17%. To znacząca różnica!
Co powiesz na to, aby nie zmieniać niczego po stronie serwera, ale aby bufory DNS klienta (routery, lokalne resolvery i bufory…) ustawiały minimalny TTL?
liczba wymaganych zapytań spada z 47% do 34%, ustawiając minimum TTL na 5 minut, do 25% z minimum 15-minutowym i do 13% z minimum 1-godzinnym. 40 minut, może słodkie miejsce. Wpływ tej minimalnej zmiany jest ogromny.
jakie są konsekwencje?
oczywiście usługa może przełączyć się na nowego dostawcę chmury, nowy serwer, nową sieć, wymagając od klientów korzystania z aktualnych rekordów DNS. A rozsądnie niski TTL pomaga w przejściu bez tarcia. Jednak nikt, przechodząc do nowej infrastruktury, nie będzie oczekiwać, że klienci będą korzystać z nowych rekordów DNS w ciągu 1 minuty, 5 minut lub 15 minut.
ustawienie minimum TTL 40 minut zamiast 5 minut nie uniemożliwi użytkownikom dostępu do usługi. Jednak drastycznie zmniejszy opóźnienia i poprawi prywatność (więcej zapytań = więcej możliwości śledzenia) i niezawodność, unikając niepotrzebnych zapytań.
oczywiście RFC twierdzą, że TTL powinny być ściśle przestrzegane. Ale rzeczywistość jest taka, że DNS stał się nieefektywny.
Jeśli korzystasz z autorytatywnych serwerów DNS, odwiedź ponownie swoje TTLs. Naprawdę chcesz, żeby były śmiesznie niskie?
Czytaj: jak wybrać wartości TTL DNS
oczywiście, istnieją ważne powody, aby używać niskich TTL DNS. Ale nie dla 75% Internetu do serwowania treści, które są w większości niezmienne, ale bezcelowe do buforowania. A jeśli, z jakichkolwiek powodów, naprawdę potrzebujesz użyć TTL o niskim DNS, upewnij się również, że pamięć podręczna nie działa na twojej stronie. Z tych samych powodów.
Jeśli używasz lokalnej pamięci podręcznej DNS, takiej jak dnscrypt-proxy, która pozwala na ustawienie minimalnych TTL, użyj tej funkcji. W porządku. Nic złego się nie stanie. Ustaw ten minimalny TTL na coś między 40 minutami (2400 sekund) a 1 godziną; jest to całkowicie rozsądny zakres.
adaptacja z oryginalnego postu, który ukazał się na 00f.net