Why DNS Propagation is mis-understood and abused by support representives.

Why DNS Propagation is mis-understood and abused by support representives.

DNS Propagation is a deadly term to use. Especially when you're speaking to support representatives. Typically if you mention you made a Name Server or DNS zone change, you'll get the default "wait 48 hours for DNS propagation".

It's a scapegoat answer, propagation exists but it's extremely fast these days. There are only a few holdouts still causing long DNS propagation to occur.

DNS starts with the root name servers, these are the backbone of the internet. They rarely need to be update unless a domain register (.com .net) changes their own root name servers. You won't need to worry about this much if you're just changing your name servers or a DNS record on your domain.

The next step in the DNS path is domain registries or TLD's (top-level domains). This would be .net and .com which is handled by Verisign. When you got to your registrar (Godaddy) and update your name servers, GoDaddy is responsible to push the change to Verisign. Now Verisign made a change in 2004 to ensure that changes to name servers is less than 5 minutes.

This is where problems start to occur, at the registrar. Typically most registrars will send the command to the registry to update the name servers on a domain right away. However some don't, some delay these changes and only process them every 30 minutes. Then you have domain resellers who have API access to the domain registrars (GoDaddy), and they might delay the change or it might never happen. But how do you know if your domain registrar even sent the update correctly? Unless the domain registry (.com .net aka Verisign) is having issues it should be within 5 minutes. You can confirm this by doing a DNS trace on just the root name servers. You can do this within linux easily using the command dnstracer, here's a web version. https://www.digwebinterface.com/?hostnames=facebook.com&type=NS&trace=on&norecursive=on&useresolver=8.8.4.4&ns=nic&nameservers=

The link above has the settings I picked embedded in the URL. Basically it's going to use a root name server to pull all the registry's root name servers (*.gtld-servers.net) and return the NS records for the domain facebook.com If you see that the NS records aren't changed, then your registrar (Godaddy) didn't submit the request or it was delayed.

It's straight forward, there is no propagation that is going to take 48 hours.⁠ So just watch out if a support representative says to wait 48 hours. They might just be using it as a default line. But it doesn't end here. It gets worse. The next step in the chain involves DNS resolvers and TTL settings.

When you computer tries to resolve a domain, it uses the DNS servers that it was configured with. Typically via DHCP or entered manually if you're a wizard ;) Majority of the world just uses the DNS servers from DHCP which can be either the ISP's or their router.

Both of which become a DNS "resolver". Essentially going out and finding out where a domain name resolves to. The problem is that these resolvers have a caching feature, and that's where the problem really starts. ISP's are the worst as they typically cache some records up to 48 hours, as for routers its pretty much brand and model dependant. Now when you go and change the DNS record for your website to point to a new IP. You've made a change that is going to be affected by DNS resolver caching. This can be mitigated by setting a really low TTL (time to live or cache) on the DNS zone (your domain has a DNS zone) SOA (Start of Authority). An SOA basically states that the DNS server is authoritative for the DNS zone in question. Rarely is this available unless you run your own server or have a great managed DNS provider. This will tell the DNS "resolvers" to not cache your DNS zone for a super long time. Typically the default is 1 hour, however some DNS resolvers ignore and cache for longer.

Then there is the individual DNS record TTL (time to live or cache) that you can also configure. Cloudflare allows you to do this. Both the DNS zone TTL and DNS record work together. If the DNS Zone TTL is super high, the DNS record TTL will never come into play.

For instance facebook.com has a DNS Zone SOA TTL of 300 seconds, and the facebook.com A record (what you punch into your browser) is set to 300 seconds.

If Facebook makes a change, all the DNS resolvers in the world need to make sure they abide by the TTL. However some don't and just hold onto the records for longer than they should, essentially caching them.

So what should you be looking for? Make sure your name servers are on the registries root name servers (.net .com Verisign) and ensure your TTL's are low. If all else fails, simply change your DNS or your customers to Google's DNS resolver (8.8.8.8) and then request a purge of the DNS record that is cached and causing you trouble. You can do this at this URL. https://developers.google.com/speed/public-dns/cache Typically you should be able to make DNS changes and have them go live within minutes. It's really ISP's, DNS resolvers, and super high TTL's that cause the 48 hour propagation. So next time someone says wait 48 hours for propagation, double check that it's true or change your DNS resolver :)

Posted by Jordan