DNS-01 challenge acme-dns internal Bind

Help
1

My domain is: ecfinternal.net

I ran this command on our acme-dns server: sudo certbot certonly --test-cert --manual --preferred-challenges dns --manual-auth-hook 'acme-dns-client' --dns-rfc2136-credentials ~/certbot/rfc2136.ini -d *.ecfinternal.net

It produced this output: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.ecfinternal.net - check that a DNS record exists for this domain

The operating system my web server runs on is (include version): Ubuntu 22.04

I have an internal LAN only Bind instance and Acme-DNS running on another server which does have a publicly accessible IP address.

ACME-dns is registered properly, I believe, but doesn't seem to actually put a txt record on my DNS server. But even if I remove the --manual-auth-hook command and put in the TXT record manually, I get the same result.

I think I understand why, it's because the TXT record on my Bind9 server isn't publicly accessible, right? I'm just not sure how to go about actually fixing this issue. Where should the TXT records go if not on our DNS server?

The guides I've seen and followed for acme-dns were all based on a public DNS server, so I think I understand why they worked in that case but not here.

Domain was purchased from Dreamhost. I added auth.ecfinternal.net (our acme-dns server) as a name server for that domain yesterday though I don't believe it has wholly propagated across the internet yet and I'm not sure if that helped or was necessary.

I've done a lot of reading over the past few days, but there are still some gaps in my understanding and my ability to get this all working. I would prefer not to go down the route of a private CA and faff about with installing CA certificates on 80+ hosts.

Any suggestions for what I'm missing/doing wrong? Thank you in advance.

2

I don't see any Cname record on _acme-challenge .ecfinternal.net to aith subdomain so not sure how it would work: only nameserver internet see is dreamhosts so any change you want to seen from internet need to be done on dreamboat name seever

4 Likes
3

I'm puzzled. Why are you combining an option for the dns-rfc2136 plugin and using acme-dns?

By the way, the hostname auth.ecfinternal.net does not exist at the Dreamhost nameservers. Also, if you simply add that single NS RR next to the 3 Dreamhost nameservers, you'd only have a 25 % chance of hitting the "correct" nameserver.

5 Likes
4

Good question. I've tried both with and with out the rfc-2136-credentials. Including it was an attempt to allow the acme-dns-client hook to put the txt file on the Bind server. Though even if it had succeed it wouldn't have helped anything as our Bind server is not publicly accessible.

5

To me, this suggests you don't fully grasp what you're doing and how the dns-01 challenge and/or acme-dns and/or the rfc-2136 plugin work.

My advice is to read up more about how these things work and if it makes sense to combine them. Or if that's even possible.

2 Likes
6

So I think what I may be missing is using some sort of public name-server at all. Dreamhost isn't hosting any records. I think I may just have misunderstood why or how to use acme-dns to allow an internal Bind server to be able to complete DNS challenges. I've heard it mentioned as an option on this forum, but I guess I'm still missing the pieces that make it actually work.

7

All challenges, dns-01, http-01 or tls-alpn-01, need to be performed using services accessible from the public internet. Using the dns-01 challenge is often the only way for people with private WEBservices, because DNS is often still publicly accessible.

When using the dns-01 challenge, the nameservers would thus need to be publicly accessible. If you'd run your own instance of acme-dns (which is just a single purpose DNS server actually), than that service too would need to be publicly accessible.

4 Likes
8

Right, the acme-dns server is publicly accessible, but the Bind servers are not. I've delegated auth.ecfinternal to the acme-dns server and registered the acme-dns-client and put the generated cname record on our bind server.

But either I'm missing some some steps or this is not a helpful path to go down and at least some records need to be hosted on a publicly accessible NS in order for verification to work.

9

The BIND server that's not publicly available? What good would the CNAME do there?

Please appreciate the working of the dns-01 challenge. The ACME validation server will crawl down the entire DNS zone from the top at the root DNS servers down to the authorative DNS server it finds in the DNS zone. ALL those services need to be publicly available. Which obviously would include the last server and all the servers in between.

Maybe I don't understand you correctly, but you say you have the acme-dns server publicly accessible. What does BIND have to do with all that? Can't you simply put the CNAME in your Dreamhost DNS zone, pointing to the acme-dns server?

3 Likes
10

Bind is simply where all all our other DNS records are.

But good point, I was following a guide to register the acme-dns-client with one's DNS server, but if that DNS server isn't publicly accessible then, yeah perhaps that isn't beneficial.

This more or less the idea of what I trying to accomplish but delegating _acme-challenge to acme-dns https://blog.svedr.in/posts/letsencrypt-dns-verification-using-a-local-bind-instance/

But acme-dns pointing at a local Bind instance, at least without delegation to a public name server doesn't seem like it's going to get me anywhere.

11

