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 #2718] Feature Request: Allow live change of certificates #1047

New issue

Closed

opened 2026-03-16 01:25:44 +03:00 by kerem · 4 comments

kerem commented

2026-03-16 01:25:44 +03:00

Owner

Originally created by @msrd0 on GitHub (Jan 11, 2025).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2718

Is your feature request related to a problem? Please describe.

I am running a crab-hole server that uses hickory-server for its DNS server. Yesterday my phone refused to connect to my DNS and the reason turned out to be that the certificate that was loaded during startup had expired and the server had not loaded the updated certificate from the file.

Looking at the API of ServerFuture, it seems the certificate and private key are passed to the server during startup and are immutable thereafter.

Describe the solution you'd like

I would like to have a way to update the certificates used by the running server. This could either be done by having the register_xxx_listener functions taking something that can be mutated, e.g. an Arc<Mutex<_>> or a trait that can accept either the current type or a mutable type, or by adding functions that can be called after the server has started to provide new certificates for a certain listener.

Describe alternatives you've considered

The alternative is restarting the whole server, thereby stopping unaffected listeners as well, so less ideal.

Originally created by @msrd0 on GitHub (Jan 11, 2025). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2718 **Is your feature request related to a problem? Please describe.** I am running a [`crab-hole`] server that uses `hickory-server` for its DNS server. Yesterday my phone refused to connect to my DNS and the reason turned out to be that the certificate that was loaded during startup had expired and the server had not loaded the updated certificate from the file. Looking at the API of [`ServerFuture`], it seems the certificate and private key are passed to the server during startup and are immutable thereafter. **Describe the solution you'd like** I would like to have a way to update the certificates used by the running server. This could either be done by having the `register_xxx_listener` functions taking something that can be mutated, e.g. an `Arc<Mutex<_>>` or a trait that can accept either the current type or a mutable type, or by adding functions that can be called after the server has started to provide new certificates for a certain listener. **Describe alternatives you've considered** The alternative is restarting the whole server, thereby stopping unaffected listeners as well, so less ideal. [`crab-hole`]: https://github.com/LuckyTurtleDev/crab-hole [`ServerFuture`]: https://docs.rs/hickory-server/0.24/hickory_server/server/struct.ServerFuture.html

kerem closed this issue

2026-03-16 01:25:49 +03:00

kerem commented

2026-03-16 01:25:55 +03:00

Author

Owner

@djc commented on GitHub (Jan 11, 2025):

It looks we have API to provide a ServerConfig directly at least for DoT (but not DoH2/3 and DoQ). That could be used to implement a custom rustls ResolvesServerCert impl which holds a PathBuf and an RwLock. However, I don't think it would necessarily make sense for such an impl to live in HickoryDNS. Maybe the way forward is to contribute a utility impl to rustls and extend the ServerFuture configuration to allow ServerConfigs for all 4 protocols? Would you be able to contribute some of this stuff?

@djc commented on GitHub (Jan 11, 2025): It looks we have API to provide a ServerConfig directly at least for DoT (but not DoH2/3 and DoQ). That could be used to implement a custom rustls ResolvesServerCert impl which holds a PathBuf and an RwLock. However, I don't think it would necessarily make sense for such an impl to live in HickoryDNS. Maybe the way forward is to contribute a utility impl to rustls and extend the ServerFuture configuration to allow ServerConfigs for all 4 protocols? Would you be able to contribute some of this stuff?

kerem commented

2026-03-16 01:26:00 +03:00

Author

Owner

@msrd0 commented on GitHub (Jan 11, 2025):

So if I understand you correctly, you suggest that we add the option to hickory to specify the cert_resolver: Arc<dyn ResolvesServerCert> for rustls ServerConfig for all the supported listeners? Which part exactly do you think should live in rustls?

@msrd0 commented on GitHub (Jan 11, 2025): So if I understand you correctly, you suggest that we add the option to hickory to specify the `cert_resolver: Arc<dyn ResolvesServerCert>` for rustls `ServerConfig` for all the supported listeners? Which part exactly do you think should live in rustls?

kerem commented

2026-03-16 01:26:05 +03:00

Author

Owner

@msrd0 commented on GitHub (Jan 11, 2025):

I've implemented a basic solution based on a trait for the tls listener here: github.com/msrd0/trust-dns@0475cfcf36

Does this look roughly like what you had in mind?

@msrd0 commented on GitHub (Jan 11, 2025): I've implemented a basic solution based on a trait for the tls listener here: https://github.com/msrd0/trust-dns/commit/0475cfcf36ff51e07513b658f3b515576bbbedc1 Does this look roughly like what you had in mind?

kerem commented

2026-03-16 01:26:10 +03:00

Author

Owner

@djc commented on GitHub (Jan 11, 2025):

Not really.

I think it could make sense to pass Arc<dyn ResolvesServerCert> to the listeners, instead of just the (Vec<CertificateDer<'_>>, PrivateKeyDer<'_>). We don't need to keep compatibility, so I'd prefer to avoid the indirection and just change the registration methods directly.

Which part exactly do you think should live in rustls?

An implementation of ResolvesServerCert that contains two PathBufs and periodically refreshes the certificate chain and private key from disk.

@djc commented on GitHub (Jan 11, 2025): Not really. I think it could make sense to pass `Arc<dyn ResolvesServerCert>` to the listeners, instead of just the `(Vec<CertificateDer<'_>>, PrivateKeyDer<'_>)`. We don't need to keep compatibility, so I'd prefer to avoid the indirection and just change the registration methods directly. > Which part exactly do you think should live in rustls? An implementation of `ResolvesServerCert` that contains two `PathBuf`s and periodically refreshes the certificate chain and private key from disk.

kerem referenced this issue

2026-03-16 03:27:40 +03:00

[PR #1047] [MERGED] Bump async-trait from 0.1.24 to 0.1.25 #1914

kerem referenced this issue

2026-03-16 03:42:51 +03:00

[PR #1047] [MERGED] Bump async-trait from 0.1.24 to 0.1.25 #1919