Ripe did some testing in 2017 that showed that most places (~94%) are doing the right thing. Somewhere around 6% of the DNS servers were either making the TTL last too long, or too short.
There's a downloadable zip file there where you could probably figure out who the offenders were. Ripe did say that it was a mix of both ISPs and Cloud providers.
Edit: There are also probably some corporate MITM type "content filtering" caches that are screwing things up too, by caching web pages longer than they should.
I think it's a fool's errand into bullying people into solving your operational woes. You pretty much only have one option for dealing with real life DNS.
* Design your system assuming a hostile environment and that propagation time is on the order of hours.
* Draw and document a hard line above which you consider it your user's problem; i.e. you start assuming the world has updated after 2 hours and any stragglers can just get errors.
I suppose you can call it bullying. I call it providing customers with additional information to help them decide whether a particular company is worth giving money to.
And it doesn't have to be an antagonistic interaction. I fully suspect that many if not most cases of TTL violations either a) have a good explanation or b) are unintentional and easily fixed. Let's open the dialog and start improving things.
I worked on dns gslb for a long stretch at Facebook^WMeta, and didn’t see an excess of bad actors. The vast majority of users follow our dns changes in an orderly fashion. Most delay sources to clients themselves.
I'm implementing my own domain seller targeted towards making domain names easy enough for the average person to use. I'd like to move towards a world where you can read the current authoritative TTL and guarantee the user everything will be updated within that time, rather than saying "Up to 48 hours".
The "up to 48 hours" is commonly used because that's the ttl of many things that matter. For instance, NS records for names in the .com zone have 48 hour ttls.
You can give better estimates to your users if you know the state you're transitioning from. For instance, a brand new .com domain would be 15 min negative ttl plus the .com zone file update frequency.
Well yeah nothing is 100% guaranteed. Including the 48 hour rule. Technically ISPs could set every TTL to take weeks. But I maintain we can make a lot of progress reducing the size of the long tail. Sometimes you have to work with broken systems, but why leave things broken that don't need to be? DNS TLL compliance can be improved one organization at a time.
There are other things you can't control. Like when NS records for a new domain show up in the servers for the TLD.
I suppose it's reasonable that you could provide a better estimate for new domains and transfers based on past experience and existing TTLs. But it will be an estimate. And the estimates would be individual or sub-group ones, like "estimate for a new .com domain" and "specific estimate for transfer of this domain", etc.
There's a lot of cool services that could be built on top of shorter/predictable TTLs. I'm on a mission to make domain names easy enough for the average person to use, and selling someone a product that can't be used for 48 hours is quite disappointing.
There's a downloadable zip file there where you could probably figure out who the offenders were. Ripe did say that it was a mix of both ISPs and Cloud providers.
https://labs.ripe.net/author/giovane_moura/dns-ttl-violation...
Edit: There are also probably some corporate MITM type "content filtering" caches that are screwing things up too, by caching web pages longer than they should.