Vercel argue that changing our CNAME to their domain is instant. But there is a Time To Live (TTL) of at least 5 minutes..... Am I missing something, or are they wrong?
Both can be true at the same time. Your authoritative data changes instantly, but the world's "view" of it will be cached for up to (not "at least") 5 minutes, varying by location, e.g. anyone who doesn't have the old data cached will "see" the new data instantly (and someone who already had the old data cached for 3 minutes will notice your changes after 2 more minutes).
The delay isn't a problem if both the "old" and "new" destinations are kept valid during the transition – if the web servers are the same (or at least host the same website) then users won't care or notice. So just don't shut down the old server until you're sure that the TTL has passed and the changes have "propagated".
I used to run a DNS server (named on Solaris) when I worked for the University, our DNS server was allowed to be authoritative for our faculty, and we could apply for more IPs from a pool given to our faculty by the central IT services. I assumed they were granted their pool from another regulated body which assigns IPs for the country, and they in turn get it from an international body (in America?).
IP address assignment is not regulated at country level (like telephone numbers would be). Instead, the university receives its addresses from one of the regional registries – RIRs – in your case ARIN for North America, whereas e.g. RIPE handles the entirety of Europe.
(But this is not strict; IP routing is dynamic – the actual routes are not based on any sort of country code nor even region code – and any address prefix can be announced from anywhere.)
So the hierarchy is:
IANA is not fully an international body, but it is the "root" organization which assigns IP address ranges (prefixes) to these RIRs.
Companies (or individuals who don't mind the fee) can then become members of their local RIR (or be "sponsored" by an existing member) to receive 'resources'. Most ISPs of course do that, as do CDN operators.
A smaller university or company will typically just have some IP addresses sub-assigned as part of an ISP's larger allocation, but one with a large internal network might certainly become a RIR member directly and fully own its IP prefixes.
And if the organization has a History, then it might still have "legacy" assignments directly from IANA, perhaps even back when that was called "SRI-NIC". You can still see a few of those in the above IANA registry: Apple, DoD, Ford. MIT also had the whole 18.0.0.0/8 directly at IANA level until they sold half of it to Amazon AWS just a few years ago.
(The Internet is a bit short on IPv4 addresses – and the 'cloud' companies gobble up anything that's still left – so a whole /9 would have sold for some serious money. Likewise Xerox also sold large chunks of its legacy 13/8 allocation to AWS, then AMPRnet sold a quarter of 44/8 to AWS, and GE sold its entire 3/8 to – as you might have guessed – AWS.)
When I made DNS changes, say for our site, I would update the forward and backward resolution files to link the domain name with ONE IP address, and then update the serial number on the configuration which told the DNS servers at central that a change had been made. The central DNS servers would then update their DNS, and thus the change would propagate around the world. It would take around 24-48 hours for the change be synchronized everywhere.
DNS, in general, doesn't work that way.
Your changes only propagate across your own set of authoritative nameservers. The replication interval used to be set by the SOA 'refresh' interval (or Active Directory replication delay), nowadays usually near-instant due to push notify.
Beyond your authoritative servers, the changes do not 'propagate' nor 'synchronize' anywhere at all. DNS information is pulled on demand by resolvers that were asked about it, on an individual subdomain basis (not whole zone), then cached for a certain amount of time – which is set by you through each record's TTL field.
Once the TTL of the cache entry expires, that resolver forgets it, and the next time it is asked about that specific name it has to pull the data from your authoritative servers again. So if you had a TTL of, say, 2 hours on the old DNS record, then all resolvers will forget the old data and therefore will "see" the change after a maximum of 2 hours (if they had the old record already cached in the first place).
This also means that resolvers which did not have the old record already cached, will see your new record immediately regardless of the previous TTL, meaning that the change is simultaneously instant and not, depending on who you ask.
It's possible that "back in the day" your domain's authoritative servers had a really long refresh interval (I wouldn't be surprised if some places had a 24h refresh, maybe even a manual cron job rather than standard AXFR for some reason – I know djbdns likes its cron and rsync).
But each domain's operator chooses their own DNS software, and therefore their own replication strategy. For example, if your DNS server uses traditional AXFR pull replication, you can freely set your SOA 'REFRESH' field to something like 1 hour or just 15 minutes. And typically, as soon as you increment the zone serial, your DNS master server will send 'NOTIFY' messages to all secondaries (replicas) to trigger an immediate retransfer.
(A domain can also get near-instant replication with e.g. DNS servers backed by Active Directory with its own replication abilities, or DNS servers backed by a Postgresql cluster or MongoDB cluster or whatever. Large CDNs are more likely to use some sort of database, not a collection of zone files.)
All of this practically means that "24-48 hours" is a commonly copied/pasted lie. Although DNS changes are not exactly instant, you can very well keep a TTL of 30 seconds to have your changes become visible after maybe a minute (authoritative server replication delay + query results cached at the worst moment).
The one significant place where "24-48 hours" is certainly true is the .com/.org/.net registry, which uses a 48-hour TTL for the published NS records, so any changes to your domain's nameservers can take up to 2 days due to caching alone (not including registrar delays).
I have done work with AWS and other SAAS companies that provide Content Delivery Services such as CloudFront, which have different servers around the world, and the DNS for these servers return a different IP according to where the request is coming from. This must mean that there is a configuration where for certain IP addresses, the authoritative servers are limited by region, but nevertheless, I would have thought changes would not be instant, and they would have to propagate as I described above.
There are a few separate points regarding this:
The DNS replies may be dynamic.
As mentioned above, DNS data does not actually "propagate" or "synchronize" outside of your own authoritative DNS servers.
This means that your DNS servers can freely decide how to answer each individual query – that's why they're authoritative – and they are not limited to purely loading static information from a zone file or a database. You can have a DNS server that generates the responses using any code you like.
This allows for "GeoDNS", where the authoritative servers look at which IP address the query comes from, decide roughly where it is (e.g. using Maxmind's GeoIP database), and return one of several alternative sets of region-specific DNS records.
The DNS server might even select which specific IP addresses to return based on live metrics of server load. I think I've seen load balancers which have a built-in DNS server for that exact purpose. (I've definitely seen IRC servers which act as their own authoritative DNS server to dynamically return a list of addresses for all 'currently online' chat servers.)
The authoritative servers may be anycast.
As mentioned before, IP routing is dynamic; the BGP protocol is used to announce routes worldwide. So unlike phone numbers (where routes would be aggregated e.g. to one route per country prefix), IP routes are generally not aggregated beyond what the network itself announces through BGP. If my network announces an IPv4 /24 then you on the other side of the pond are still going to see the same route for just that /24.
This means that, regardless of the regional registries, there is no limitation as to how and where an IP route may be announced from. Packets will go towards literally wherever you've set up the BGP session with some upstream ISP and announced the prefix.
A large network may have connections to multiple ISPs, and potentially even at different physical locations, all announcing the same route. Packets will generally take the 'closest' path (subject to a lot of asterisks and footnotes).
For example, if a given CDN's or ISP's network has peerings on both the East and West coasts, then they might announce the same prefix from both places, and your packets will generally travel to the entry point that is closest to you. You send a packet from California, it enters the company's network at Equinix Los Angeles; you send a packet from Ohio, it enters the company's network at Equinix Ashburn; you send a packet from Paris, it enters the company's network at DE-CIX Frankfurt. (I hope I got the USA map right.)
But once the packet "enters the target network", it doesn't necessarily have to go to the same place; the network's operator decides where it goes. So there might be two different instances of a DNS server with the exact same IP address, naturally becoming "region limited" as packets will always be routed to the nearest instance. This is completely invisible to the user.
The big public DNS resolvers like 1.1.1.1 or 8.8.8.8 work this way, as do the authoritative DNS servers for the DNS root zone and many TLDs, and plenty of companies (e.g. the same CDNs) offer anycast authoritative DNS service for regular domains. (For example, if I do dig +nsid example.com @8.8.8.8 it shows that I'm talking to the Frankfurt instance, while dig id.server txt ch @1.1.1.1 shows the Vilnius instance.)
So even the "same" caching resolver will have different kinds of data cached around the world. My closest instance of 8.8.8.8 may still have an old record cached while your nearest instance of 8.8.8.8 may already report the new data.
This also extends to GeoDNS – your instance of 8.8.8.8 will query its nearest copy of Vercel's authoritative servers and will get a GeoIP reply appropriate for your region, while my instance of 8.8.8.8 (having a fully separate cache) will receive a GeoDNS answer for my region.
(In fact, even though 8.8.8.8 isn't that close to me, it will report "This query is coming from this approximate IP prefix" to Vercel – DNS extension 'EDNS Client Subnet' – so that Vercel could choose a more suitable GeoDNS response for my location rather than the resolver's.)
Vercel argue that changing our CNAME to their domain is instant. But there is a Time To Live (TTL) of at least 5 minutes..... Am I missing something, or are they wrong?Surely they can demonstrate this to you with a test domain?