Does DNS propagation depend on TTL?

Question

I am a little confused as to the concepts of TTL and propagation times and I'd like to clarify some things that I did not manage to find specific answers for in the web.

AFAIK, TTL (time-to-live) represents the (top) time needed for servers around the world to update their cached value for a specific DNS.

So...

1. If I change a DNS record, does this change happen immediately, taking TTL time to update around the world? Or is it only after TTL time has passed that these changes will update and then start to propagate through the world?

2. Each server will periodically check the DNS in intervals of TTL, right? So, if a server checks a DNS record with a TTL of 14400 and I change it immediately afterwards, the server will next update its cache after a little less than 14400. If I happen to change it just prior to its check, it will update almost immediately.

3. Do TTL values for a DNS record (e.g., MX) depend on other TTL values or update times of, say, more general elements that override/extend its actual time-to-live (e.g., SOA refresh time)? In other words, if I only care on updating MX records and I need to do it every 4 hours, do I need to set anything else except the TTL for those MX records?

4. Is TTL the (theoretical) limit that a specific DNS record will update around the world? Although the actual update times are greatly varied, as I understand due to servers keeping their own cache times.

Answer 1

1. There is no "propagation", there is only caching. So, when you update a record on a authoritative server, it will be changed there immediately. Caching servers will update their data once the cache expires.

For example, I will query my company's local DNS server for one hostname from my personal domain. My domain's authoritative name server is at AWS, and the record ata3ias.test.bajic.nl is configured with TTL 120 and IP address 127.0.0.5:

First I will query the authoritative AWS name server:

[root@foo ~]# dig ata3ias.test.bajic.nl @ns-1695.awsdns-19.co.uk
...
;; ANSWER SECTION:
ata3ias.test.bajic.nl.  120     IN      A       127.0.0.5
;; WHEN: Thu Dec 29 12:43:13 2016

I will then change the IP address to 127.0.0.6 and query again:

[root@foo ~]# dig ata3ias.test.bajic.nl @ns-1695.awsdns-19.co.uk
...
;; ANSWER SECTION:
ata3ias.test.bajic.nl.  120     IN      A       127.0.0.6
;; WHEN: Thu Dec 29 12:43:22 2016

Next, I will query my company's internal DNS server (I can safely assume that no one before tried to resolved this address and there is no entry in DNS server's cache):

[root@foo ~]# dig ata3ias.test.bajic.nl @10.0.0.5
...
;; ANSWER SECTION:
ata3ias.test.bajic.nl.  119     IN      A       127.0.0.6
;; Query time: 26 msec
;; WHEN: Thu Dec 29 12:46:20 2016

Notice the TTL, and also notice the Query time: The caching server queried the authoritative DNS server, got the response with TTL and remembered that info.

Now, if I do it again:

[root@foo ~]# dig ata3ias.test.bajic.nl @10.0.0.5
...
;; ANSWER SECTION:
ata3ias.test.bajic.nl.  107     IN      A       127.0.0.6
;; Query time: 0 msec
;; WHEN: Thu Dec 29 12:46:32 2016

This answer is served from cache, you can see that by TTL (so not only the caching server will keep the data in cache for TTL time, it will also pass the information about remaining TTL to clients), and also you can see that it it took 0ms to reseolve the query (because there was no need to contact authoritative name server).

I will then go to AWS console to edit IP address once again and change it to 127.0.0.7. To confirm the change, I will again query the authoritative server directly:

[root@foo ~]# dig ata3ias.test.bajic.nl @ns-1695.awsdns-19.co.uk
;; ANSWER SECTION:
ata3ias.test.bajic.nl.  120     IN      A       127.0.0.7
;; WHEN: Thu Dec 29 12:47:10 2016

Now I will query internal DNS server again:

[root@foo ~]# dig ata3ias.test.bajic.nl @10.0.0.5
;; ANSWER SECTION:
ata3ias.test.bajic.nl.  63      IN      A       127.0.0.6
;; WHEN: Thu Dec 29 12:47:16 2016

It is still serving old data, and will do so for another 63 seconds. After a minute:

[root@foo ~]# dig ata3ias.test.bajic.nl @10.0.0.5
;; ANSWER SECTION:
ata3ias.test.bajic.nl.  3       IN      A       127.0.0.6
;; WHEN: Thu Dec 29 12:48:16 2016

And finally, few seconds later, internal DNS server will serve fresh information:

[root@foo ~]# dig ata3ias.test.bajic.nl @10.0.0.5
;; ANSWER SECTION:
ata3ias.test.bajic.nl.  119     IN      A       127.0.0.7
;; WHEN: Thu Dec 29 12:48:21 2016

2. Exactly.
3. In general, SOA TTL values are of concern only for syncing between primary and secondary (slave) name servers, so no, you don't need to set anything other than TTL for MX records. You can find detailed explanation of all SOA TTL records here
4. For well behaved servers, yes. For others, there is nothing you can do.