First, it would help to define the term “DNS zone”. Quoting wikipedia, it says:
A DNS zone is any distinct, contiguous portion of the domain name space in the Domain Name System (DNS) for which administrative responsibility has been delegated to a single manager.
To paraphrase, a DNS zone is a collection of all the DNS records for a custom domain. When you add custom domains to Netlify DNS we create a DNS zone which stores all the DNS records for that custom domain at Netlify.
So what is an “inactive Netlify DNS zone”? It is a DNS zone created at Netlify but not currently being used.
Actually, yes, inactive DNS zones with our DNS service do cause problems. The most common issue they cause is that our service will be unable to create or update the automatic Let’s Encrypt SSL certificates for this custom domain. This can affect any updates for the Let’s Encrypt SSL certificates our service provisions, including updates for branch subdomains.
Why does the inactive DNS zone cause this? Because there are two methods to do verification with Let’s Encrypt: a) HTTP based verification and b) DNS based verification.
If you create a Netlify DNS zone for a custom domain, our service will try to verify the SSL certificate using DNS based verification. However, if the DNS zone is inactive, the DNS based verification will always fail (until the issue is fixed).
SSL certificate provisioning failures are the most common issues inactive DNS zones cause.
First, check to see if you have a DNS zone for this custom domain on your Netlify account. This can be found under Account Name > Domains or by using the URL below (while logged in):
This will tell you if the DNS zone exists at Netlify. Do you see your custom domain listed on that page above? If the answer is “yes”, then you have a Netlify DNS zone for this custom domain.
Next, we need to see if that DNS zone is active or not.
For this next check I’m going to use the command line tool
dig. You can install
dig on almost any operating system and I highly recommend it if you are troubleshooting DNS issues.
I’m using the
+trace option below to do a recursive lookup of the DNS name server (NS) records for this domain. I truncated the response with
tail as only the last few lines matter for this check:
$ dig of-mu.org NS +trace | tail -n 6 of-mu.org. 1800 IN NS dns1.p07.nsone.net. of-mu.org. 1800 IN NS dns2.p07.nsone.net. of-mu.org. 1800 IN NS dns3.p07.nsone.net. of-mu.org. 1800 IN NS dns4.p07.nsone.net. ;; Received 127 bytes from 184.108.40.206#53(ns-80-c.gandi.net) in 171 ms
The line to examine is the last line with “;; Received 127 bytes from”. This line shows which name server that answered this query last.
What does the answer above show? It shows that the Netlify DNS name server record (NS records) did get sent. However, the “Received from” line shows that those name servers were not the name servers that answered for this custom domain. (Please note, that Netlify using the DNS services of NS1 for our DNS infrastructure which is why the answers all contain
The key here is to note that while the NS records above are for name servers used by Netlify DNS (the
nsone.net NS records) the answer above didn’t come from those name servers. The answer came from
ns-80-c.gandi.net. This is the name server for the domain registrar.
The registrar’s DNS name server answered this request. That name server (
ns-80-c.gandi.net) knows about the other name servers and returned their records. However, with this configuration, those other name servers are not being used. This means the DNS zone at Netlify is “inactive”. It exists but it won’t ever be used unless something is changed.
To summarize this check, if you run a traced DNS lookup (using
dig +trace) and the answer isn’t received from the Netlify DNS name servers, this proves the DNS zone at Netlify is “inactive”.
The next check method uses the WHOIS data for the custom domain.
If you have the command line utility called
whois installed, that can be used to check the WHOIS data. (There are also web based WHOIS tools, for example here.)
Below I have used
whois to check the name servers for this custom domain (and I also used
grep to filter that output for just the name servers):
$ whois of-mu.org | grep -i "name server" Name Server: NS-80-C.GANDI.NET Name Server: NS-146-B.GANDI.NET Name Server: NS-76-A.GANDI.NET
As you can see it shows the authoritative name servers for the custom domain. Those name servers are not the same as the Netlify DNS name servers. This also proves that the DNS zone at Netlify is “inactive”. It exists but it is not being used.
So, what do these two commands look like when the DNS zone at Netlify is active?
dig +trace output showing an active Netlify DNS zone:
$ dig mufu.io NS +trace | tail -n 6 mufu.io. 3600 IN NS dns1.p06.nsone.net. mufu.io. 3600 IN NS dns2.p06.nsone.net. mufu.io. 3600 IN NS dns3.p06.nsone.net. mufu.io. 3600 IN NS dns4.p06.nsone.net. ;; Received 125 bytes from 220.127.116.11#53(dns4.p06.nsone.net) in 19 ms
In this case, the Netlify DNS name servers were returned and the answer came from one of those name servers (
Here is the WHOIS data for that custom domain:
$ whois mufu.io | grep -i "name server" Name Server: DNS1.P06.NSONE.NET Name Server: DNS2.P06.NSONE.NET Name Server: DNS3.P06.NSONE.NET Name Server: DNS4.P06.NSONE.NET
Again, the WHOIS data shows the Netlify DNS name servers because this custom domain’s Netlify DNS zone is “active”.
There are two very different solutions:
- Delete the inactive DNS zone and use our external DNS instructions.
- Activate the inactive DNS zone.
These solutions are either/or. You may be wondering which you should use.
If the DNS already points to Netlify and the site works but SSL doesn’t then I would try deleting the inactive zone first (solution #1). I recommend that solution first because it will have no impact to your current DNS configuration (because what is being deleted is inactive).
Using Netlify DNS does enable features like automatic SSL for branch subdomains. However, using Netlify DNS isn’t the only way to point a custom domain to a Netlify site.
You can also use the external DNS instructions and not use Netlify DNS at all.
If that is your preferred solution, simply navigate the the DNS zone page for the custom domain at Netlify and use the “Delete DNS zone” at the bottom of the page to delete the zone.
Once this is done, the SSL certificate provisioning should be successful (as long as the external DNS instructions were followed). If it isn’t successful please create a new topic in #Netlify-support and let us know about it.
- Before activating the Netlify DNS zone, please be sure to transfer all the required DNS records to Netlify (this must be done manually). There is more about copying all required DNS records here.
The other solution is to activate the Netlify DNS zone. To do this, you will need to replace the current authoritative name servers with the ones for Netlify DNS.
How to do this varies from one domain registrar to the next. For example, with Gandi, the instructions can be found here:
For AWS Route 53, the instructions are here:
For GoDaddy, the instructions can be found here:
You should be able to find similar instructions for your domain registrar by making a web search for your registrar’s name plus “change name servers”.
An inactive DNS zone in Netlify DNS will prevent SSL certificates from being provisioned and/or updated for a custom domain. The solution for this will be to either 1) delete the inactive DNS zone at Netlify or 2) change the name servers at the registrar to make the inactive zone active.
If there are questions/comments about this support guide, please add those comments below.
However, if you want to troubleshoot your DNS/SSL for a specific custom domain please create a new topic in #Netlify-support stating the custom domain which isn’t working and our support team will follow-up with you there.