Table of Contents
Content Error or Suggest an Edit
Notice a grammatical error or technical inaccuracy? Let us know; we will give you credit!
Warning
You’ve reached a draft 🤷♂️ and unfortunately, it’s a work in progress.
Introduction
This article will go into how DNS works and why DNS propagation is really just a means to have you wait for the DNS cache to expire. Hence, it’s an incorrect terminology.
First, How Does DNS Work?
Domain Registry vs Registrar
I think it’s important to make sure we explain some terminology that is sprinkled in this article.
A Domain Registry is the organization in charge of a TLD (top level domain) extension. An example would be .com, .net which is owned by Verisign.
A Domain Registrar is an organization that has a connection to a registry like Verisign and provides domain name registration services.
Root Name Servers
DNS starts with the root name servers, these are the backbone of the internet. They hold all the name servers for the various TLD registries (.com .net .ca and more). They rarely need to be updated unless a domain regsitry (.com .net .ca and more) changes their own TLD root name servers. You won’t need to worry about these servers, unless you’re troubleshooting an issue.
TLD Domain Registry Name Servers
The next step in the DNS path is domain registries or TLD’s (top-level domains). For example 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. Previously, they all happened at a timed interval. So the 24-48 hour propagation terminology started to be used here.
What’s DNS Propagation?
The term “DNS Propagation” was coined in the early days of domain name registration. It was used to describe the delay of changing your name servers at your registrar. A change would typically take effect at a specific time each day, versus right away or within a specific amount of time.
You’ll her it quite often when you’re speaking to a domain registrars support representatives. Typically if you mention you made a Name Server or DNS change, you’ll get the default “wait 48 hours for DNS propagation”.
It’s a scapegoat answer, propagation doesn’t really exists anymore. In reality, there are only a few holdouts still causing long DNS changes. Most of the time its extremely long cache configuration on recursive DNS resolvers or a registrar delaying changes due to system issues or an outage.
The problem starts with Domain Registrars
Domain Registrars and Nameserver Update Delay’s
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 a system/software issue might cause the change to never happen.
Verifying Domain Registrars are doing their job
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. The update should only take 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.
What about Recursive DNS Resolvers, what are those?
Your computer or internet device is trying to access google.com in a web browser. However, it doesn’t know what IP Address google.com points to. This is where a recursive DNS resolver can help answer this question. A recursive DNS resolver will track down what IP Address google.com resolves to. It will make a series of requests to find the authoritative DNS name server.
Sometimes a recursive DNS resolver doesn’t need to track down a request. It can pass the request off to another recursive DNS resolver or it might already have the answer cached.
How Recursive DNS Resovlers Work
When your computer or internet device tries to resolve a domain, it uses a set of DNS servers also now as recursive DNS resolvers. Typically these DNS servers are configurated using DHCP or entered manually if you’re a tech wizard or you have some sort of DNS malware 😈
These DNS resolvers are used to resolve domain names to IP Addresses, the librarian analogy works well here.
The recursor can be thought of as a librarian who is asked to go find a particular book somewhere in a library
DHCP and Recursive DNS Resolvers
When you connect to a network, wireless, wired or via mobile data. You’ll receive a set of DNS servers from DHCP. Generally speaking, your network DHCP server might be one of the following.
- An all in one home/small business wireless/router from Asus, DLink or another hardware vendor.
- An all in one wireless router provided by you ISP.
- If you’re on a corporate network, it might be from a Active Directory server, enterprise firewall or a software appliance/virtual machine that deals with DNS and DHCP.
- On mobile data, it’s similar to the above corporate network.
You’ll have some sort of DNS servers configured on your internet device to resolve domain names to IP’s.
What Recursive DNS Resolvers am I using?
Great question. It’s complicated, but I’ll try and break it down.
You can easily see the configured DNS servers for your internet connection on an internet device. This guide doesn’t specifically tell you how to do this. The DNS servers configured on are referenced by IP Addresses. They’re not name based due to the fact that they’re the very servers that will allow name based DNS resolution.
There are generally a couple different DNS resolver setups you need to be aware of.
- You’re using your ISP’s DNS servers.
- You’re using the local network DNS server, that then uses another set of DNS resolvers from the upstream ISP.
- You’re using a public DNS resolver.
Why is it important to know what Recursive DNS Resolvers you’re using?
It’s important to know what DNS resolvers you’re using when troubleshooting DNS issues. You need to know how you’re receiving an answer to your DNS resolution request. You need to know the librarians you’re using.
DNS Resolver Cache is the real culprit
The problem is that recursive DNS resolvers have a caching feature, and that’s where the problem really starts. A recursive DNS resolver will cache a DNS answer for a configured amount of time. ISP’s are the worst offenders, they typically cache some records up to 48 hours or even days at a time. This leads to waiting 24-48 hours for the cache to expire.
Double Cache – A Recursive DNS Resolver Nightmare
There are specific situations where you might find yourself in a double recursive DNS resolver situation. This is where the recursive DNS resolver you’re using is caching your requests but also using another recursive DNS resolver that is caching requests.
This is problematic, a recursive DNS resolver should be obtaining answers for DNS queries itself from authoritative DNS servers. Not using another recursive DNS resolver
Original Post
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 🙂
DNS Propagation is DNS cache or service issues
DNS is pretty straight forward, there is no propagation really. So just watch out if a support representative says to wait 24-48 hours for propagation. They might just be using it as a default line to close your request.
Awesome DNS Tools and Information
List of Free Public DNS Resolvers
If you’re using a mobile device, you can use something like the Cloudflare 1.1.1.1 app. These types of apps can change your DNS to a public resolver. Here’s a list of some public DNS resolvers.
CLI Commands
dig
Dig is probably my #1 go to for all DNS queries. Here are some great examples
Query
dig google.com @8.8.8.8
- nslookup
- dnstracer
Web Based Tools
DNS Articles
- Julia Evans on DNS and the term “DNS propigation” – https://jvns.ca/blog/2021/12/06/dns-doesn-t-propagate/
- Cloudflare “What is dns?” – https://www.cloudflare.com/en-ca/learning/dns/what-is-dns/
Changelog
- 12-09-2021 Formatting changes, more content and overall restructuring of the article.
Jordan Trask
With 20 years of experience in technology spanning Linux, Data Center Infrastructure, and related services and applications, Jordan consults with small, medium, and large organizations tackling technology problems and needs. With 10 years of experience in WordPress, he’s created Managing WP as a means of dumping his brain on the web.
Jordan operates LMT Solutions providing Technology Consulting Services and We Power WP for WordPress Care Plans and Support.
