[Support Guide] How to detect and fix inactive Netlify DNS zones

What is an “inactive Netlify DNS zone”?

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.

Are inactive DNS zones a problem?

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.

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.

How do I identify an inactive DNS zone?

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.

Check #1: Inactive DNS zone check using dig with +trace

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 217.70.187.81#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 nsone.net.)

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”.

Check #2: Inactive DNS zone check using WHOIS data

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.

Example of “active” Netlify DNS zones

So, what do these two commands look like when the DNS zone at Netlify is active?

Here is 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 198.51.45.70#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 (dns4.p06.nsone.net).

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”.

I have an inactive DNS zone at Netlify. How do I fix it?

There are two very different solutions:

  1. Delete the inactive DNS zone and use our external DNS instructions.

or:

  1. 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).

Solution #1: Delete the inactive DNS zone

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.

Solution #2: Activate the inactive DNS zone

IMPORTANT NOTE FOR SOLUTION #2

  • 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”.

Summary

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.

@luke Thanks for this. I was just reading how these inactive zones could become zombie domains for hackers.

However, I’m not getting the same returns for the dig and whois commands that you show. For example, using dig through CloudFlare Warp:

dig gregraven.org NS +trace | tail -n 6

.			518202	IN	NS	m.root-servers.net.
.			518202	IN	RRSIG	NS 8 0 518400 20200914050000 20200901040000 46594 . F5HUdJl/qlKwTD3NqSGV0GiqYG/YSnEJ/pB6VPRlnpN/7LuyuRkTEj/e 66OgIh5/KLRr3/8oixDgyvnZ4mtcEHZvVId9MhU0B1yWf1K6rwNE99q3 j/MmJcL6qG6q9TcNUAEHb8vgc9paBvYOMnXw2CkXzEBsldc5NxbaXMj6 st8N0/w0t9y/dDoFkwZvVQEeVivVS1wucqacL9yXNEhvf+ghJXj2wkiI 74/VWOilzA31lrOkL4MNntDCQSWy2oj/5VWutCY0Fqr+7054JNzbFNmG FW0Gq9pSAMqaTFfbGwBiEuN/UC2OxYMUBABqmwMFhvbFpGCCEj1CvGJs VwSLeQ==
;; Received 525 bytes from 192.0.2.2#53(192.0.2.2) in 5 ms

;; Received 31 bytes from 199.7.83.42#53(l.root-servers.net) in 5 ms

Using dig without CloudFlare Warp:

dig gregraven.org NS +trace | tail -n 6    

; <<>> DiG 9.10.6 <<>> gregraven.org NS +trace
;; global options: +cmd
;; Received 17 bytes from 192.168.254.254#53(192.168.254.254) in 1 ms

Using whois with or without CloudFlare Warp:

whois gregraven.org | grep -i "name server"
Name Server: DNS1.P08.NSONE.NET
Name Server: DNS2.P08.NSONE.NET
Name Server: DNS3.P08.NSONE.NET
Name Server: DNS4.P08.NSONE.NET
Name Server: dns1.p08.nsone.net
Name Server: dns2.p08.nsone.net
Name Server: dns3.p08.nsone.net
Name Server: dns4.p08.nsone.net

(Apparently, whois is returning information for both IPv4 and IPv6.)

This is in Terminal.app on macOS.

Finally, I read somewhere that whois results are not necessarily authoritative, whereas dig results are. What has been your experience?

For example:

whois karsavuran.com | grep -i "name server"

Name Server: DNS1.P08.NSONE.NET
Name Server: DNS2.P08.NSONE.NET
Name Server: DNS3.P08.NSONE.NET
Name Server: DNS4.P08.NSONE.NET
Name Server: dns1.p08.nsone.net
Name Server: dns2.p08.nsone.net
Name Server: dns3.p08.nsone.net
Name Server: dns4.p08.nsone.net

vs:

dig karsavuran.com -t NS

; <<>> DiG 9.10.6 <<>> karsavuran.com -t NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 43115
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;karsavuran.com.			IN	NS

