Подробное руководство по настройке TTL для записей DNS

[dso]

У себя на локали получил для сайта значение 41094, а в G Suite Toolbox — 86399. Кому верить? :)

[TimsTims]

localhost?

Я к слову о том, что если вы проверяете свой домен, то должны знать его настоящее установленное значение TTL

[dso]

Нет, не localhost. Взял еще один публичный сайт proza.ru.

dig на убунте:

;; ANSWER SECTION:
proza.ru.		86400	IN	A	217.16.27.129

G Suite Toolbox:

;ANSWER
proza.ru. 10767 IN A 217.16.27.129

[navion]

Похоже гугловые DNS показывают TTL своего кэша.
Первый запрос:

dig proza.ru. 8.8.8.8

;; ANSWER SECTION:
proza.ru.               86228   IN      A       217.16.27.129

Через пару секунд:

dig proza.ru. 8.8.8.8

;; ANSWER SECTION:
proza.ru.               86221   IN      A       217.16.27.129

[navion]

И не только гугловые, Windows Server через дебаг ведет себя также — при первом запросе показывает полный TTL, а в последующих он уменьшается.

[KawaiDesu]

Послыайте запрос напрямую DNSам, которые обслуживают ваш домен. Скорее всего на «локали» вы получаете овтет от кеширующего провайдерского сервера.

[navion]

при выборе небольших значений (меньше одного часа) вы сможете сохранить работоспособность сети и лучше подготовить ее к внедрению изменений

Я бы на это не рассчитывал, некоторые провайдеры игнорируют низкие значения TTL на своих кэширующих DNS и округляют их до часа.

[HyperMe]

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

Например, если значение TTL составляет 3600 секунд (1 час), а цепочка DNS состоит из 5 звеньев, полное распространение изменений должно занять не более 18 000 секунд (5 часов).

Насколько мне помнится, каждый хоп будет передавать не начальное значение TTL записи, а оставшееся время с момента кеширования. Т.е. в вашем примере, через 3600 секунд, запись протухнет на всех 5 серверах цепочки.