There is no mentioning of acme-dns in that guide. Also, acme-dns is always the end point of the DNS traversal. acme-dns CANNOT "point" to anything?

Are we even talking about the same acme-dns I'm wondering now?

5 Likes
12

Dreamhost has an option to flush their internal DNS cache once every 12 or 24 hours. It's on the DNS section of their control panel, but can be somewhat hidden. I doubt that is the issue, but you can try.

Like @Osiris said, you don't seem to understand exactly what is going on.

Looking at your DNS, it is wrong.

Whois reports this for your domain:

Name Server: AUTH.ECFINTERNAL.NET
Name Server: NS1.DREAMHOST.COM
Name Server: NS2.DREAMHOST.COM
Name Server: NS3.DREAMHOST.COM

These all should be the dreamhost severs. This is configured on your registrar (dreamhost). You should remove the AUTH entry for that.

Follow the directions on acme-dns. Your acme-dns server must be publicly accessible, and the DNS server that delegates authority to it must be publicly accessible.

In the dreamhost dns, you should:

  • NS record for auth.ecfinternal.net pointing to auth.ecfinternal.net
  • A record for auth.ecfinternal.net pointing to your IP address

Any subdmains you want to authorize via DNS-01 will then have a CNAME _acme-challenge record pointing to the "account" placed on the acme-dns instance.

I would prefer not to go down the route of a private CA and faff about with installing CA certificates on 80+ hosts.

acme-dns will require 80+ accounts to be setup for this, which can be overwhelming.

the acme-dns maintainers were nice enough to merge a PR for me a while ago -- Relax subdomain validation from UUID to actual subdomain by jvanasco · Pull Request #243 · joohoi/acme-dns · GitHub - which relaxes their validation to allow for rfc compliant subdomains to be used instead of uuids.

My suggestion is to write a script that will pre-generate an acme-dns credential for each of the 80+ domains, then use/adapt this script I open sourced to change the UUIDs into subdomains that reflect the subdomain you want a certificate for (see peter_sslers/tools/replace_domain.py at main · aptise/peter_sslers · GitHub)

This way your DNS records for example.com would CNAME onto com.example.auth.ecfinternal.net instead of uuid-uuid-uuid-uuid.auth.ectinternal.net. That can make management, setup, and troubleshooting much easher.

If using acme-dns, there is ZERO reason to involve bind or the various rfc2136 commands to certbot. The only command that certbot needs to know is the manual-auth-hook.

4 Likes
13

There we go, that is what I was missing, thank you. "Follow the directions on acme-dns. Your acme-dns server must be publicly accessible, and the DNS server that delegates authority to it must be publicly accessible." I knew the second part, but was not clear on the second part.

Yeah, I'll remove the auth.ecfinternal it's not doing anything. But neither are the dreamhost names servers at this point.

So if I understand it correctly my options are to ditch Bind entirely and go with public nameservers. Or go with private certificates. That makes sense to me.

As for generating the certificates I was going to use a few wildcards for sub domains to cut down the numbers somewhat, but thank you, I will certainly take a look at your PR and script that's very helpful.

1 Like
14

Nope, same acme-dns I just phrased it the wrong way around. Bind delegating to acme-dns. Not acme-dns pointing to bind.
And no, mention of acme-dns in that guide. If there were a guide of setting up acme-dns with an internal bind I certainly would be following that. But it does not exist for what are becoming obvious reasons.

15

You only need the public name servers to satisfy the challenge to get the public certificate. You could request the cert even from a single machine and then deploy the certificate as you see fit on your local network. You would not need A or AAAA records in the public DNS just the TXT record to satisfy the challenge.

You could continue to use your bind server for your local purposes

3 Likes
16

That's what I was trying to accomplish. My initial understanding was acme-v02.api would reach out to my acme-dns which "knows" to look for the txt records in my local bind server. I see now that's incorrect.

So my Bind side is mostly right, but acme-dns-client needs to register with a public DNS where it can place (and then remove) the TXT records? That's makes a good deal of sense. Requires the use of Bind, acme-dns and the public DNS, but that's fine.

1 Like
17

You wouldn't need acme-dns if your public DNS nameservers supported an API directly. For example, if you used Cloudflare instead (for free) you could use the Certbot plugin to update them directly

3 Likes
18

The concent would work, if acme-dns were something different entirely E.g., some kind of VPN linked DNS "proxy", if something like that even exists. But acme-dns is no such thing.

Still I can't escape the feeling you don't fully grasp what acme-dns is.. Please read up on that thoroughly. It's not that difficult of a concept. Please read the basics.

2 Likes
19

I found it confusing for a while. This topic of mine might help OP understand a bit:

5 Likes
20

True. If I were using a different public DNS with a less secure API and it had all our A records then I could certainly see a place with it. But if using Cloudfare and just for DNS Challenges, then removing it from the equation seem like the better choice.

2 Likes