;; Query time: 148 msec
;; SERVER: 192.0.2.2#53(192.0.2.2)
;; WHEN: Tue Sep 01 16:17:49 PDT 2020
;; MSG SIZE  rcvd: 43

Hi, @gregraven, I don’t show that IP address for the DNS server as being reachable: 192.0.2.2. I say that based on this RFC:

https://tools.ietf.org/html/rfc5737

When I run the traced lookup locally I get this:

$ dig gregraven.org NS +trace

; <<>> DiG 9.10.6 <<>> gregraven.org NS +trace
;; global options: +cmd
.			87044	IN	NS	m.root-servers.net.
.			87044	IN	NS	a.root-servers.net.
.			87044	IN	NS	e.root-servers.net.
.			87044	IN	NS	h.root-servers.net.
.			87044	IN	NS	i.root-servers.net.
.			87044	IN	NS	b.root-servers.net.
.			87044	IN	NS	k.root-servers.net.
.			87044	IN	NS	l.root-servers.net.
.			87044	IN	NS	c.root-servers.net.
.			87044	IN	NS	f.root-servers.net.
.			87044	IN	NS	d.root-servers.net.
.			87044	IN	NS	g.root-servers.net.
.			87044	IN	NS	j.root-servers.net.
.			87044	IN	RRSIG	NS 8 0 518400 20200914050000 20200901040000 46594 . F5HUdJl/qlKwTD3NqSGV0GiqYG/YSnEJ/pB6VPRlnpN/7LuyuRkTEj/e 66OgIh5/KLRr3/8oixDgyvnZ4mtcEHZvVId9MhU0B1yWf1K6rwNE99q3 j/MmJcL6qG6q9TcNUAEHb8vgc9paBvYOMnXw2CkXzEBsldc5NxbaXMj6 st8N0/w0t9y/dDoFkwZvVQEeVivVS1wucqacL9yXNEhvf+ghJXj2wkiI 74/VWOilzA31lrOkL4MNntDCQSWy2oj/5VWutCY0Fqr+7054JNzbFNmG FW0Gq9pSAMqaTFfbGwBiEuN/UC2OxYMUBABqmwMFhvbFpGCCEj1CvGJs VwSLeQ==
;; Received 525 bytes from 8.8.8.8#53(8.8.8.8) in 18 ms

org.			172800	IN	NS	c0.org.afilias-nst.info.
org.			172800	IN	NS	b0.org.afilias-nst.org.
org.			172800	IN	NS	a0.org.afilias-nst.info.
org.			172800	IN	NS	b2.org.afilias-nst.org.
org.			172800	IN	NS	a2.org.afilias-nst.info.
org.			172800	IN	NS	d0.org.afilias-nst.org.
org.			86400	IN	DS	17883 7 1 38C5CF93B369C7557E0515FAAA57060F1BFB12C1
org.			86400	IN	DS	17883 7 2 D889CAD790F01979E860D6627B58F85AB554E0E491FE06515F35548D 1EB4E6EE
org.			86400	IN	RRSIG	DS 8 1 86400 20200914170000 20200901160000 46594 . J4QKOBUO9a6ceDnRV+nQ1aIy8Kbl8h6IcmufMVFQztHTjkSzFcYbeHDe 3epRd00c6MVXIraBJ0wUHPRjyzBbRuGpN9GeYGdNqXWuqORyztvK43GP So6gPBxlmMS1XoiBkl5AEf48l6h0hB/55/vWrw2SOEF4ulLbF5BplBeW RUnJx3/ZuUxeUzIOkVfBaWIZCrhGeJ2b3aCA5RMFFiIaJgbAXtkKZzJi vXu/iInI5WBROqIVPuuv1YNA58OCkuy/+L6/ybJyTIWzh0RzdbR7+odD kbSe45IKFh6mrSVwJjR7+p1GUFlHFKZM7OnEHDxN+BY0lweZvjXfiHBz jbG2hw==
;; Received 815 bytes from 192.112.36.4#53(g.root-servers.net) in 74 ms

