starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 03:05:51 +03:00

[GH-ISSUE #553] Server: Support alternate backend DBs #532

New issue

Open

opened 2026-03-15 22:59:50 +03:00 by kerem · 7 comments

kerem commented

2026-03-15 22:59:50 +03:00

Owner

Originally created by @Darkspirit on GitHub (Aug 27, 2018).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/553

PowerDNS stores all DNSSEC keys and zones in a MySQL database which you can replicate.

It would be good if there was an option to globally restrict/disable AXFR:

Originally created by @Darkspirit on GitHub (Aug 27, 2018). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/553 PowerDNS stores all DNSSEC keys and zones in a MySQL database which you can replicate. It would be good if there was an option to globally restrict/disable AXFR: * https://doc.powerdns.com/md/authoritative/settings/#allow-axfr-ips * https://doc.powerdns.com/md/authoritative/settings/#disable-axfr

kerem added the

enhance

crate:server

labels

2026-03-15 22:59:50 +03:00

kerem commented

2026-03-15 23:00:01 +03:00

Author

Owner

@bluejekyll commented on GitHub (Aug 27, 2018):

I've been reconsidering the storage for TRust-DNS. I'm still not sure which direction we should go. I've been contemplating building something like RAFT over DNS nodes, using DNS itself as a transport mechanism and mTLS as a means of validating the authn/authz.

If you you have specific requirements and want to put them on this bug that would be great. Specifically, what would be your idea means of restricting AXFR? would mTLS be something you'd consider good? I'm not a big fan of IP restriction...

@bluejekyll commented on GitHub (Aug 27, 2018): I've been reconsidering the storage for TRust-DNS. I'm still not sure which direction we should go. I've been contemplating building something like RAFT over DNS nodes, using DNS itself as a transport mechanism and mTLS as a means of validating the authn/authz. If you you have specific requirements and want to put them on this bug that would be great. Specifically, what would be your idea means of restricting AXFR? would mTLS be something you'd consider good? I'm not a big fan of IP restriction...

kerem commented

2026-03-15 23:00:06 +03:00

Author

Owner

@Darkspirit commented on GitHub (Sep 1, 2018):

I try to explain where I am and what I would try to get to:

My current PowerDNS configuration

MySQL backend (MariaDB)
any-to-tcp=yes
disable-axfr=yes (just not needed at the moment)
default-ksk-algorithms/default-zsk-algorithms=ecdsa384
Statistics page
Currently no slaves.
PowerDNS' HTTP API has one API key that permits to do everything.
PowerAdmin directly edits PowerDNS' database and afterwards runs pdnsutil rectify-zone domain.tld.
acme.sh updates the _acme-challenge.domain.tld/TXT record through PowerDNS' HTTP API.
A dyndns.php script allows certain users to update certain records, which itself uses the PowerDNS API.

If I keep PowerDNS, I would replace PowerAdmin and my dyndns.php script with a simple hyper/diesel/tokio-rustls solution.

But everything should be moved to TRust-DNS, if possible.

My idea was to create a small Rust program that

provides an HTTPS API for acme.sh and for a remote web interface,
creates files/keys for new zones and restarts TRust-DNS once a day,
updates zone files and runs nsupdate to update records on-the-fly (for example ACME TXT and TLSA)

I didn't start the project yet as I saw nsupdate's source code, didn't understand it and found no way to convert TRust-DNS' DNSSEC keys to its format.
(I'm not a real programmer, I can configure things.) It shook me out of disgust. I think I shouldn't want to use nsupdate. xD

Now I would have to try to get an alternative to nsupdate together, based on TRust-DNS' source code.

TRust-DNS' backend type doesn't really matter: Important would be only that there's no need for a restart. I can't judge protocols, but a dns server shouldn't waste power/time to make zone transfers to everyone who is asking. (I don't like security by obscurity. It's not my motivation.)

@Darkspirit commented on GitHub (Sep 1, 2018): I try to explain where I am and what I would try to get to: My current PowerDNS configuration - MySQL backend (MariaDB) - [any-to-tcp](https://doc.powerdns.com/md/authoritative/settings/#any-to-tcp)=yes - [disable-axfr](https://doc.powerdns.com/md/authoritative/settings/#disable-axfr)=yes (just not needed at the moment) - [default-ksk-algorithms](https://doc.powerdns.com/md/authoritative/settings/#default-ksk-algorithms)/[default-zsk-algorithms](https://doc.powerdns.com/md/authoritative/settings/#default-zsk-algorithms)=ecdsa384 - Statistics page - Currently no slaves. - PowerDNS' HTTP API has one API key that permits to do everything. - [PowerAdmin](https://www.poweradmin.org/) directly edits PowerDNS' database and afterwards runs [`pdnsutil rectify-zone domain.tld`](https://doc.powerdns.com/authoritative/manpages/pdnsutil.1.html). - [acme.sh](https://github.com/Neilpang/acme.sh/blob/master/dnsapi/dns_pdns.sh) updates the _acme-challenge.domain.tld/TXT record through PowerDNS' HTTP API. - A dyndns.php script allows certain users to update certain records, which itself uses the PowerDNS API. If I keep PowerDNS, I would replace PowerAdmin and my dyndns.php script with a simple hyper/diesel/tokio-rustls solution. But everything should be moved to TRust-DNS, if possible. My idea was to create a small Rust program that - provides an HTTPS API for acme.sh and for a remote web interface, - creates files/keys for new zones and restarts TRust-DNS once a day, - updates zone files and runs [`nsupdate`](https://manpages.debian.org/stretch-backports/dnsutils/nsupdate.1.en.html) to update records on-the-fly (for example ACME TXT and TLSA) I didn't start the project yet as I saw nsupdate's [source code](https://github.com/isc-projects/bind9/blob/master/bin/nsupdate/nsupdate.c), didn't understand it and found no way to convert TRust-DNS' DNSSEC keys to its format. (I'm not a real programmer, I can configure things.) It shook me out of disgust. I think I shouldn't want to use nsupdate. xD Now I would have to try to get an alternative to nsupdate together, based on TRust-DNS' source code. TRust-DNS' backend type doesn't really matter: Important would be only that there's no need for a restart. I can't judge protocols, but a dns server shouldn't waste power/time to make zone transfers to everyone who is asking. (I don't like security by obscurity. It's not my motivation.)

kerem commented

2026-03-15 23:00:11 +03:00

Author

Owner

@bluejekyll commented on GitHub (Sep 1, 2018):

Excellent. This is a great list of features!

I’ve been contemplating the dynamic dns story a little bit. In theory we should be compatible with nsupdate and sig0 auth, though I haven’t set that up. There is an integration test that is the opposite, ie trust-dns to bind9.

For updates over https, I’m finishing up work on the DNS-over-HTTPS implementation, I think we could potentially take that and extend it to support a JSON interface, but I’m only planning on supporting HTTP/2. If that’s a problem, then another option would be to create http server endpoint as you suggest, and bind that to a TRust-DNS server over the standard sig0 dynamic dns protocol.

In terms of the backend, I’ve been considering FoundationDB. But it shouldn’t be hard to take the existing SQLite backend and create one over Postgres or MariaDB (or both) if that’s preferable.

@bluejekyll commented on GitHub (Sep 1, 2018): Excellent. This is a great list of features! I’ve been contemplating the dynamic dns story a little bit. In theory we should be compatible with nsupdate and sig0 auth, though I haven’t set that up. There is an integration test that is the opposite, ie trust-dns to bind9. For updates over https, I’m finishing up work on the DNS-over-HTTPS implementation, I think we could potentially take that and extend it to support a JSON interface, but I’m only planning on supporting HTTP/2. If that’s a problem, then another option would be to create http server endpoint as you suggest, and bind that to a TRust-DNS server over the standard sig0 dynamic dns protocol. In terms of the backend, I’ve been considering FoundationDB. But it shouldn’t be hard to take the existing SQLite backend and create one over Postgres or MariaDB (or both) if that’s preferable.

kerem commented

2026-03-15 23:00:16 +03:00

Author

Owner

@Darkspirit commented on GitHub (Sep 1, 2018):

but I’m only planning on supporting HTTP/2

Perfect, awesome! :)
Personally, I only switched from h2 back to hyper because it was a bit easier and it allowed me to show an error page to all legacy clients (if req.version() != http::version::Version::HTTP_2) that they should download a recent Firefox.

But it shouldn’t be hard to take the existing SQLite backend and create one over Postgres or MariaDB (or both) if that’s preferable.

The main bonus of PowerDNS' MySQL backend is that it doesn't need zone-specific config files. Just replacing SQLite with another database wouldn't be like that. If TRust-DNS offered a small API and took care of storing the configuration in format you like (maybe just the current) and where you like, I TRust you on the decision how replication should be done in a way you like.

TRust-DNS' bind9-like backend is anyway good for simple configurations and should be extended with a service trust-dns-server reload functionality that re-reads config/zone files. (#20?)
That would be easier for beginners and maybe better than trying to locally use nsupdate? 🙈

I opened this issue because README.md says the following:

There currently is no way to limit TCP and AXFR operations, so it is still not recommended to put into production as TCP can be used to DOS the service.

My few club members will gladly take the "risk" to have TRust-DNS in production, even without turning AXFR off. If it would really happen, we wouldn't fear a DDoS or short downtimes by DOS.

@Darkspirit commented on GitHub (Sep 1, 2018): > but I’m only planning on supporting HTTP/2 Perfect, awesome! :) [Personally](https://dev.terrax.net), I only switched from h2 back to hyper because it was a bit easier and it allowed me to show an error page to all legacy clients (if req.version() != http::version::Version::HTTP_2) that they should download a recent Firefox. > But it shouldn’t be hard to take the existing SQLite backend and create one over Postgres or MariaDB (or both) if that’s preferable. The main bonus of PowerDNS' [MySQL backend](https://doc.powerdns.com/authoritative/backends/) is that it doesn't need zone-specific config files. Just replacing SQLite with another database wouldn't be like that. If TRust-DNS offered a small API and took care of storing the configuration in format you like (maybe just the current) and where you like, I TRust you on the decision how replication should be done in a way you like. TRust-DNS' bind9-like backend is anyway good for simple configurations and should be extended with a `service trust-dns-server reload` functionality that re-reads config/zone files. (#20?) That would be easier for beginners and maybe better than trying to locally use nsupdate? :see_no_evil: I opened this issue because README.md says the following: > There currently is no way to limit TCP and AXFR operations, so it is still not recommended to put into production as TCP can be used to DOS the service. My few club members will gladly take the "risk" to have TRust-DNS in production, even without turning AXFR off. If it would really happen, we wouldn't fear a [DDoS](https://wiki.hetzner.de/index.php/DDoS-Schutz/en) or short downtimes by DOS.

kerem commented

2026-03-15 23:00:21 +03:00

Author

Owner

@bluejekyll commented on GitHub (Sep 5, 2018):

TRust-DNS' bind9-like backend is anyway good for simple configurations and should be extended with a service trust-dns-server reload functionality that re-reads config/zone files.

Yes, we can start with this. I think there are some better signal handlers in place in now in Rust, so this is definitely an option...

My few club members will gladly take the "risk" to have TRust-DNS in production, even without turning AXFR off.

Cool, and it won't be hard for me to feature flag AXFR off, just not a high priority ATM.

@bluejekyll commented on GitHub (Sep 5, 2018): > TRust-DNS' bind9-like backend is anyway good for simple configurations and should be extended with a service trust-dns-server reload functionality that re-reads config/zone files. Yes, we can start with this. I think there are some better signal handlers in place in now in Rust, so this is definitely an option... > My few club members will gladly take the "risk" to have TRust-DNS in production, even without turning AXFR off. Cool, and it won't be hard for me to feature flag AXFR off, just not a high priority ATM.

kerem commented

2026-03-15 23:00:26 +03:00

Author

Owner

@wkornewald commented on GitHub (Jul 2, 2019):

Related to #16: For very easy deployment with replication and/or minimum resource usage (e.g. on Raspberry Pi) it would be great to have no dependency on external DBs and other services. Also, IMHO at least a replicated DNS cluster should be self-contained and small, so sqlite or some embedded key-value store and eventually consistent replication should be sufficient even for geo-distributed setups. Deploying (and learning how to do that, esp. for less popular DBs like FoundationDB) and maintaining a huge DB cluster for storing maybe just 10MB of dynamic data really shouldn't be required. Compared to MySQL or FoundationDB, replication at the Trust-DNS level allows for a significantly simpler and highly available (AP of CAP) deployment requiring minimal resources.

@wkornewald commented on GitHub (Jul 2, 2019): Related to #16: For very easy deployment with replication and/or minimum resource usage (e.g. on Raspberry Pi) it would be great to have no dependency on external DBs and other services. Also, IMHO at least a replicated DNS cluster should be self-contained and small, so sqlite or some embedded key-value store and eventually consistent replication should be sufficient even for geo-distributed setups. Deploying (and learning how to do that, esp. for less popular DBs like FoundationDB) and maintaining a huge DB cluster for storing maybe just 10MB of dynamic data really shouldn't be required. Compared to MySQL or FoundationDB, replication at the Trust-DNS level allows for a significantly simpler and highly available (AP of CAP) deployment requiring minimal resources.

kerem commented

2026-03-15 23:00:32 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jul 2, 2019):

I agree completely with this. I forsee different backend options. The current state of the world in the systems isn't ideal. We need some means of updating both in the file backed system and the sqlite system. Today, file backed is really the only serviceable means of operating trust-dns. I'd like to add some mechanism (sighup?) to reload files from disk. For sqlite which currently supports dynamic-dns, we need to come up with a replication strategy to make it complete, as discussed in #16 . And yes, I like the idea of having at least one option for a lightweight easily deployed service based on sqlite (or I've also been considering experimenting with rocksdb, as the datamodel is not complex).

@bluejekyll commented on GitHub (Jul 2, 2019): I agree completely with this. I forsee different backend options. The current state of the world in the systems isn't ideal. We need some means of updating both in the file backed system and the sqlite system. Today, file backed is really the only serviceable means of operating trust-dns. I'd like to add some mechanism (sighup?) to reload files from disk. For sqlite which currently supports dynamic-dns, we need to come up with a replication strategy to make it complete, as discussed in #16 . And yes, I like the idea of having at least one option for a lightweight easily deployed service based on sqlite (or I've also been considering experimenting with rocksdb, as the datamodel is not complex).

kerem referenced this issue

2026-03-15 23:00:53 +03:00

[GH-ISSUE #560] tcp connection shutting down: io error #537

kerem referenced this issue

2026-03-16 02:10:50 +03:00

[PR #566] [MERGED] Delays all connections until actual use. #1519