Zalecany DNS TTL

24

Wiem, że może być bardzo różnie w zależności od sytuacji, ale w przypadku hostingu strony internetowej bez planów przeniesienia serwera hostingowego, co należy ustawić TTL w rekordzie DNS?

Brian Fisher
źródło

Odpowiedzi:

20

Zwykle zostawiam to na domyślnym Slicehost, 86 400 sekund (1 dzień). Upuszczam go do 10 minut, kiedy czeka mnie ruch i czekam dzień lub dwa.

edytuj: Obecnie (2016) staram się utrzymywać niski poziom - ~ 5 minut.

ceejayoz
źródło
To spora różnica! Przydałoby się, gdyby odpowiedź zawierała uzasadnienie zmiany na znacznie niższe TTL.
Anthony G - sprawiedliwość dla Moniki
3
@AnthonyGeoghegan Nowoczesne serwery mogą obsługiwać znacznie częstsze żądania, a teraz, gdy jestem na bardzo niezawodnych serwerach nazw (AWS Route 53), wolę mieć możliwość zmiany DNS w dowolnym momencie.
ceejayoz
12

Standardy (napisane dawno temu w 1987 r.) Sugerują 86 400 sekund (1 dzień) jako minimalną domyślną wartość TTL.

Ważne jest, aby wartości TTL były ustawione na odpowiednie wartości. TTL to czas (w sekundach), w którym program tłumaczący wykorzysta dane uzyskane z serwera, zanim ponownie poprosi serwer. Jeśli ustawisz zbyt niską wartość, twój serwer zostanie obciążony wieloma powtórzeniami. Jeśli ustawisz zbyt wysoką wartość, zmieniane informacje nie zostaną rozpowszechnione w rozsądnym czasie. Jeśli pozostawisz pole TTL puste, domyślnie będzie ono określone w rekordzie SOA dla strefy.

Większość informacji o urządzeniu nie zmienia się znacząco przez długi czas. Dobrym sposobem na skonfigurowanie wartości TTL byłoby ustawienie ich na wysoką wartość, a następnie obniżenie wartości, jeśli wiesz, że zmiana nastąpi wkrótce. Możesz ustawić większość TTL na dowolne miejsce między dniem (86400) a tygodniem (604800). Następnie, jeśli wiesz, że niektóre dane będą się zmieniać w najbliższej przyszłości, ustaw TTL dla tej RR na niższą wartość (od godziny do dnia), aż nastąpi zmiana, a następnie przywróć ją do poprzedniej wartości.

Ponadto wszystkie RR o tej samej nazwie, klasie i typie powinny mieć tę samą wartość TTL.

Zobacz RFC 1033: http://tools.ietf.org/html/rfc1033

RFC 1912 (od 1996) sugeruje, że 3 dni mogą być bardziej odpowiednie dla SOAzapisów.

http://www.ietf.org/rfc/rfc1912.txt

dmourati
źródło
4
Wyobrażam sobie, że ruch DNS z niskich czasów TTL był znacznie większym problemem w 1987 i 1996 niż w 2011/2012.
ceejayoz
6
Oba przytoczone przez ciebie standardy odnoszą się tylko do pola „Minimum” rekordu SOA, które i tak nie jest już używane do określania domyślnego lub minimalnego TTL, jak miało to miejsce w momencie pisania tych standardów. Najlepsze praktyki DNS napisane 27 i 18 lat temu zostały napisane, gdy DNS - a nawet Internet - był inną bestią. W dzisiejszych czasach 300 sekund (5 minut) jest dość powszechnym TTL dla głównych rekordów A / AAAA, chociaż przydatne tylko wtedy, gdy potrzebujesz szybkiego przełączania awaryjnego, w przeciwnym razie bardziej odpowiednie byłoby 6 godzin +. Rekordy NS i rekordy A / AAAA dla adresów NS zwykle trwają 1 dzień lub dłużej.
thomasrutter
6
Spóźniłem się z komentowaniem tego, ale należy zauważyć, że niewłaściwe jest określanie tych RFC jako „standardów”. ( RFC 1796 ) Zwracam na to uwagę, aby czytelnicy z dzisiejszego świata nie odchodzili od tego pytania i odpowiedzi ze złym zrozumieniem.
Andrew B,
7

Zauważyłem, że modne jest posiadanie krótszych czasów TTL, aby móc szybciej reagować w sytuacjach awaryjnych (szczególnie w środowisku HA DNS).

SuperBOB
źródło
1
Tak. CloudFlare domyślnie ustawia TTL wszystkich swoich klientów na 300 sekund (5 minut), co jest szalenie krótkie, ale oczywiście widzą korzyści.
Simon East
3

Po prostu pozostawiłbym domyślną wartość ustawioną przez twojego hosta, chyba że z jakiegoś powodu jest absurdalnie wysoka lub niska. Następnie, jeśli kiedykolwiek zechcesz się przenieść, zmniejsz go do około 20 minut na kilka dni przed planowanym przeprowadzeniem.

squillman
źródło
2

4 godziny powinny być w porządku, zapewniając zadowalającą równowagę. Tego używam w większości stref.

Mihai Limbăşan
źródło
4
To chyba zbyt krótko.
dmourati
5
@dmourati: Jest rok 2011. W przeważającej większości małych (tj. poniżej 1000 stref) serwerów DNS i dla wszystkich klientów dodatkowe wymagania dotyczące obciążenia procesora i przepustowości są absolutnie nieistotne. Oczywiście, jeśli twoje serwery DNS przestaną działać na więcej niż 4 godziny, jesteś SOL, ale jeśli to ważne i nie możesz zapewnić niezawodnej usługi DNS, to nie masz firmy, która hostowałaby twoją usługę DNS na tak chwiejnych podstawach. ..
Mihai Limbăşan,
3
Gdy użytkownik zadaje pytanie, na które odpowiedź jest udzielana bezpośrednio w RFC, kierujesz go do RFC niezależnie od roku.
dmourati,
@dmourati Czy jest to zalecane w RFC?
Joó Ádám
Tak, patrz moja odpowiedź powyżej.
dmourati
2

(uwaga: ten post dotyczy TTL w indywidualnych rekordach A / AAAA, niektóre inne typy rekordów mogą mieć dłuższe TTL, ponieważ nie reprezentują pojedynczych punktów awarii w ten sam sposób).

Naprawdę musisz o tym pomyśleć w kontekście planów odzyskiwania po awarii. Nie chodzi o to, kiedy zamierzasz przenieść witrynę (w przypadku zamierzonych ruchów możesz zmniejszyć TTL w przedbiegu do ruchu). Chodzi o to, kiedy Twój gospodarz znika z Internetu lub wykopuje Cię z powodu naruszenia TOS lub wykopuje, ponieważ nie może obsłużyć DDOS, który przyszedł po twojej myśli.

Jeśli w tych okolicznościach nie zależy Ci na tym, aby Twoja witryna nie działała przez jeden dzień, pozostaw TTL domyślnie na jeden dzień. Jeśli masz przestrzeń adresową PI i tranzyt BGP w wielu lokalizacjach od wielu dostawców i zamierzasz obsłużyć odzyskiwanie po awarii na poziomie BGP, to kontynuuj i pozostaw domyślną wartość jednego dnia. Z drugiej strony, jeśli używasz DNS jako mechanizmu dzielenia się tąfotą na stronę trybu failover, to chcesz znacznie krótszego czasu TTL, 5 minut jest dość powszechną wartością.

Peter Green
źródło