Ability to redirect ACME DNS challenge?

[stefansundin]

Hello. Thanks for this service, it is very useful.

I have a question whether or not it would be possible to add a feature which would enable me to renew my wildcard Lets Encrypt cert without having to update my DNS. I have read https://github.com/cunnie/sslip.io/blob/main/docs/wildcard.md but honestly I don't fully understand how I would set that up, and I would prefer not to have to run my own DNS server.

Let me explain with my current setup and how I currently renew this certificate.

I have a domain that is hosted on Amazon Route53, lets call it example.com. I have a few DNS entries set up like foo.example.com, and then I have xip.example.com which is an NS record to ns-aws.sslip.io. So I am able to use both regular DNS records that are hardcoded, and then when I need to use sslip I simply use my xip subdomain.

However, I also want to use TLS on xip.example.com, and to do that I temporarily delete xip.example.com and I create _acme-challenge.xip.example.com to satisfy the DNS challenge. Once I have renewed the certificate I then again create xip.example.com. This works well, but there are some manual steps and I think it can be done better. And not to mention, this procedure temporarily breaks DNS queries for *.xip.example.com.

What if TXT queries for _acme-challenge.xip.example.com were redirected to _acme-challenge._xip.example.com (note that I added an underscore before xip). That would let me renew my certificate while not having to delete and later recreate xip.example.com.

I think this is a simpler solution than running your own DNS server. I hardly understand how that is done anyway. I guess I need to read up on authoritative DNS servers etc. The bottom line is that deleting and recreating my DNS record for a little while is far simpler to me than running my own DNS server.

I was going to try to implement this but I don't think it is possible to support this without breaking the current wildcard setup, which is why I am posting this issue.

Thank you for reading and considering my proposal!

[cunnie]

Hi @stefansundin ,

I also want to use TLS on xip.example.com, and to do that I temporarily delete xip.example.com and I create _acme-challenge.xip.example.com to satisfy the DNS challenge

I think you can accomplish what you want by creating an _acme-challenge.xip.example.com TXT record — you don't need to fiddle with the ._xip. subdomain.

I think that Let's Encrypt will query your name servers for the TXT record _acme-challenge.xip.example.com, then your DNS server will respond with the TXT record if it has been created, otherwise it'll return the delegated nameservers (ns-aws.sslip.io and so on).

[stefansundin]

Interesting! I guess I just assumed that any DNS request for anything under xip.example.com would go to sslip first and not my nameservers. I just renewed the cert again without messing with the NS record and it seems like it worked!

Thank you for explaining this! 😄 🎉

[TimeToogo]

Hey @cunnie,
From my testing using Route53 this approach does not work. My understanding (I may be wrong) is if you delegate a subdomain to another nameserver, that will take precedence over any records from the origin nameserver as the nameservers in the NS record become authoritative for that subdomain. Let me know if I've misunderstood your approach.
Thanks.

[cunnie]

@TimeToogo I don't know about Route 53, but I know you're right with BIND. Let me ponder this—I'm hoping I can do something clever with glue records.

[mrjones-plip]

Hey hey! I wanted to share some findings around this comment:

The bottom line is that deleting and recreating my DNS record for a little while is far simpler to me than running my own DNS server.

I VERY much agreed with this at first - I want to run as few servers/services as possible.

But having all kinds of problems with this flow, I found ACME DNS Server which made my life way easier. To me, if you're ok with a one liner to run sslip.io (I'm using the docker steps), you're likely ok with a few more lines:

1. kills the current docker instance of sslip.io :

   docker kill wildcard
   

2. in terminal 1: wait for "Please deploy a DNS TXT record under the name":

   certbot certonly --manual --preferred-challenges dns -d "*.xip.example.com"
   

3. in terminal 2: output the challenge value from step 2 into file, start simple DNS server for TXT, hit enter in terminal 1 when done:

   echo "ACME_CHALLENGE_VALUE" >/opt/records/_acme-challenge.xip.example.com&&./acme-dns-server.py 53 /opt/records 
   

4. run from terminal 2, stop acme-dns-server.py, start sslip.io docker container

   ctrl + c && docker start wildcard
   

Of course this is terrible to run manually every 3 months, but I very much enjoy I can do it all from the command line on the a single server. I found this easier than juggling my registrar's DNS server web GUI, the sslip.io server and then possibly another server with certbot or acme.sh or whatnot.

