Glad to see this.
One of my (stupid) pet peeves is people that say "You have to wait for the DNS to propogate".
DNS does not propogate.
What you're actually waiting for is the cache TTL to expire so those name-servers that have cached it have to query the real answer again, thus getting the newly pushed information.
Of course it appears exactly like it "takes time to propagate" which is why it's actually a pretty sound description of what's happening, and thus why it's a stupid pet peeve.
Pointless rant ends.
I respect and agree with your rant. CTO and Co-Founder of DNSFilter here.
When we get a complaint that our recursive servers are returning an 'old IP' as if we did something wrong... I start by explaining that they likely didn't properly lower their TTL prior to making a change.
Sadly we'll never win this battle; so at some point in the future we'll need to join the likes of google in providing a page to force cache expiration of domains at customers request :/
Oh! I always thought the TTL was the delay in "propagating" the DNS change, not an expiration time for lookups. Learn something new everyday... Good thing that's not my day job.
Don't forget negative caching. Windows famously fucks up here. A DNS look up these days is minute in the grand scheme of things and yet Windows still insists on caching a failed lookup for five minutes.
So you fire up cmd.exe and issue ifconfig /releasedns, ..., ipconfig /?, ipconfig /flushdns and then you go back to pinging the bloody address instead of using nslookup because you learned from another idle/jaded sysadmin to use ping as a shortcut to querying DNS, instead of actually querying what the DNS servers respond with.
Obviously, a better thing to do when checking your DNS entries is dig out ... dig.
DNS changes _do_ propagate: from the one you edited to the others via zone transfers and the like (primary to secondary etc) and thence to caching resolvers.
"Negative caching was an optional part of the DNS specification and deals with the caching of the non-existence of an RRset [RFC2181] or domain name."
Optional.
Now, I know how DNS works and so do you but your average sysadmin wants instant results as they thrash around trying to get something to work. You see the same effect with firewalls. If state tables don't get flushed after a change then the change will seem to be ineffective. Been there and done that. States often die after five minutes and so do Windows DNS fuck ups.
That is why the master says: "wait longer" followed by "turn it off and on again" or "go out and smoke a fag" or "get me a coffee" or whatever. When your arse is on fire in IT, learn when to trust your judgement and take five.
The most egregious case I've seen was an Amiga site. The site went down and for several days reported that users would need to wait for the updated records to propagate and lots of loyal fans were insisting anybody who couldn't read the site was just being too impatient.
What was actually wrong? They wrote their new IP address as a DNS name in their DNS configuration rather than as an IP address. Once they fixed that it began working and they acted as though that was just because now it had successfully propagated.
On the other hand propagation is a thing when it comes to distributing modified DNS records to multiple notionally authoritative DNS servers.
This can be a problem for using Let's Encrypt dns-01 challenges for example, especially with a third party DNS provider.
Suppose you write a TXT record to pass dns-01 and get a wildcard certificates for your domain example.com. You submit it to your provider's weird custom API and it says OK. Unfortunately when you do this all it really did was write the updated TXT record to a text file on an SFTP server. Each of the provider's say three authoritative DNS servers (mango, lime, kiwi) check this site every five minutes, download any updated files and begin serving the new answers.
Still they said OK, so you call Let's Encrypt and say you're ready to pass the challenge. Let's Encrypt calls authoritative server kiwi, which has never seen this TXT record and you fail the challenge.
So you check DNS - your cache infrastructure calls lime, which has updated and gives the correct answer, it seems like everything is fine, so you report a bug with Let's Encrypt. But nothing was wrong on their side.
Now, unlike typical "DNS propagation" myths the times for authoritative servers are usually minutes and can be only seconds for a sensible design (SFTP servers is not a sensible design) so you can just add a nice generous allowance of time and it'll usually work. But clearly the Right Thing™ is to have an API that actually confirms the authoritative servers are updated before returning OK.
> So you check DNS - your cache infrastructure calls lime, which has updated and gives the correct answer, it seems like everything is fine
Been there, done that, got burned. If you're mucking around with DNS records that are going to be verified by someone else, never trust your local lookups, always try to verify through a fresh third party that everything resolves correctly before you submit.
Because oops, something went wrong, the verification hit a wildcard entry with a cache time of days, and now you have to wait that long before trying again, because that entry isn't budging from other resolver's caches...
"Propagate" just means "spread". Your latest record certainly does "propagate" in that it displaces the previous version of the record in resolvers' caches.
People use it in the context of "I've made the change now the change has to be pushed out to everyone" but that's not true. Everyone else has to pull the change.
It's the idea that it spreads out slowly from the centre to the far reaches that annoys me - which is what most people seem to be suggesting when they refer to "DNS Propagating".
It's not one big push, it's millions of tiny pulls.
