Jaki procent serwerów nazw honoruje TTL w dzisiejszych czasach?

Kilka lat temu musiałem dokonać kilku zmian DNS w ciągu kilku tygodni, kiedy przenosiłem części sprzętu z jednego centrum danych do drugiego. W tym czasie około 95% serwerów nazw na świecie wydawało się szanować wartość TTL, a około 5% zignorowało nasz i wymyśliło własne. Innymi słowy, 95% ruchu przekroczyło zdefiniowane przez nas 15-minutowe TTL. Kolejne 3% dotarło w pierwszej godzinie, 1% w pierwszym dniu, a kilku maruderów zajęło nawet trzy dni.

(Tak, OK, mylę procent ruchu z procentem serwerów nazw. Proszę wstawić ręczne przetwarzanie).

Było to mniej więcej w 2001 roku i używaliśmy dinozaurów do przesyłania pakietów przez tuby. Domyślam się, że dzisiejsze serwery nazw są lepiej zachowane i nie będzie problemu z maruderem. Czy ktoś ma przeczucie, jaki procent ruchu zmieni się obecnie w ramach określonego TTL? Czy wciąż istnieje wiele serwerów nazw, które ignorują TTL?

Przeprowadziliśmy się niedawno i mieliśmy wiele problemów z DNS.

Kiedy zrobiliśmy huśtawkę, większość klientów zaczęła od razu uzyskiwać nowe adresy IP. Ale niektórzy wciąż uderzali o stare adresy IP od tygodni. Pozostawiliśmy serwer na około miesiąc. W końcu przejrzeliśmy dzienniki IIS na starej maszynie i zadzwoniliśmy do klientów, mówiąc im, aby opróżnili DNS na tamtejszej firmie lub serwerach DNS ISP. To sprawiło, że ostatni z nich został przeniesiony.

To była niewielka liczba osób, które trzymały się starych adresów IP. Spośród 20 000 klientów, może 50 miało problemy po pierwszym dniu.

(Bardzo) długie wartości TTL tygodni są honorowane w maju 2011 r. Przez większość serwerów nazw rozstrzygających DNS do 2 tygodni.

W teście z użyciem just-dnslookup.com, mającym 50 globalnych rozproszonych aktywnych punktów pomiarowych, z rekordem A TTL ustawionym na 99,999.999 = 165 tygodni (dokładnie: 165 tygodni 2 dni 9 godzin 46 minut 39 sekund) i domyślnym TTL 2 tygodnie (= SOA + NS TTL).

Pierwsze wyszukiwanie zwraca:

• TTL 1 tydzień, dla 3 z 50 punktów pomiarowych
• TTL 165 tygodni, dla 47 z 50 punktów pomiarowych

Powracają kolejne wyszukiwania (przekonwertowane na oryginalną wartość TTL):

• TTL 1 tydzień, dla 3 z 50 punktów pomiarowych
• TTL 2 tygodnie, dla 46 z 50 punktów pomiarowych
• TTL 165 tygodni, dla 1 z 50 punktów pomiarowych

Drugi test (z użyciem innej domeny), w którym domyślna wartość TTL jest ustawiona na 4 tygodnie (= SOA + NS TTL), jest poniżej.

Pierwsze wyszukiwanie zwraca:

• TTL 1 tydzień, dla 3 z 50 punktów pomiarowych
• TTL 2 tygodnie dla 1 z 50 punktów pomiarowych
• TTL 165 tygodni, dla 46 z 50 punktów pomiarowych

Powracają kolejne wyszukiwania (przekonwertowane na pełną długość TTL):

• TTL 1 tydzień, dla 3 z 50 punktów pomiarowych
• TTL 2 tygodnie dla 47 z 50 punktów pomiarowych
• TTL 165 tygodni, dla 0 z 50 punktów pomiarowych

Z najbardziej znanych / najlepiej połączonych publicznych usług tłumaczących:

• Publiczny DNS Google [8.8.8.8 i 8.8.4.4] skraca się do 1 dnia.
• UltraDNS [rdns (1 | 2) .ultradns.net] honoruje pełne 165 tygodni.
• Sprintlink [ns (1 | 2 | 3) .sprintlink.net] honorować pełne 165 tygodni.

Niedawno przeniosłem DNS dla kilku domen, które hostują moją osobistą stronę i projektują witryny z GoDaddy na wewnętrzny DNS (tak, dosłownie mój dom ). Ogólnie rzecz biorąc, każda strona, do której mam zdalny dostęp, szanowała TTL i dobrze się zmieniła. To samo zgłosił każdy przyjaciel, którego mogłem poprosić o sprawdzenie, zarówno przez telefon stacjonarny, jak i komórkowy. Jedynym problemem, jak na ironię, były główne buforujące serwery DNS na $ University, na których pracuję, które zdawały się całkowicie ignorować TTL dla zapytań buforowanych (a nawet ignorować wartość TTL, którą przypisywali do buforowanego wyniku).