And, of course this should totally be automated with something like dehydrated's hook which acme-dns-server.py has published an example of.

[horsley]

@cunnie I have a new idea. First, let me briefly explain my current situation.

My domain name resolution is hosted on Cloudflare, and I have assigned a subdomain by pointing an NS record to ns-azure.sslip.io. The problem arises when I need to apply for a wildcard domain certificate for this subdomain. Both web and API options prohibit me from adding the corresponding TXT records. The reason is simple—Cloudflare considers the entire subdomain to be hosted elsewhere through NS records and no longer under Cloudflare's control. If I deploy the DNS service of sslip.io myself, I believe the service can provide an API for adding TXT records. This way, tools like acme.sh can add the appropriate TXT records using the API mode. Another option is to implement limited DNS API support based on the API specifications of widely supported DNS service providers. This approach would not require adding new capabilities or modifications to acme.sh while still providing support.

By using acme.sh, the DNS operations required for certificate issuance and renewal can be fully automated.

[cunnie]

Hi @horsley, thanks for explaining your current situation:

If I deploy the DNS service of sslip.io myself, I believe the service can provide an API for adding TXT records

What does "the service" refer to? Cloudflare? I assume you're not referring to sslip.io—it doesn't have an API.

[horsley]

@cunnie No, I mean that sslip.io should implement an API for adding TXT record acquired by DNS-01 challenge. With this API, the certificate application process can be fully automated.

Cloudflare already has an API, but it does not allow adding subdomain records when NS records have already been added to the domain. Cloudflare considers the management authority to be transferred once NS records are added. In this case, if we delegate the subdomain to sslip.io (self hosted) for DNS resolution through NS records, the TXT records required for the certificate application process should also be provided by this service.

It just another solution for the problem mentioned at #27. We want the acme-challenge TXT record works. After that, Let's Encrypt tools like acme.sh can issue and renew cert automatically

[horsley]

By reading the code, I found that what I actually need is the combination of "sslip.io/src/wildcard-dns-http-server" and "sslip.io/src/sslip.io-dns-server"

[cunnie]

By reading the code, I found that what I actually need is the combination of "sslip.io/src/wildcard-dns-http-server" and "sslip.io/src/sslip.io-dns-server"

I like that idea! I think that was the thrust of @TimeToogo 's PR, but it seems they've lost interest in the PR, so maybe I'll re-work it when I get back to the States (right now I'm in France playing rugby against local teams).

[wzwtt]

By reading the code, I found that what I actually need is the combination of "sslip.io/src/wildcard-dns-http-server" and "sslip.io/src/sslip.io-dns-server"

I like that idea! I think that was the thrust of @TimeToogo 's PR, but it seems they've lost interest in the PR, so maybe I'll re-work it when I get back to the States (right now I'm in France playing rugby against local teams).

It is a good idea, but I think the most practical way is to redirect txt query requests automatically, or even redirect all txt requests back to the original domain name. You can agree that all the addresses for back-to-source queries are the name of the atomic domain with an underscore (_) in front of it. For example, the NS record of *.xip.example.com points to ns-gce.sslip.io., and ns-gce.sslip.io can redirect all txt queries of *.xip.example.com back to *._xip.example.com, just like the txt query of somewords.xip.example.com returns to somewords._xip.example.com.

As for how to redirect, I think ns-gce.sslip.io can first query the txt record of somewords._xip.example.com, and then use this result to return to the queryer of somewords.xip.example.com.

I think this feature is very useful and can be considered for inclusion.

[cunnie]

@wzwtt thanks for the suggestion.

I am not sure what an "atomic" domain means, and I find the underscore notation confusing. But I encourage you to write the code you're interested in seeing — I happily review pull requests!

think ns-gce.sslip.io can first query the txt record of somewords._xip.example.com, and then use this result to return to the queryer of somewords.xip.example.com.

sslip.io will not query any other servers for records — it forces sslip.io to become a recursive nameserver, which brings in much more complexity (retries, timeouts, expiries) than I'm willing to deal with. You are, of course, free to fork my code, make the changes you want, but at that point you're better off starting from scratch using https://github.com/miekg/dns library rather than my code.