Правильно рассчитать DNS TTL с хоста -a вывода
Я пытаюсь выяснить, как обрабатываются TTL в DNS (в конце концов, я пытаюсь найти самый быстрый способ переключения домена), но почему-то я застрял в интерпретации значений TTL.
Например, сегодня я переместил домен, в котором были следующие записи DNS, прежде чем переместить его мне:
host -a example.com ns.old-provider.net
Trying "example.com"
Using domain server:
Name: ns.old-provider.net
Address: 0.0.0.0#53
Aliases:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45674
;; flags: qr aa rd; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 4
;; QUESTION SECTION:
;example.com. IN ANY
;; ANSWER SECTION:
example.com. 3600 IN NS ns9.old-provider.net.
example.com. 3600 IN NS ns.old-provider.net.
example.com. 180 IN MX 10 mail.example.com.
example.com. 3600 IN NS ns8.old-provider.net.
example.com. 180 IN A 0.0.0.0
example.com. 3600 IN SOA ns.old-provider.net. info.old-provider.net. 2015012001 14400 3600 604800 3600
;; ADDITIONAL SECTION:
ns8.old-provider.net. 86400 IN A 0.0.0.0
ns9.old-provider.net. 3600 IN A 0.0.0.0
ns.old-provider.net. 86400 IN A 0.0.0.0
mail.example.com. 180 IN A 0.0.0.0
Received 258 bytes from 0.0.0.0#53 in 31 ms
Моя интерпретация вышеприведенного вывода такова, что этот домен должен быть разрешен для моего сервера максимум через 3600 секунд (так как я меняю записи NS и A).
Поскольку я переместил вышеуказанный домен, через 3 часа после получения ACK-файла TRANSFER он все еще переходит на неправильный DNS-сервер:
host -a example.com 8.8.8.8
[...]
;; ANSWER SECTION:
example.com. 179 IN A 0.0.0.0
example.com. 3599 IN NS ns9.old-provider.net.
example.com. 3599 IN NS ns.old-provider.net.
example.com. 179 IN MX 10 mail.example.com
example.com. 3599 IN NS ns8.old-provider.net.
example.com. 3599 IN SOA ns.old-provider.net. info.old-provider.net. 2015012001 14400 3600 604800 3600
Как вы можете видеть, я использую DNS-сервер Google для проверки, так что я полагаю, что это может быть сохранением того, что TTL соблюдается.
Я должен что-то упустить. Но я не могу понять - кто-нибудь может дать мне подсказку, пожалуйста?
Является ли проблема TTL записи SOA, поэтому перед переключением ее следует уменьшить?
РЕДАКТИРОВАТЬ
dig +trace + дополнительный пример.com @8.8.8.8
; <<>> DiG 9.8.1-P1 <<>> +trace +additional example.com @8.8.8.8
;; global options: +cmd
. 1024 IN NS c.root-servers.net.
. 1024 IN NS i.root-servers.net.
. 1024 IN NS j.root-servers.net.
. 1024 IN NS d.root-servers.net.
. 1024 IN NS f.root-servers.net.
. 1024 IN NS g.root-servers.net.
. 1024 IN NS k.root-servers.net.
. 1024 IN NS a.root-servers.net.
. 1024 IN NS h.root-servers.net.
. 1024 IN NS l.root-servers.net.
. 1024 IN NS b.root-servers.net.
. 1024 IN NS e.root-servers.net.
. 1024 IN NS m.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 30 ms
de. 172800 IN NS z.nic.de.
de. 172800 IN NS f.nic.de.
de. 172800 IN NS a.nic.de.
de. 172800 IN NS l.de.net.
de. 172800 IN NS s.de.net.
de. 172800 IN NS n.de.net.
a.nic.de. 172800 IN A 194.0.0.53
a.nic.de. 172800 IN AAAA 2001:678:2::53
f.nic.de. 172800 IN A 81.91.164.5
f.nic.de. 172800 IN AAAA 2a02:568:0:2::53
l.de.net. 172800 IN A 77.67.63.105
l.de.net. 172800 IN AAAA 2001:668:1f:11::105
n.de.net. 172800 IN A 194.146.107.6
n.de.net. 172800 IN AAAA 2001:67c:1011:1::53
s.de.net. 172800 IN A 195.243.137.26
z.nic.de. 172800 IN A 194.246.96.1
;; Received 343 bytes from 2001:500:2f::f#53(2001:500:2f::f) in 179 ms
example.com. 86400 IN NS ns9.old-provider.net.
example.com. 86400 IN NS ns8.old-provider.net.
example.com. 86400 IN NS ns.old-provider.net.
;; Received 93 bytes from 0.0.0.0#53(0.0.0.0) in 39 ms
example.com. 180 IN A 0.0.0.0
;; Received 45 bytes from 0.0.0.0#53(0.0.0.0) in 29 ms
1 ответ
Я не могу ответить наверняка, потому что вы используете скрытый домен, но когда вы меняете апекс NS записи также важно проверить TTL вашего ссылающегося NS записи и соответствующие клейкие записи. Следует ожидать, что старые серверы имен будут продолжать просматривать запросы в течение всей продолжительности. Это было бы наиболее вероятной проблемой для меня, учитывая тесты, которые вы выполняете.
В качестве фона, я собираюсь направить вас к существующим вопросам и ответам, которые я сделал некоторое время назад. Принятый ответ ссылается на RFC2181 (я использую его часто, так как он предназначен для потребления человеком):
Какова роль записей NS на вершине домена DNS?
Я считаю, что здесь происходит то, что ваши клейкие записи пассивно кэшируются. Причина, по которой это не очевидно из вашей проверки, заключается в том, что явный запрос NS а также A записи часто вызывают авторитетный поиск, если он еще не был сделан. По сути, клей пассивно соблюдается до тех пор, пока не истечет TTL или кто-то явно не запросит запись.
Самый простой способ подтвердить это:dig +trace +additional example.com