How does DynamicDNS act immediately?

Question

My understanding of the core functionality of DNS is to provide a naming/mapping service between domain names (e.g. blah-whatever.com) and IP addresses (e.g. 100.2.3.4).

Furthermore, my understanding of how Internet DNS servers work is that when a domain/IP mapping record is changed (say, changing blah-whatever.com to now point to 105.2.3.4, etc.), this change needs to be propagated over every DNS server in the world before the change can be said to be "complete". This propagation period can sometimes last up to 24 hours.

So to begin with, if anything I have said so far is misguided or incorrect, please begin by correcting me!

Assuming I'm more or less correct, I don't understand how companies like CloudFlare or DynamicDNS can offer "instant rollover"-type services whereby you change your DNS record with them and - boom - the change takes affect instantly.

I understand there is something called "TTL" (time to live, I presume ?!?) that plays a role in this instant rollover capability, but since I'm already fuzzy on the capability to begin with it's hard to make sense of what this TTL is or what purpose it serves.

So I ask: what is it about Dynamic DNS and its competitors that allows them to change DNS mappings instantly (without taking 24 hours to propagate DNS changes like everybody else), and how does TTL fit into this process? Thanks in advance.

Solution 1

My previous answer contained false information because I had a few misconceptions regarding how DNS changes are propagated. So here is a second attempt. For a detailed explanation, I encourage you to read Alex answer.

To my understanding, there are 2 factors involved in how quickly a DNS change propagates:

1. Zone transfers between the DNS servers that are authorative for a zone.
2. The TTL set for single records in that zone.

Zone Transfers

Given that you need two distinct name servers to manage a zone, you'd want these servers to quickly have the latest version of that zone available to them.

This is either achieved by pulling the latest version of the zone at a fixed interval, or waiting for a NOTIFY from an authorized name server.

Given that this mechanism is under complete control of whoever runs the name servers, any delays in this area can be fully controlled.

TTL

The TTL is a timeout specified for every single resource record in a zone. This value defines how long the record should be cached by non-authorative DNS providers.

Please keep in mind that this value only comes into play if an existing record is changed. New records can't be cached yet.

Given that the TTL is also under full control of whoever controls the zone, the delay can also be fully controlled.

Solution 2

You have some misconceptions, so I'll try to explain the whole process. (I'm good with the details since I involved in operating a public dynamic DNS service).

Let's say your domain is example.com, and let's say example.com domain hosted with some dynamic DNS company, let's call it lightfastdns.net (fictional name). Your domain contains DNS record - somehost.example.com, which currently points to 1.1.1.1.

1. When you make a change to your DNS record, this change is first submitted to some intermediate server, operated by lightfastdns.net, e.g. updates.lightfastdns.net. This happens almost instantly (in fraction of second). You can submit your update via web interface or with a dynamic updates client, or via some API. That doesn't matters, in any case this update will arrive on some server which handles DNS updates.

