On Mon, 14 Mar 2022 at 19:36, B D dzidek23@gmail.com wrote:
TTL will force clients to update the dns record, but it isn't going to change the speed at which the DNS to DNS communication works.
It's the DNS to DNS bit that I'm not clear on.
Suppose a client is sat behind a router that uses Google's 8.8.8.8 DNS, and assume host1.example.com has just been added to the DNS (it never existed before and nothing has ever requested it before) with a TTL of 1hr.
The way I (possibly wrongly) understood it, at this point neither the router's DNS nor Google know anything about host1.example.com, and that remains the case until the client requests it in their web browser. Their router doesn't know so it asks Google, Google doesn't know so it asks the authoritative DNS, that does know and sens back an IP address with a TTL of 1hr. Google stores it, makes a note not to ask again for 1hr, and passes it to the client's router, which again caches it for an hour and passes it on to the client's browser, which might well cache it until the browser or PC is restarted.
In this scenario, any change to host1.example.com will not be visible to anyone else who uses Google's DNS until that hour is up, after which the next request for host1.example.com will trigger a fresh authoritative lookup. (And some DNS servers might not honour the 1hr TTL, and browsers are laws unto themselves.) But in principle this is where propagation delay comes from, *as I understand it - and I might be wrong*.
The key here, if I understand correctly, is that when host1.example.com is added to DNS it isn't published to Google (and all the other DNS servers); it just sits there until something asks for it that either doesn't already know the answer, or does but the cached answer has expired.
So if I update the domain to use a new DNS server, then provided I get records into the DNS before anything asks for them, then any requests will either be served from the cache values from the old server until they expire, or from the new server after that; the chance of asking the new server before the records are present can be made vanishingly small if the delay between switching DNS and adding the records is small enough.
HOWEVER: What I seem to be being told is that it doesn't work this way and that whether or not there are queries against the new DNS before it has records added, there will be a propagation delay. If this is correct then my understanding above is wrong.
(One potential issue would be if the new DNS didn't update immediately with new records, perhaps only showing them after an hourly database reload. But from some quick tests using dig @<authoritative DNS> they seem to be available from the authoritative DNS immediately they're added.)