Comments 8
У себя на локали получил для сайта значение 41094, а в G Suite Toolbox — 86399. Кому верить? :)
0
localhost?
Я к слову о том, что если вы проверяете свой домен, то должны знать его настоящее установленное значение TTL
Я к слову о том, что если вы проверяете свой домен, то должны знать его настоящее установленное значение TTL
0
Нет, не localhost. Взял еще один публичный сайт proza.ru.
dig на убунте:
G Suite Toolbox:
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
0
Похоже гугловые 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
+1
Послыайте запрос напрямую DNSам, которые обслуживают ваш домен. Скорее всего на «локали» вы получаете овтет от кеширующего провайдерского сервера.
0
при выборе небольших значений (меньше одного часа) вы сможете сохранить работоспособность сети и лучше подготовить ее к внедрению изменений
Я бы на это не рассчитывал, некоторые провайдеры игнорируют низкие значения TTL на своих кэширующих DNS и округляют их до часа.
0
Для расчета максимального (худший случай) временного интервала, необходимого на обновление значения записи DNS в ссылках для всех клиентов, умножьте число звеньев цепочки (без учета полномочного сервера) на значение TTL.
Например, если значение TTL составляет 3600 секунд (1 час), а цепочка DNS состоит из 5 звеньев, полное распространение изменений должно занять не более 18 000 секунд (5 часов).
Насколько мне помнится, каждый хоп будет передавать не начальное значение TTL записи, а оставшееся время с момента кеширования. Т.е. в вашем примере, через 3600 секунд, запись протухнет на всех 5 серверах цепочки.
0
Sign up to leave a comment.
Подробное руководство по настройке TTL для записей DNS