I'm trying to figure out how TTLs are handled in DNS (in the end I'm trying to figure out the fastest way to switch over a domain), but somehow I'm stuck in interpreting TTL values.
For example I moved a domain today which had the following DNS records before moving it to me:
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
My interpretation of the above output is, that this domain should be resolved to my server after a maximum of 3600 seconds (as I'm changing both, the NS and A records).
As I did move the above domain, 3 hours after receiving the TRANSFER ACK it is still resolving to the wrong DNS server:
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
As you can see I'm using the Google DNS server to check, so I guess it can be save that the TTL is respected.
I must be missing something. But I can't figure it out – can anyone give me a hint here, please?
Is the problem the TTL of the SOA record, so this must be lowered before making the switch?
EDIT
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
Best Answer
I can't answer for certain because you're using an obfuscated domain, but when you're changing the apex
NS
records it is also important to verify the TTL of your referringNS
records and corresponding glue records. It should be expected that the old nameservers will continue to see queries for the full duration. This would be the most likely problem to me given the tests that you are running.As background, I'm going to steer you toward an existing Q&A I did awhile back. The accepted answer links to RFC2181 (I use it often since it's designed for human consumption):
What is the role of NS records at the apex of a DNS domain?
I believe what is happening here is that your glue records were being passively cached. The reason why this isn't obvious from your validation is that an explicit query for the
NS
andA
records will often trigger an authoritative lookup if one has not been made yet. Basically, the glue is passively respected until such a point that either the TTL expires, or someone explicitly requests the record.The easiest way to confirm is to run this:
dig +trace +additional example.com