Why does Let's Encrypt use a DNS-01 challenge instead of HTTP-01?

The DNS-01 challenge is required when issuing wildcard SSL certificates or when your servers are hidden behind firewalls and cannot accept inbound HTTP traffic on port 80. It proves domain ownership by requiring you to create a specific cryptographic TXT record in your DNS zone.

How long does it take for DNS TXT records to propagate globally?

Propagation time depends entirely on the Time-To-Live (TTL) value you configured on the previous record and your DNS hosting provider's architecture. If you set a low TTL of 60 seconds, changes usually propagate within one to two minutes.

What should I do if NS lookup returns NXDOMAIN for my challenge record?

An NXDOMAIN error means the record does not exist on the name server you queried. Check your DNS provider's control panel to ensure the record was created successfully, verify that you included the leading underscore in `_acme-challenge`, and confirm you are querying the correct authoritative name server.

Can I have multiple TXT records for _acme-challenge.example.com?

Yes. If you are renewing multiple subdomains or using multiple ACME clients simultaneously, your DNS zone may hold multiple TXT records under the same name. Let's Encrypt will iterate through them and match the specific token it generated for the current session.

Why does my local nslookup show the new record, but Let's Encrypt still fails?

This usually indicates a split-brain DNS issue or inconsistent synchronization across your authoritative name servers. If Let's Encrypt hits a secondary name server that has not yet received the zone update from your primary master server, validation will fail even if your local resolver sees the record.

Validate Lets Encrypt DNS Challenge with NS Lookup

Using an NS lookup is the most reliable way to troubleshoot and verify that your ACME client has successfully published the required TXT records for a Let's Encrypt DNS-01 challenge. When Let's Encrypt attempts to issue or renew a wildcard SSL certificate, it queries your authoritative name servers for a specific TXT record on _acme-challenge.example.com. If your public name servers do not return the exact token generated by your ACME client, the validation fails and your certificate issuance is blocked.

To check your DNS propagation instantly during troubleshooting, you can use the NS Lookup tool to query specific public name servers and confirm your records are live globally.

Understanding the Let's Encrypt DNS-01 Challenge

The DNS-01 challenge proves that you control the DNS records for your domain name. Unlike HTTP-01 challenges, which require a web server to be running and accessible on port 80, DNS-01 challenges rely entirely on your DNS configuration. This makes them essential for issuing wildcard certificates (e.g., *.example.com) and securing internal services that are not exposed to the public internet.

When you run an ACME client like Certbot, Lego, or Win-ACME, the client performs the following sequence:

Requests a certificate from Let's Encrypt.
Receives a unique cryptographic token.
Creates a TXT record named _acme-challenge.example.com containing a specific hash of that token.
Signals to Let's Encrypt that the challenge is ready for validation.

If Let's Encrypt queries your domain and receives an outdated record, a timeout, or a NXDOMAIN (Non-Existent Domain) error, the validation fails. This is where performing manual lookups becomes crucial.

Preparing Your Environment for DNS Verification

Before running any command-line tools, you need to know three pieces of information:

Your fully qualified domain name (FQDN), such as example.com or sub.example.com.
The exact name of the challenge record: _acme-challenge.example.com.
The IP addresses or hostnames of your authoritative name servers (e.g., ns1.example.net or public resolvers like Google's 8.8.8.8 and Cloudflare's 1.6.1.1).

Let's assume your domain uses documentation IP range examples and your DNS provider is hosting the following record:

Record Type: TXT
Name: _acme-challenge
Value: j9W1V_8Vx...xyz (the ACME validation token hash)
TTL: 60 seconds (recommended low TTL during issuance)

Step-by-Step Guide to Validating Records with NS Lookup and Dig

To ensure your DNS challenge is properly exposed to the world, you should query your authoritative name servers directly, bypassing local caching resolvers. Here is how to do it using standard command-line tools.

Step 1: Query Your Authoritative Name Server Directly

Using the dig utility on Linux or macOS, you can query your specific authoritative name server to bypass any intermediate caching.

dig @ns1.example.net _acme-challenge.example.com TXT

Sample Output:

;; Got answer:
;; -> HEADER opcode: QUERY,-NOERROR, ANSWER
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;;;	_acme-challenge.example.com.	IN	TXT

;; ANSWER SECTION:
_acme-challenge.example.com.	 60	IN	TXT	"j9W1V_8Vx...xyz"

If you see the exact token string returned in the answer section with the aa (Authoritative Answer) flag present, your DNS provider has successfully updated the record.

Step 2: Use Built-In NSLookup on Windows PowerShell

If you are operating on a Windows machine, use PowerShell to perform an interactive NS lookup. This is particularly helpful when managing certificates via Windows-based ACME clients.

nslookup
> set type=TXT
> server 8.8.8.8
> _acme-challenge.example.com

Sample Output:

Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:

_acme-challenge.example.com	TEXT = "j9W1V_8Vx...xyz"

Note that public resolvers like Google or Cloudflare may take a few seconds to reflect changes if your TTL is higher or if there is upstream caching.

Comparison of DNS Query Tools for SSL Validation

Tool	Primary Use Case	Best For	Caveats
dig	Advanced DNS debugging	Linux/macOS engineers	Not installed by default on Windows
nslookup	Quick checks & interactive queries	Cross-platform troubleshooting	Output formatting varies by OS
Online NS Lookup	Instant global propagation checks	Web-based verification	Requires internet access

Common Mistakes and How to Fix Them

Even experienced engineers occasionally stumble upon propagation quirks during automated certificate issuance. Here are the most frequent pitfalls:

1. Missing Underscore Prefix

Let's Encrypt strictly requires the record name to start with an underscore: _acme-challenge. Creating a record named acme-challenge without the leading underscore will cause immediate validation failure.

2. Appending the Root Domain Twice

When configuring a TXT record in your DNS provider's control panel, be careful with trailing dots. If you enter _acme-challenge.example.com.example.com, the lookup will fail. Most control panels automatically append your root domain, so entering just _acme-challenge is usually sufficient.

3. Aggressive DNS Caching (TTL Too High)

If you previously ran an issuance test with a 1-hour TTL (3600), your local resolvers and some global nodes will cache the old result (or lack thereof). Always lower your TTL to 60 seconds at least 15 minutes before initiating a Let's Encrypt DNS challenge.

4. Split-Brain DNS or Multi-Provider Mismatches

If your domain uses multiple DNS providers or secondary name servers that do not sync correctly, Let's Encrypt may hit a name server that lacks the TXT record. Always verify every authoritative name server listed in your SOA record.

Quick Checklist for Let's Encrypt DNS Challenges

Confirmed the ACME client has API access to your DNS provider.
Set the DNS record type strictly to TXT.
Verified the name is _acme-challenge.example.com (with the underscore).
Reduced the record TTL to 60 seconds prior to running the client.
Executed an NS lookup to confirm the token is visible on authoritative servers.
Resumed the ACME client command to complete validation and issue the certificate.

How to Use NS Lookups to Validate SSL Let's Encrypt DNS Challenges