gregraven.org.		86400	IN	NS	dns1.p08.nsone.net.
gregraven.org.		86400	IN	NS	dns2.p08.nsone.net.
gregraven.org.		86400	IN	NS	dns3.p08.nsone.net.
gregraven.org.		86400	IN	NS	dns4.p08.nsone.net.
h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. 86400 IN NSEC3 1 1 1 D399EAAB H9P94CHNCUOADBOKM57JBRIMA2O6J0IQ  NS SOA RRSIG DNSKEY NSEC3PARAM
h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. 86400 IN RRSIG NSEC3 7 2 86400 20200923013438 20200902003438 22064 org. LqGNdoMpBQu/e+CEdz6aOyqn0ysqI7aqg5CdQi44W3e1O5lZfcPbhMSH WW+e2wMsKAleczGZkgatuKdB1bnoW17ZNPCmqP1Zqtyz7eHYn9HissJP 8EJWuvTVee9IeQ/YGUHZO7GWrMegMgHlaRFaRFb5O9MpGquIZAlFGTbC 2oE=
iv44dgl8m6b9l3cguobp139nto9nsva1.org. 86400 IN NSEC3 1 1 1 D399EAAB IV4BH10TC3H9IN03L9K6ABG9E0L1ORH4  NS DS RRSIG
iv44dgl8m6b9l3cguobp139nto9nsva1.org. 86400 IN RRSIG NSEC3 7 2 86400 20200922152330 20200901142330 22064 org. B6QVoKgqCqks9GrAf3mtGrcrZUVdSgP9Dwj3gc2HYkC7CHkZGoETzWzn QagrANNcGi7fuSa4u8/GskDomyRtGZpb0NoOjJu5Il06SU30FyzIurlA gVIsqVRiA1OG1/e5Szk96r1oD3hRzmlYEY/spOVnV438la+P03eGHkIE 9bU=
;; Received 624 bytes from 199.19.56.1#53(a0.org.afilias-nst.info) in 38 ms

gregraven.org.		3600	IN	NS	dns1.p08.nsone.net.
gregraven.org.		3600	IN	NS	dns2.p08.nsone.net.
gregraven.org.		3600	IN	NS	dns3.p08.nsone.net.
gregraven.org.		3600	IN	NS	dns4.p08.nsone.net.
;; Received 131 bytes from 198.51.44.72#53(dns3.p08.nsone.net) in 16 ms

I do agree that the WHOIS data isn’t authoritative. However, it is almost always up-to-date in my experience. Also, some people may find the WHOIS information easier to process than the recursive DNS query, so I included it for those reasons.

@Luke That’s why I chose that as an example. whois shows Netlify name servers for karsavuran.com, while dig shows it has no connection with any name server. Technically, whois is correct, but practically, dig is “more correct,” because while Netlify DNS has been assigned, the Netlify DNS doesn’t seem to know anything about this site.

dig @dns1.p08.nsone.net karsavuran.com -t NS

; <<>> DiG 9.10.6 <<>> @dns1.p08.nsone.net karsavuran.com -t NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46899
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;karsavuran.com.			IN	NS

;; Query time: 25 msec
;; SERVER: 198.51.44.8#53(198.51.44.8)
;; WHEN: Tue Sep 01 19:30:12 PDT 2020
;; MSG SIZE  rcvd: 43

Neither tells the full story, but dig at least shows that there seems to be a problem.

Hi, @gregraven, I actually used the WHOIS data to find the root cause:

$ whois karsavuran.com | grep "DNSSEC"
   DNSSEC: signedDelegation
   DNSSEC DS Data: 22516 13 1 0F6A49630B319010F6A91FC6DA08A685049E521E
DNSSEC: signedDelegation

The DNS lookup is failing because DNSSEC is enabled for this domain and our DNS service doesn’t support DNSSEC. This means that all DNS queries will fail unless DNSSEC is disabled or the DNS service for this domain is moved to a different service that does support DNSSEC.

@luke Ah ha! I’ll have to be on the lookout for that one in the future.

A post was split to a new topic: Questions about Netlify DNS configuration