Назад | Перейти на главную страницу

Есть ли способ узнать TTL для записей DNS корневого сервера имен?

В настоящее время я переношу зону DNS от одного поставщика DNS-сервера к другому. Я пытаюсь оценить, сколько времени потребуется для распространения изменения, и понять, какой может быть задержка, если я выберу откат в середине потока.

Раньше я думал, что могу:

dig example.com ns

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

Я проверил это, установив тестовую запись в зоне у каждого из провайдеров:

Provider1 test.example.com 10.0.0.1
Provider2 test.example.com 192.168.0.1

Для обоих поставщиков TTL в записях NS равняется 0, тогда как записи NS на уровне регистратора TLD указывают на серверы имен Provider1.

Когда я меняю записи NS в зоне Provider1, я почти сразу вижу, как это отражается в запросах NS (используя dig example.com ns).

Однако, когда я отправляю запрос для записи A, т.е.

test.example.com

он всегда возвращается

10.0.0.1

независимо от того, какие записи NS в зоне у Провайдера 1 установлены на.

На основании этого я пришел к выводу, что записи NS в файле зоны не имеют отношения к миграции и что важны только записи серверов имен на уровне TLD.

Однако я не могу понять, как долго, вероятно, будут распространяться изменения, вперед или назад.

Можно ли узнать, с какими TTL я работаю для записей, исходящих от корневых серверов TLD?

На основании этого я пришел к выводу, что записи NS в файле зоны не имеют отношения к миграции и что важны только записи серверов имен на уровне TLD.

Это неверная гипотеза, но легко ошибиться. Вы можете прочитать немного больше о записях apex NS Вот. Краткая версия заключается в том, что оба значения имеют значение, и тот, который используется, будет отличаться в зависимости от того, запрашивал ли кеширующий DNS-сервер ранее ваш домен или нет.

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

В настоящее время я переношу зону DNS от одного поставщика DNS-сервера к другому. Я пытаюсь оценить, сколько времени потребуется для распространения изменения, и понять, какой может быть задержка, если я выберу откат в середине потока.

Я собираюсь сосредоточиться на этой теме, поскольку в остальной части вашего вопроса у вас есть несколько фальстартов. Во-первых, важно помнить, что TTL кэшируются на рекурсивных DNS-серверах. Поскольку все в Интернете используют разные рекурсивные DNS-серверы, только Вы можете сделать предположение, что это займет до п секунд, с п значение TTL.

Это подводит нас к тому, какие значения TTL здесь актуальны:

  • TTL для отдельных записей, находящихся в кеше. Даже если NS Срок действия записей истекает, запросы на отдельные записи, находящиеся в кеше, не истекают автоматически. Пример: если test.example.com IN A истекает через десять минут, но example.com IN NS истекает через пять минут, test.example.com останется в кеше даже после NS записи изменились. Какие-либо проблемы, связанные со значением этой записи на новых серверах, не станут очевидными до тех пор, пока срок действия записи не истечет и она не будет обновлена.
  • TTL для NS связать записи, обслуживаемые DNS-серверами TLD. Они используются рекурсивными серверами, которым необходимо получить информацию о вашем домене при первом запросе. Эти TTL влияют на то, как долго DNS-серверы, перечисленные в вашем файле зоны, будут использоваться для следующего обновления. (обратитесь к разделу вопросов и ответов, который я дал выше, чтобы получить разъяснения по этому поводу)
  • TTL для NS записи, перечисленные в верхней части файла зоны. По истечении срока жизни клейкой записи эти TTL мощь использоваться вместо этого. Реализации различаются по этой детали. Поскольку вы имеете дело со множеством различных реализаций Интернета, единственное безопасное предположение - это то, что некоторые серверы его используют.

Вы не можете предположить, что все кешированные NS TTL записи в Интернете поступают из того или иного источника. Это заставляет вас планировать работу с более высоким из двух, если вы действительно не беспокоитесь о рекурсивных DNS-серверах, с которыми вы не работаете.

Собирая все это вместе, мы приходим к следующим выводам:

  • Максимальное количество времени, необходимое для обновления любой данной записи DNS на новом сервере имен, составляет самый высокий TTL между этой записью NS записи в клее, а NS записи в зоне.
  • Предполагая, что TTL на новом DNS-сервере идентичны старому серверу, максимальное время, необходимое для отката, составляет наивысшее значение из трех TTL, снова. Любые запросы, которые поступили на новый сервер между моментом, когда вы изначально изменили DNS-серверы и отменили изменение, будут полагаться на значения, полученные с нового сервера.
  • Это очень важно чтобы все DNS-серверы, участвующие в изменении, работали и синхронизировались до тех пор, пока все TTL не истекут после вашего последнего NS изменение записи. Вам не только нужны все серверы, доступные для клиентов, которые не приняли последнее изменение, но и любое несоответствие в данных записи между ними может еще больше запутать.

Вы можете легко сделать это с помощью nslookup в Windows, я предполагаю, что вы можете сделать то же самое с dig. С помощью nslookup вы просто запрашиваете у одного из серверов имен GTLD записи сервера имен вашего домена, используя отладку, чтобы получить список серверов имен для вашего домена с TTL этих записей сервера имен.

