2016-12-28 17 views
3

Я немного смущен относительно понятий TTL и времени распространения, и я хотел бы прояснить некоторые вещи, на которые мне не удалось найти ответы на конкретные вопросы в Интернете.Зависит ли распространение DNS от TTL?

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

Итак ...

  1. Если я изменить DNS-запись, это изменение произойдет немедленно, принимая время TTL для обновления по всему миру? Или это только после того, как прошло время TTL, что эти изменения будут обновляться, а затем начать распространяться по всему миру?

  2. Каждый сервер будет периодически проверять DNS в интервалах TTL, не так ли? Итак, если сервер проверяет запись DNS с TTL 14400, и сразу же меняю его, сервер будет обновлять свой кеш после чуть меньше 14400. Если мне случится изменить его непосредственно перед его проверкой, он обновит почти сразу же.

  3. Значения TTL для записи DNS (например, MX) зависят от других значений TTL или времени обновления, например, более общих элементов, которые переопределяют/расширяют его фактическое время жизни (например, время обновления SOA) ? Другими словами, если мне нужно только обновлять записи MX, и мне нужно делать это каждые 4 часа, мне нужно установить что-нибудь еще, кроме TTL для этих записей MX?

  4. Является ли TTL (теоретическим) пределом, что конкретная запись DNS будет обновляться по всему миру? Хотя фактические времена обновления сильно различаются, как я понимаю из-за того, что серверы сохраняют время своего кеша.

ответ

1
  1. Там нет "распространения", есть только кэширование. Поэтому, когда вы обновляете запись на авторитетном сервере, она будет немедленно изменена. Кэширующие серверы будут обновлять свои данные по истечении срока действия кэша.

Например, я буду запрашивать локальный 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
  • Для хорошо управляемых серверов, да. Для других вы ничего не можете сделать.
  • +0

    Спасибо за ваши ответы :) 1. Итак, срок действия кеша относится к TTL, принятому серверами в то время, когда они в последний раз проверяли право DNS? 3. Итак, в каком случае применяются значения SOA TTL? Будет ли в учетной записи реселлера, например, SOA отвечать за обновление DNS-записей домена клиента? – Ata3ias

    +1

    См. Правки, он должен уточнить кеширование. Кроме того, я добавил ссылку на подробное объяснение SOA TTL. –