- Там нет "распространения", есть только кэширование. Поэтому, когда вы обновляете запись на авторитетном сервере, она будет немедленно изменена. Кэширующие серверы будут обновлять свои данные по истечении срока действия кэша.
Например, я буду запрашивать локальный DNS-сервер моей компании для одного имени хоста из своего личного домена. авторитетное имя сервера моего домена находится в АМС, а запись ata3ias.test.bajic.nl конфигурируется с TTL 120 и IP-адрес 127.0.0.5:
Сначала я запросить авторитетное имя сервера AWS:
[[email protected] ~]# dig ata3ias.test.bajic.nl @ns-1695.awsdns-19.co.uk
...
;; ANSWER SECTION:
ata3ias.test.bajic.nl. 120 IN A 127.0.0.5
;; WHEN: Thu Dec 29 12:43:13 2016
затем я изменить IP-адрес на 127.0.0.6 и запрос снова:
[[email protected] ~]# dig ata3ias.test.bajic.nl @ns-1695.awsdns-19.co.uk
...
;; ANSWER SECTION:
ata3ias.test.bajic.nl. 120 IN A 127.0.0.6
;; WHEN: Thu Dec 29 12:43:22 2016
Далее я опрашивает внутренний сервер DNS моей компании (я могу с уверенностью предположить, что никто до пытался не решен этот адрес и там не входит в кеш DNS-сервера):
Обратите внимание на TTL, а также обратите внимание на время запроса: сервер кэширования запросил авторитетный DNS-сервер, получил ответ с TTL и запомнил эту информацию.
Теперь, если я сделаю это снова:
[[email protected] ~]# dig ata3ias.test.bajic.nl @10.0.0.5
...
;; ANSWER SECTION:
ata3ias.test.bajic.nl. 107 IN A 127.0.0.6
;; Query time: 0 msec
;; WHEN: Thu Dec 29 12:46:32 2016
Этот ответ подается из кэша, вы можете увидеть, что TTL (так что не только сервер кэширования будет хранить данные в кэше времени TTL, его также передаст информацию о оставшихся TTL для клиентов), а также вы увидите, что потребовалось 0 мс для повторного запроса запроса (потому что не было необходимости связываться с авторитетным сервером имен).
Затем я перехожу к консоли AWS, чтобы снова изменить IP-адрес и изменить его на 127.0.0.7. Для подтверждения изменения, я буду снова запросить полномочный сервер непосредственно:
[[email protected] ~]# dig ata3ias.test.bajic.nl @ns-1695.awsdns-19.co.uk
;; ANSWER SECTION:
ata3ias.test.bajic.nl. 120 IN A 127.0.0.7
;; WHEN: Thu Dec 29 12:47:10 2016
Теперь я запросить внутренний сервер DNS снова:
[[email protected] ~]# dig ata3ias.test.bajic.nl @10.0.0.5
;; ANSWER SECTION:
ata3ias.test.bajic.nl. 63 IN A 127.0.0.6
;; WHEN: Thu Dec 29 12:47:16 2016
Он по-прежнему подают старые данные, и будет делать это для другого 63 секунды. Через минуту:
[[email protected] ~]# dig ata3ias.test.bajic.nl @10.0.0.5
;; ANSWER SECTION:
ata3ias.test.bajic.nl. 3 IN A 127.0.0.6
;; WHEN: Thu Dec 29 12:48:16 2016
И, наконец, спустя несколько секунд, внутренний сервер DNS будет служить свежей информации:
[[email protected] ~]# dig ata3ias.test.bajic.nl @10.0.0.5
;; ANSWER SECTION:
ata3ias.test.bajic.nl. 119 IN A 127.0.0.7
;; WHEN: Thu Dec 29 12:48:21 2016
<ол начать = "2">
Ровно.
В целом, значения SOA TTL вызывают озабоченность только для синхронизации между серверами имен первичных и вторичных (подчиненных), поэтому нет, вам не нужно устанавливать ничего, кроме TTL для записей MX. Вы можете найти подробное объяснение всех записей SOA TTL here
Для хорошо управляемых серверов, да. Для других вы ничего не можете сделать.
Спасибо за ваши ответы :) 1. Итак, срок действия кеша относится к TTL, принятому серверами в то время, когда они в последний раз проверяли право DNS? 3. Итак, в каком случае применяются значения SOA TTL? Будет ли в учетной записи реселлера, например, SOA отвечать за обновление DNS-записей домена клиента? – Ata3ias
См. Правки, он должен уточнить кеширование. Кроме того, я добавил ссылку на подробное объяснение SOA TTL. –