1

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
2

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 referring NS 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 and A 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

2
  • 1
    I'm guessing you put together some elements of that edit by hand, considering that the glue records from +additional are completely absent for example.com. Using the domain that you just gave me, the nameservers for de. are serving up a referral with TTLs of 86400 across the board. (for both NS records and A record glue) It's a safe assumption that the TTL on those A records would have been the same when they pointed at your old provider. As a result, there would have been servers on the internet taking up to 24 hours to notice your change. – Andrew B Mar 12 '15 at 15:21
  • Sorry for misleading you here - indeed I used example.com just as replacement for my live domain in the output. Again, thanks for your extensive explanation. – s1lv3r Mar 12 '15 at 17:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.