Microsoft Windows [Version 10.0.10240]
(c) 2015 Microsoft Corporation. All rights reserved.

C:\Users\Joe>nslookup
Default Server:  Unknown
Address:  192.168.1.2

> server f.gtld-servers.net
Default Server:  f.gtld-servers.net
Address:  192.35.51.30

> set q=ns
> set debug
> crabbygeezer.com
Server:  f.gtld-servers.net
Address:  192.35.51.30

------------
Got answer:
    HEADER:
        opcode = QUERY, id = 4, rcode = NOERROR
        header flags:  response, want recursion
        questions = 1,  answers = 0,  authority records = 5,  additional = 10

    QUESTIONS:
        crabbygeezer.com, type = NS, class = IN
    AUTHORITY RECORDS:
    ->  crabbygeezer.com
        nameserver = freedns1.registrar-servers.com
        ttl = 172800 (2 days)
    ->  crabbygeezer.com
        nameserver = freedns2.registrar-servers.com
        ttl = 172800 (2 days)
    ->  crabbygeezer.com
        nameserver = freedns3.registrar-servers.com
        ttl = 172800 (2 days)
    ->  crabbygeezer.com
        nameserver = freedns4.registrar-servers.com
        ttl = 172800 (2 days)
    ->  crabbygeezer.com
        nameserver = freedns5.registrar-servers.com
        ttl = 172800 (2 days)
    ADDITIONAL RECORDS:
    ->  freedns1.registrar-servers.com
        internet address = 208.64.122.242
        ttl = 172800 (2 days)
    ->  freedns1.registrar-servers.com
        internet address = 72.20.53.50
        ttl = 172800 (2 days)
    ->  freedns2.registrar-servers.com
        internet address = 208.64.122.244
        ttl = 172800 (2 days)
    ->  freedns2.registrar-servers.com
        internet address = 72.20.38.137
        ttl = 172800 (2 days)
    ->  freedns3.registrar-servers.com
        internet address = 5.135.128.216
        ttl = 172800 (2 days)
    ->  freedns3.registrar-servers.com
        internet address = 62.210.149.103
        ttl = 172800 (2 days)
    ->  freedns4.registrar-servers.com
        internet address = 62.210.149.102
        ttl = 172800 (2 days)
    ->  freedns4.registrar-servers.com
        internet address = 72.20.53.50
        ttl = 172800 (2 days)
    ->  freedns5.registrar-servers.com
        internet address = 192.99.40.34
        ttl = 172800 (2 days)
    ->  freedns5.registrar-servers.com
        internet address = 72.20.53.50
        ttl = 172800 (2 days)

------------
crabbygeezer.com
        nameserver = freedns1.registrar-servers.com
        ttl = 172800 (2 days)
crabbygeezer.com
        nameserver = freedns2.registrar-servers.com
        ttl = 172800 (2 days)
crabbygeezer.com
        nameserver = freedns3.registrar-servers.com
        ttl = 172800 (2 days)
crabbygeezer.com
        nameserver = freedns4.registrar-servers.com
        ttl = 172800 (2 days)
crabbygeezer.com
        nameserver = freedns5.registrar-servers.com
        ttl = 172800 (2 days)
freedns1.registrar-servers.com
        internet address = 208.64.122.242
        ttl = 172800 (2 days)
freedns1.registrar-servers.com
        internet address = 72.20.53.50
        ttl = 172800 (2 days)
freedns2.registrar-servers.com
        internet address = 208.64.122.244
        ttl = 172800 (2 days)
freedns2.registrar-servers.com
        internet address = 72.20.38.137
        ttl = 172800 (2 days)
freedns3.registrar-servers.com
        internet address = 5.135.128.216
        ttl = 172800 (2 days)
freedns3.registrar-servers.com
        internet address = 62.210.149.103
        ttl = 172800 (2 days)
freedns4.registrar-servers.com
        internet address = 62.210.149.102
        ttl = 172800 (2 days)
freedns4.registrar-servers.com
        internet address = 72.20.53.50
        ttl = 172800 (2 days)
freedns5.registrar-servers.com
        internet address = 192.99.40.34
        ttl = 172800 (2 days)
freedns5.registrar-servers.com
        internet address = 72.20.53.50
        ttl = 172800 (2 days)
>

Синтаксис для выполнения аналогичного запроса с использованием dig является:

$ dig NS crabbygeezer.com @f.gtld-servers.net +trace

Раньше вы могли запросить запись SOA для домена, чтобы получить значения TTL по умолчанию:

dig example.com. SOA

Но это устарело в пользу директивы $ TTL.

Если у вас есть определенные записи, которые вас интересуют, вы можете добавить флаг + ttlid, чтобы копать:

dig +ttlid somehost.example.com.

Чтобы получить точный оставшийся TTL:

;; ANSWER SECTION:
somehost.example.com.      604800  IN      A       192.168.99.5

(второе поле - TTL - в данном случае 604800)