8

I want to create wildcard SSL for my website via LetsEncrypt. I followed the instruction and after running Certbot, it gives me a DNS challenge and says:

Please deploy a DNS TXT record under the name

_acme-challenge.db.example.com with the following value:
 jn324jr348r342bhr234hrou234nbr4324fj34r

Also db.example.com is inside /etc/bind/.

What I do is that opened db.example.com and at the bottom line add this:

_acme-challenge.db.example.com 3600 IN TXT "jn324jr348r342bhr234hrou234nbr4324fj34r"

But whe i check it like this:

nslookup -type=TXT _acme-challenge.example.com

It gives me this error:

 - The following errors were reported by the server:                           

   Domain: db.example.com                                                
   Type:   dns                                                                 
   Detail: DNS problem: NXDOMAIN looking up TXT for                            
   _acme-challenge.db.example.com - check that a DNS record              
   exists for this domain                                                      
ubuntu@me-1:/etc/bind$ nslookup -type=TXT _acme-challenge.example.com
Server:         127.0.0.53                                                     
Address:        127.0.0.53#53                                                  

** server can't find _acme-challenge.example.com: NXDOMAIN

And when I run Certbot also get an error:

Some challenges have failed.                                                   

IMPORTANT NOTES:                                                               
 - The following errors were reported by the server:                           

   Domain: db.example.com                                                
   Type:   dns                                                                 
   Detail: DNS problem: NXDOMAIN looking up TXT for                            
   _acme-challenge.db.example.com - check that a DNS record                                           
   exists for this domain

What wrong Im doing here?

Fcoder
  • 341
  • 1
  • 4
  • 8
  • You should prefer `dig` over `nslookup` in general, but in both cases you should specify the nameserver you query (that is `dig` option `@`) otherwise you are querying any random recursive nameserver which does not allow you to see exactly what is published right now on your authoritative nameservers because of the caching. – Patrick Mevzek May 25 '20 at 20:55

2 Answers2

10

Please note you have to wait for a while until changes in your DNS zone will be updated on servers worldwide. Your problem is that you're trying to check if changes are applied to the DNS too fast. There is a good way out from this case and it requires using DNS provider's API. If you use for instance OVH, you can use their API for DNS changes and certbot will be able to check changes immediately. There is a list of all API plugins here: https://certbot.eff.org/docs/using.html?highlight=dns#dns-plugins

If your DNS provider doesn't support this, try moving your DNS zone to Cloudflare. It's super easy and you'll get that service for free. Also, by using DNS API you'll be able to renew wildcard certificates for free by leaving a single command in cron like this:

0  1   20 * *   root    certbot certonly --non-interactive -d example.com -d '*.example.com' --dns-cloudflare --dns-cloudflare-credentials /my/secret/api/key/location
Radosław Serba
  • 173
  • 1
  • 11
  • 2
    "Please note you have to wait for a while until changes in your DNS zone will be updated on servers worldwide. " That is not true. There is no propagation Updates are (should be) immediate on authoritative nameservers. Recursive ones will be updated once they do a query, not automatically. If they did a query just before the change then they kept the previous data for at least the TTL value associated with the records. – Patrick Mevzek May 25 '20 at 20:54
  • Please renew at a random time of the day. Packages usually include a randomized systemd timer, or a cron job like `0 */12 * * * root perl -e 'sleep int(rand(43200))' && certbot -q renew`. – Matt Nordhoff May 25 '20 at 23:51
  • @MattNordhoff what's the point of renewing a certificate once per day if you can execute that command once for a month since Let's Encrypt certificates are valid for 3 months? @PatrickMevzek that's true, my answer wasn't accurate for a reason - people usually don't have authoritative server set as a default one on their devices to query DNS. Usually it comes from ISP or people set 8.8.8.8 as it's popular. You can always define what server are you querying in the `nslookup` like `nslookup supra.tf 1.1.1.1` where `1.1.1.1` is the server being queried. – Radosław Serba May 26 '20 at 16:22
  • 1
    "people usually don't have authoritative server set as a default one on their devices to query DNS." That doesn't mean anything. Of course no one query authoritative nameservers directly under normal operations, you always use a recursive one. But to DEBUG DNS related problems you can query authoritative nameservers. There is no default hard coded time for changes to appear worldwide because there is just no propagation as the DNS is not top down. Understanding the difference between authoritative and recursive nameservers is very important. – Patrick Mevzek Jun 18 '20 at 16:36
  • that means a lot, thanks a lot for the explanation – Radosław Serba Jun 21 '20 at 11:56
7

Note that in a zone file, names not ending with a dot . are relative, usually to the current domain.

So an entry for _acme-challenge.db.example.com inside the zone for db.example.com actually means an entry for _acme-challenge.db.example.com.db.example.com.

To make sure you have the right entry, you can either:

  • Add a dot a the end: _acme-challenge.db.example.com.

  • Or not include the domain: _acme-challenge

This is based on the zone being for db.example.com, things would be slightly different is the zone were for example.com instead.

Also don't forget to update the serial of the zone (in the SOA record) when you update it, and reload the zone.

This is of course based on the registered name servers for your domain being your own server (and a secondary).

When querying using nslookup or dig you can tell them which server to ask the answer from. Always start by checking your primary, then your secondary, then other servers. And don't forget some types of updates may take a while (especially changes which are subject to TTL of the previous record, and additions subject to the negative cache TTL of the domain).

jcaron
  • 1,030
  • 7
  • 9