Я пытаюсь понять, как 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 часа после получения TRANSFER ACK он все еще разрешается на неправильный 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 + additional example.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
Я не могу ответить с уверенностью, потому что вы используете обфусцированный домен, но когда вы меняете вершину NS записи также важно проверить TTL вашего ссылающегося NS записи и соответствующие записи клея. Следует ожидать, что старые серверы имен будут продолжать получать запросы в течение всего времени. Это будет для меня наиболее вероятной проблемой, учитывая тесты, которые вы выполняете.
В качестве фона я собираюсь направить вас к существующим вопросам и ответам, которые я сделал некоторое время назад. Принятый ответ ссылается на RFC2181 (я часто его использую, поскольку он предназначен для потребления людьми):
Какова роль NS-записей на вершине DNS-домена?
Я считаю, что здесь происходит то, что ваши клейкие записи пассивно кэшировались. Причина, по которой это не очевидно из вашей проверки, заключается в том, что явный запрос для NS и A записи часто вызывают авторитетный поиск, если он еще не был произведен. По сути, клей пассивно соблюдается до тех пор, пока либо не истечет TTL, либо кто-то явно не запросит запись.
Самый простой способ подтвердить это запустить: dig +trace +additional example.com