starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 11:15:54 +03:00

[GH-ISSUE #3226] ACME support for TLS #1159

New issue

Open

opened 2026-03-16 01:45:35 +03:00 by kerem · 9 comments

kerem commented

2026-03-16 01:45:35 +03:00

Owner

Originally created by @Cyberax on GitHub (Aug 22, 2025).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3226

Hickory has support for DNS over TLS, but it requires the certificate to be specified externally. It would be nice if Hickory could automatically request certificates from Let's Encrypt, especially when it already has a TLS server.

It can then use the TLS challenge (TLS-ALPN-01), avoiding the need to run an HTTP server or use the DNS challenge.

Describe the solution you'd like
An optional TLS-ALPN-01 challenge solver that can be used to periodically update the TLS keys.

Describe alternatives you've considered
An insecure HTTP-only server on port 80 to retrieve keys and send a SIGHUP to Hickory is another solution.

Originally created by @Cyberax on GitHub (Aug 22, 2025). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3226 Hickory has support for DNS over TLS, but it requires the certificate to be specified externally. It would be nice if Hickory could automatically request certificates from Let's Encrypt, especially when it already has a TLS server. It can then use the TLS challenge (TLS-ALPN-01), avoiding the need to run an HTTP server or use the DNS challenge. **Describe the solution you'd like** An optional TLS-ALPN-01 challenge solver that can be used to periodically update the TLS keys. **Describe alternatives you've considered** An insecure HTTP-only server on port 80 to retrieve keys and send a SIGHUP to Hickory is another solution.

kerem commented

2026-03-16 01:45:42 +03:00

Author

Owner

@djc commented on GitHub (Aug 22, 2025):

Would be nice, I guess. @cpu I guess this would make RFC 9539 support nicer but it's not a requirement?

@Cyberax would you be able to contribute a PR that integrates instant-acme? Do you need integration in the server library or in the binary?

@djc commented on GitHub (Aug 22, 2025): Would be nice, I guess. @cpu I guess this would make RFC 9539 support nicer but it's not a requirement? @Cyberax would you be able to contribute a PR that integrates instant-acme? Do you need integration in the server library or in the binary?

kerem commented

2026-03-16 01:45:47 +03:00

Author

Owner

@cpu commented on GitHub (Aug 23, 2025):

I guess this would make RFC 9539 support nicer but it's not a requirement?

Yeah, for an auth. server RFC 9539 advocates self-signed certs for DoT/DoH/DoQ, but one issued by a real CA via ACME would be better for ratcheting up security in the future and a recursive peer that follows the 9539 advice and ignores path building to a known trust anchor would be no worse off.

@Cyberax are you thinking about this for a Hickory based recursive resolver offering DoT to clients?

In either case I think getting the configuration right will take some care since I suspect it'll be important to include an IP address subject for the DoH/DoT/DoQ resolver context, and to have some control over the address(es) picked if we're binding multiple interfaces. For LE that also means using the short-lived profile that isn't quite launched in prod yet.

@cpu commented on GitHub (Aug 23, 2025): > I guess this would make RFC 9539 support nicer but it's not a requirement? Yeah, for an auth. server RFC 9539 advocates self-signed certs for DoT/DoH/DoQ, but one issued by a real CA via ACME would be better for ratcheting up security in the future and a recursive peer that follows the 9539 advice and ignores path building to a known trust anchor would be no worse off. @Cyberax are you thinking about this for a Hickory based recursive resolver offering DoT to clients? In either case I think getting the configuration right will take some care since I suspect it'll be important to include an IP address subject for the DoH/DoT/DoQ resolver context, and to have some control over the address(es) picked if we're binding multiple interfaces. For LE that also means using the short-lived profile that isn't quite launched in prod yet.

kerem commented

2026-03-16 01:45:52 +03:00

Author

Owner

@divergentdave commented on GitHub (Aug 23, 2025):

Note that using TLS-ALPN-01 will require a separate TLS server listening on port 443. The existing port 853 server for DoT is not suitable to demonstrate domain control under the CABF Baseline Requirements.

@divergentdave commented on GitHub (Aug 23, 2025): Note that using TLS-ALPN-01 will require a separate TLS server listening on port 443. The existing port 853 server for DoT is not suitable to demonstrate domain control under the CABF Baseline Requirements.

kerem commented

2026-03-16 01:45:57 +03:00

Author

Owner

@Cyberax commented on GitHub (Aug 23, 2025):

@djc I guess the binary itself would be better-suited for that. I'll work on the PR in the near future, and it indeed can help with the future RFC 9539 support or the DoH for recursive clients.

@Cyberax commented on GitHub (Aug 23, 2025): @djc I guess the binary itself would be better-suited for that. I'll work on the PR in the near future, and it indeed can help with the future RFC 9539 support or the DoH for recursive clients.

kerem commented

2026-03-16 01:46:02 +03:00

Author

Owner

@Cyberax commented on GitHub (Aug 23, 2025):

@cpu Yes, I'm thinking primarily about this use-case. Encryption for the recursive-to-authoritative traffic would also be nice, but it's realistically years away from wide deployment.

@Cyberax commented on GitHub (Aug 23, 2025): @cpu Yes, I'm thinking primarily about this use-case. Encryption for the recursive-to-authoritative traffic would also be nice, but it's realistically years away from wide deployment.

kerem commented

2026-03-16 01:46:07 +03:00

Author

Owner

@bdaehlie commented on GitHub (Aug 23, 2025):

We are working to speed up the timeline for that and ACME support would be very helpful.

@bdaehlie commented on GitHub (Aug 23, 2025): We are working to speed up the timeline for that and ACME support would be very helpful.

kerem commented

2026-03-16 01:46:12 +03:00

Author

Owner

@cpu commented on GitHub (Aug 23, 2025):

@Darkspirit It seems you deleted your comment?

Why not dns-01?

Quoting from the Let's Encrypt post, We've Issued Our First IP Address Certificate:

And, probably not surprisingly, you can’t use the DNS challenge method to prove your control over an IP address; only the http-01 and tls-alpn-01 methods can be used.

I think it's important for recursive resolvers offering DoT to include a IP address subject. There may be an argument that it's worth supporting other challenge-types, but I agree with the OP that starting with TLS-ALPN-01 is a sensible route.

@cpu commented on GitHub (Aug 23, 2025): @Darkspirit It seems you deleted your comment? > Why not dns-01? Quoting from the Let's Encrypt post, [We've Issued Our First IP Address Certificate](https://letsencrypt.org/2025/07/01/issuing-our-first-ip-address-certificate): > And, probably not surprisingly, you can’t use the DNS [challenge method](https://letsencrypt.org/docs/challenge-types/) to prove your control over an IP address; only the http-01 and tls-alpn-01 methods can be used. I think it's important for recursive resolvers offering DoT to include a IP address subject. There may be an argument that it's worth supporting other challenge-types, but I agree with the OP that starting with TLS-ALPN-01 is a sensible route.

kerem commented

2026-03-16 01:46:17 +03:00

Author

Owner

@msrd0 commented on GitHub (Oct 14, 2025):

I think the HTTP-01 would also make a lot of sense. On my server, I have both a DoT server and an HTTP(s) server running. Thus, both port 80 and port 443 are controlled by other software and cannot be used by hickory-dns. IIRC, The TLS challenge requires full control over port 443, and cannot sit behind a reverse proxy. The HTTP-01 challenge could be implemented by hickory-dns by opening an http server to some unix socket or local port and having the reverse proxy forward requests there.

@msrd0 commented on GitHub (Oct 14, 2025): I think the HTTP-01 would also make a lot of sense. On my server, I have both a DoT server and an HTTP(s) server running. Thus, both port 80 and port 443 are controlled by other software and cannot be used by hickory-dns. IIRC, The TLS challenge requires full control over port 443, and cannot sit behind a reverse proxy. The HTTP-01 challenge could be implemented by hickory-dns by opening an http server to some unix socket or local port and having the reverse proxy forward requests there.

kerem commented

2026-03-16 01:46:22 +03:00

Author

Owner

@edgecase14 commented on GitHub (Oct 28, 2025):

... IIRC, The TLS challenge requires full control over port 443, and cannot sit behind a reverse proxy.

The UALPN part of Uacme can be a reverse proxy for the alpn challenge, as can nginx.

@edgecase14 commented on GitHub (Oct 28, 2025): > ... IIRC, The TLS challenge requires full control over port 443, and cannot sit behind a reverse proxy. The UALPN part of Uacme can be a reverse proxy for the alpn challenge, as can nginx.