Рекомендуемый DNS TTL


24

Я знаю, что это может сильно отличаться в зависимости от ситуации, но для хостинга веб-сайта без планов перемещения хост-сервера, какой хороший TTL можно установить для записи DNS?

Ответы:


20

Я склонен оставить его по умолчанию Slicehost, 86 400 секунд (1 день). Я опускаю его до 10 минут, когда у меня есть ожидающий ход, и жду день или два.

редактировать: в эти дни (2016) я склонен держать его на низком уровне - ~ 5 минут.


Это большая разница! Было бы полезно, если бы ответ включал обоснование перехода на гораздо более низкий TTL.
Энтони Дж - справедливость для Моники

3
@AnthonyGeoghegan Современные серверы могут обрабатывать гораздо более частые запросы, и теперь, когда я работаю на высоконадежных серверах имен (AWS Route 53), я бы предпочел иметь возможность менять DNS в любой момент.
ceejayoz

12

Стандарты (написанные давно в 1987 году) предлагают 86 400 секунд (1 день) в качестве минимального значения TTL по умолчанию.

Важно, чтобы TTL были установлены на соответствующие значения. TTL - это время (в секундах), в течение которого распознаватель будет использовать данные, полученные с вашего сервера, прежде чем он снова запросит ваш сервер. Если вы установите слишком низкое значение, ваш сервер будет загружен множеством повторных запросов. Если вы установите слишком высокое значение, то измененная вами информация не будет распространяться в течение разумного периода времени. Если вы оставите поле TTL пустым, по умолчанию будет указано значение, указанное в записи SOA для зоны.

Большая часть информации о хосте не сильно меняется в течение длительных периодов времени. Хороший способ настроить свои TTL - установить их на высокое значение, а затем понизить его, если вы знаете, что скоро произойдут изменения. Вы можете установить большинство TTL где-нибудь между днем ​​(86400) и неделей (604800). Затем, если вы знаете, что некоторые данные будут изменяться в ближайшем будущем, установите TTL для этого RR до более низкого значения (от часа до дня) до тех пор, пока не произойдут изменения, а затем верните его до прежнего значения.

Кроме того, все RR с одинаковыми именем, классом и типом должны иметь одинаковое значение TTL.

См. RFC 1033: http://tools.ietf.org/html/rfc1033.

RFC 1912 (от 1996) предполагает, что 3 дня могут быть более подходящими для SOAзаписей.

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


4
Я полагаю, что DNS-трафик с низким TTL был значительно большей проблемой в 1987 и 1996 годах, чем в 2011/2012.
ceejayoz

6
Оба эти стандарта, которые вы цитируете, ссылаются только на поле «Минимум» записи SOA, которое больше не используется для определения значения по умолчанию или минимального TTL, как это было задумано еще при написании этих стандартов. Лучшие практики DNS, написанные 27 и 18 лет назад, были написаны, когда DNS - в действительности Интернет - был другим зверем. В настоящее время 300 секунд (5 минут) - это довольно распространенный TTL для основных записей A / AAAA, хотя он полезен только при необходимости быстрого переключения при сбое, в противном случае более подходящим будет 6 часов +. Записи NS и записи A / AAAA для адресов NS обычно составляют 1 день или более.
Томасруттер

6
Я опоздал с комментариями по этому поводу, но следует отметить, что неуместно называть какой-либо из этих RFC "стандартами". ( RFC 1796 ). Я отмечаю это, чтобы сегодняшние читатели не уходили от этого вопроса с неправильным пониманием.
Эндрю Б

7

Я заметил, что становится все более модным иметь более короткие TTL, чтобы иметь возможность быстрее реагировать в чрезвычайных ситуациях (особенно в среде HA DNS).


1
Да. CloudFlare по умолчанию задает TTL всех своих клиентов до 300 секунд (5 минут), что очень мало, но они, очевидно, видят преимущества.
Саймон Ист

3

Я бы просто оставил значение по умолчанию, установленное вашим хостом, если по какой-то причине оно не будет смехотворно высоким или низким. Затем, если вы когда-нибудь захотите переместить, уменьшите его до 20 минут или около того за пару дней до того, как вы планируете это сделать.


2

4 часа должно быть просто отлично, обеспечивая приемлемый баланс. Это то, что я использую в большинстве зон.


4
Это, наверное, слишком коротко.
dmourati

5
@dmourati: Это 2011 год. Для подавляющего большинства небольших DNS-серверов (то есть, под зонами 1000 или около того) и для всех без исключения дополнительных требований к загрузке ЦП и пропускной способности абсолютно ничтожно. Конечно, если ваши DNS-серверы не работают более 4 часов, вы - SOL, но если это важно и вы не можете предоставить надежную службу DNS, у вас нет бизнеса, в котором ваша служба DNS изначально находится на таком шатком фундаменте. ..
Михай Лимбашан

3
Когда пользователь задает вопрос, на который дан прямой ответ в RFC, вы направляете его в RFC независимо от того, какой это год.
Дмурати

@dmourati Это предписано в RFC?
Joó Ádám

Да, смотрите мой ответ выше.
dmourati


2

(примечание: этот пост относится к TTL на индивидальных записях A / AAAA, некоторые другие типы записей могут иметь более длинные TTL, поскольку они не представляют одинаковые точки отказа одинаково).

Вы действительно должны думать об этом с точки зрения ваших планов аварийного восстановления. Дело не в том, когда вы намереваетесь переместить сайт (для преднамеренных перемещений вы можете уменьшить TTL при подготовке к перемещению). Речь идет о том, когда ваш хост исчезает с лица интернета или выгоняет вас за нарушение TOS или выгоняет вас из-за того, что они не могут справиться с DDOS, попавшимся вам на пути.

Если вы не заботитесь о том, чтобы ваш сайт был недоступен в течение дня или около того в таких обстоятельствах, тогда оставьте TTL по умолчанию на один день. Если у вас есть адресное пространство PI и транзит BGP в нескольких местах от нескольких провайдеров, и вы собираетесь обрабатывать аварийное восстановление на уровне BGP, тогда оставьте его на один день по умолчанию. С другой стороны, если вы используете DNS в качестве механизма перенаправления вашего таффика на отказоустойчивый сайт, то вам нужен гораздо более короткий TTL, 5 минут - это довольно распространенное значение.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.