2. This updates server pushes your updated record (let's say, 1.2.3.4) to "master" DNS server for your domain. This DNS server is also operated by lightfastdns.net. How fast that happens: depends on how DNS provider designed their software. (It can be instantly, and can be every 24 hours. For example gandi.net push DNS updates once per hour.) Of course, our lightfastdns.net will do it instantly.

3. This master DNS server will push updates to slave DNS servers for example.com domain. This servers are also operated by the same lightfastdns.net company. How fast this happens: with modern software master will instantly send NOTIFY message to the slaves, and they will instantly get the updated record from the master. with older software we had REFRESH and RETRY values in the SOA record, but today it's rarely relevant. Of course, our lightfastdns.net implements NOTIFY and updates propagate instantly.

What we have now is that all "authoritative" servers for your domain received the updated record (1.2.3.4). For lightfastdns.net it took about two seconds.

1. Now, we will move to Ivan's home at Russia, and Ivan wants to open "somehost.example.com" in his browser. If he never opened that before, his browser does not knows the address, so browser will ask his operating system . But, if he visited the site recently, the address may still be stored inside the browser, and he will use the old (obsolete) address ! For how long ? - Depends on browser, Google Chrome for example stores DNS records only for up to 60 seconds. We have up to 60 seconds delay. for this fact, I'd say that DNS change did not propagate to this browser yet.

2. In any case, after 60 seconds, or immediately, browser will eventually ask operating system to get the address. Operating system may already know the (old, obsolete) answer, and return it, in this case I'd say that the new record did not propagated yet to Ivan's OS. How long OS will store the old value - fow modern operating systems this controlled by TTL parameter. TTL in DNS defines how long a record may be stored in cache. Our lightfastdns.net allowed to use quite low TTL - 30 seconds, so we got a new delay of up to 30 seconds, overall - 90 seconds so far.

3. If OS does not know the answer, or if the answer it knew is now outdated by TTL, OS will ask DNS resolver (Ivan's ISP assigned him with a DNS resolver dns.moscow-telecom.ru). Here to, old record may be cached up to TTL seconds, or dns.moscow-telecom.ru may not know the address. We get another 30 seconds, as dns.moscow-telecom.ru also caches DNS for no longer than TTL value. We have 120 seconds delay. That is what called that the new DNS record did not propagated yet to Moscow-Telecom's DNS servers.

4. If ISP's DNS server does not know the answer, or if the answer it knew is already obsolete because it's TTL expired - dns.moscow-telecom.ru will ask one of AUTHORITATIVE DNS servers for example.net (do you remember them ?). Those got the change about 118 seconds ago, and they will return the new answer, this answer will be immediately sent by chain to DNS resolver, to OS, and to Ivan's browser.

Thus, propagating the record took from 2 to 120 seconds, depending on the state of various caches. Longer TTL - longer delays may take place.

To make it complete - some ISPs violate the standards and cache records for long time. Some older OSes kept old record for long time, and older browsers too. But for most users it will works as expected.

Solution 3

No. The change does not need to propagate to every DNS server in the world.

If you change something and someone queries the changed record on your DNS server the result is instantaneous.

The problem is if you queried this name before and it got cached. Then you will get the old IP until the cache expires. In DNS you can set how long an old query is valid, and that period is often set to several days. For DynDNS it is typically set lower, but not all DNS resolvers honour that.

Comments

[pnongrata]

Thanks @Oliver (+1) - So it sounds like an "instant rollover" is an urban legend! I guess my followup question would be: why not just edit my DNS records myself? Is it because these companies offer APIs so that DNS changes can be automated when certain events trigger? I guess I'm searching for what purpose they serve in the first place!

[pnongrata]

Thanks @Hennes (+1) - please see my question under Oliver's answer - I have the same question for you!

[Oliver Salzburg]

@zharvey: You can, of course, run your own DNS server and edit your zones directly yourself. But you need to provide at least 2 distinct DNS servers that are authorative for your zone to be accepted by the root servers. People usually don't have that kind of infrastructure available to them.

[ganesh]

You can edit DNS records yourself. You just need to run a pair of name servers (in different subnets). DynDNS however does that work for you and allows for relative easy updates. Basically you are outsourcing some work.

[Izzy]

@zharvey of course you can have an "instant rollover". If you mean that literally, just let both machines switch their IPs (which is not always possible). Other than that, you will always have a certain delay. Usually, if services are to be moved to different servers, the admin change the TTL in advance (e.g. lower it to something like 1h) -- so when the change takes place, the delay will be minimal. After it's done, TTL will be increased again (to e.g. 24h or more) to allow for better caching and faster responses on DNS queries. But that usually does not involve DynDNS ;)

[Alex]

Sorry for being rude, but this answer is wrong by almost every point.

[Oliver Salzburg]

@Alex: Would you care to elaborate on that claim?

[Alex]

I'm very sorry that it came out this verbose. Maybe someone wants to make a shorter variant (as a separate answer) - you are welcome.

[Alex]

@zharvey Actually you asked what is the difference between dynamic and not dynamic - it's 1. How fast they handle steps (2) and (3) and 2. How low TTL they permit you to set.

[Alex]

@OliverSalzburg 1. NOTIFY support is under complete control of DNS provider, 2. Values in SOA record are not TTL, 3. Refresh support is under complete control of DNS provider, 4. Presence of NOTIFY makes those SOA values irrelevant to update process 5. Low TTLs are usually respected as that is what standards demand to do.

[Oliver Salzburg]

@Alex: I guess my answer could be improved. It should be more clear what I'm trying to say and if there are any mistakes, I'd like to resolve them. However, I feel like some of your criticism is unwarranted. I'd be happy if you'd join me in Super User Chat to help me work out the mistakes in my answer :)

[Oliver Salzburg]

@zharvey It has come to my attention that my answer is, indeed, incorrect. Please do me the favor and review the other answers so that you can pick a proper solution and I can remove this misinformation. Thanks :)