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

Я к слову о том, что если вы проверяете свой домен, то должны знать его настоящее установленное значение TTL
Нет, не 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
Похоже гугловые 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
И не только гугловые, Windows Server через дебаг ведет себя также — при первом запросе показывает полный TTL, а в последующих он уменьшается.
Послыайте запрос напрямую DNSам, которые обслуживают ваш домен. Скорее всего на «локали» вы получаете овтет от кеширующего провайдерского сервера.
при выборе небольших значений (меньше одного часа) вы сможете сохранить работоспособность сети и лучше подготовить ее к внедрению изменений

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

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

Насколько мне помнится, каждый хоп будет передавать не начальное значение TTL записи, а оставшееся время с момента кеширования. Т.е. в вашем примере, через 3600 секунд, запись протухнет на всех 5 серверах цепочки.
Only those users with full accounts are able to leave comments. Log in, please.