Wydaje się, że ogólnie TTL należy szanować. 56% serwerów autorytatywnych dla domen .com i .net korzysta z BIND, co oczywiście jest zgodne ze standardami. Wygląda na to, że Cablevision / Optimum (przynajmniej w NJ) używa Nominum CNS, który również szanuje TTL.

To nie jest odpowiedź na twoje pytanie; ale raczej dodatkowe rzeczy, które warto wziąć pod uwagę w testowaniu:

Łańcuchowe rekursory DNS i demony buforujące

Nie tylko rekursory DNS na brzegu buforują rekordy. Czasami ludzie łączą rekursory, a to dodaje czasu. To, czy należy to zrobić, czy nie, może być długotrwałą dyskusją opartą na tym, co ludzie próbują rozwiązać. Widziałem 3 poziomy rekurencji w centrum danych. Mieszanie rekursorów może dawać mieszane wyniki, ponieważ spadki TTL nie zawsze są zachowywane. Niektóre rekordy pamięci podręcznej systemów operacyjnych. Niektóre systemy stosują takie rzeczy nscd, dnsmasqi innych metod w celu zminimalizowania wpływu lokalnych problemów recursor i zmniejszyć obciążenie ich recursors. Cechy systemu operacyjnego różnią się w zależności od wersji wydania, demonów buforowania, wersji demonów buforowania itp.

[Edytuj] Aby powtórzyć, nie jest to normalne zachowanie demona rekursora lub buforowania. Nie zamierzam zawstydzić tych błędnych, ale jeden z nich jest uważany za nieobsługiwany, mimo że jest połączony z wieloma dystrybucjami Linuksa.

Pamięć podręczna DNS aplikacji

Niektóre przeglądarki również buforują rekordy. Java i inne aplikacje również buforują DNS. Czasami możesz ograniczyć maksymalne ttl w aplikacjach.

Wyniki końcowe mogą być wypaczone

Powyższe elementy mogą łatwo zmienić 15-minutowy czas TTL w ponad 60 minut lub nawet dłużej.

Dlatego często sugeruję, aby aplikacje lub strony internetowe rozważyły ​​posiadanie wielu aktywnych węzłów w projekcie odporności na awarie, aby klient mógł szybciej określić, kiedy jeden punkt wejścia do Twojej witryny uległ awarii i automatycznie poradził sobie z problemem w zgrabny i przewidywalny sposób , gdy jest to wykonalne. Anycast to jedna z metod, której używają niektóre firmy, aby przełączanie awaryjne było nieco przezroczyste i nie polegało tak bardzo na zmianach DNS. Istnieją również sprytne metody równoważenia obciążenia, które można wykonać w javascript przy użyciu wielu rekordów DNS.

Stare pytanie, ale nowe odpowiedzi (2017, 6 lat później):

1. Wydaje się, że prawie wszystkie światowe serwery DNS są aktualizowane w 5 minut
2. Google i OpenDNS pozwalają ręcznie opróżnić rekord DNS, przyspieszając aktualizacje propagacji

Przed poniższymi eksperymentami wcześniej zmieniłem TTL z 14400 (sekundy = 4 godziny) na 300 (sekundy = 5 minut), ale zrobiłem to 2 godziny przed eksperymentami, a ponieważ poprzedni TTL wynosił 4 godziny, nie jestem pewien, czy moja zmiana wydostałby się, gdyby serwery DNS nie miały własnego minimalnego TTL.

Moje eksperymenty:

Eksperyment 1:

Zmieniłem tłumaczenie nazwy na IP (rekord A) na autorytatywnym serwerze, a następnie sprawdziłem:

• https://www.whatsmydns.net
• https://dnschecker.org

Po 5 minutach (300 sekundach) około połowa globalnych serwerów sprawdzonych przez te strony została poprawiona.

Po 7 minutach wszystkie zostały zaktualizowane oprócz 1.

Eksperyment 2:

Google i OpenDNS pozwalają ręcznie opróżnić pamięć podręczną DNS dla określonej domeny. Spinki do mankietów:

• Flush Google wpis DNS cache „s dla swojej domeny: https://developers.google.com/speed/public-dns/cache
• Przemywać OpenDNS DNS cache entry „s dla swojej domeny: https://cachecheck.opendns.com/

Zaktualizowałem kolejny rekord A, a następnie natychmiast opróżniłem pamięć podręczną DNS Google. Mają captcha, która sprawiła, że ​​„kliknąłem wszystkie kwadraty ze znakami” 3 razy, więc zajęło mi to 1-2 minuty, zanim ukończyłem kolor.

Po 4 minutach tylko 1 serwer DNS sprawdzony przez te strony miał stary adres IP. Wszystkie pozostałe zostały zaktualizowane.

Więc wyczyszczenie pamięci podręcznej DNS Google i zmuszenie jej do ponownego zapytania do autorytatywnego serwera wydaje się przyspieszyć globalną propagację DNS, być może przez uruchomienie aktualizacji pamięci podręcznej na serwerach na całym świecie.

Jednak nawet bez koloru Google wydaje się, że propagacja odbywa się w ciągu kilku minut, a nie godzin lub dni.