starred/hickory-dns

Fork 0

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

[GH-ISSUE #2431] How to get rid of `openssl` from the dependency tree? #986

New issue

Closed

opened 2026-03-16 01:10:49 +03:00 by kerem · 5 comments

kerem commented

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

Owner

Originally created by @AaronKutch on GitHub (Sep 5, 2024).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2431

Unless I'm misunderstanding something, I can/should be able to remove openssl from the dependency tree (which would make it significantly easier to build the hickory-dns server and expunge the remaining non-Rust dependencies for my use case). Are there any issues that could arise?

One of the first things standing out from the Cargo.toml features is that all the activations of optional dependencies like

dns-over-rustls = [
...
    "hickory-resolver/dns-over-rustls",
]

(which appears to be intended to activate the feature flag and not pull in hickory-resolver by itself)
Should be written like

dns-over-rustls = [
...
    "hickory-resolver?/dns-over-rustls",
]

(which only activates the feature flag if hickory-resolver was actually pulled in)
(I forgot what this question mark case was called, it is difficult to search for), because building for a specific binary with --no-default-features --features=dns-over-rustls will build all of them together if even one of these is triggered without the ?. This issue is also causing openssl to be introduced from somewhere even when I don't have -openssl features, and I notice when trying to edit the Cargo.tomls that there is an error with a single ResolveError being pulled in from hickory-resolver that should probably be in hickory-proto.
I am also unsure about what features I actually need to enable for a public DNS server that should handle all of whatever a "standard" DNS server should. Why does the hickory-dns server crate pull in the recursor and resolver, shouldn't those only be for clients?

Originally created by @AaronKutch on GitHub (Sep 5, 2024). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2431 Unless I'm misunderstanding something, I can/should be able to remove `openssl` from the dependency tree (which would make it significantly easier to build the hickory-dns server and expunge the remaining non-Rust dependencies for my use case). Are there any issues that could arise? One of the first things standing out from the `Cargo.toml` features is that all the activations of optional dependencies like ``` dns-over-rustls = [ ... "hickory-resolver/dns-over-rustls", ] ``` (which appears to be intended to activate the feature flag and not pull in `hickory-resolver` by itself) Should be written like ``` dns-over-rustls = [ ... "hickory-resolver?/dns-over-rustls", ] ``` (which only activates the feature flag if `hickory-resolver` was actually pulled in) (I forgot what this question mark case was called, it is difficult to search for), because building for a specific binary with `--no-default-features --features=dns-over-rustls` will build all of them together if even one of these is triggered without the `?`. This issue is also causing `openssl` to be introduced from somewhere even when I don't have `-openssl` features, and I notice when trying to edit the Cargo.tomls that there is an error with a single `ResolveError` being pulled in from `hickory-resolver` that should probably be in `hickory-proto`. I am also unsure about what features I actually need to enable for a public DNS server that should handle all of whatever a "standard" DNS server should. Why does the `hickory-dns` server crate pull in the recursor and resolver, shouldn't those only be for clients?

kerem closed this issue

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

kerem commented

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

Author

Owner

@djc commented on GitHub (Sep 6, 2024):

Can you be more specific about what crate's Cargo.toml you're looking at? Is it the top-level server binary?

I think "weak" was used at some point to describe the ? here -- in any case, the feature resolution stuff is documented at https://doc.rust-lang.org/cargo/reference/features.html#dependency-features if that helps.

One problem is that there isn't a very good definition of what a "standard" DNS server is. Do you mean an authoritative server (that is delegated to by the parent zone's DNS server to resolve records for the zone) or a "stub" resolver (which we call a recursor)? The hickory-server crate also supports a wide range of protocols which is probably more extensive than that of many other implementations.

You didn't mention what version you're working with -- if 0.24.x, I suggest you try 0.25.0-alpha.2 (which should have decent quality) which improved a bunch on the dependency handling front.

@djc commented on GitHub (Sep 6, 2024): Can you be more specific about what crate's `Cargo.toml` you're looking at? Is it the top-level server binary? I think "weak" was used at some point to describe the `?` here -- in any case, the feature resolution stuff is documented at https://doc.rust-lang.org/cargo/reference/features.html#dependency-features if that helps. One problem is that there isn't a very good definition of what a "standard" DNS server is. Do you mean an authoritative server (that is delegated to by the parent zone's DNS server to resolve records for the zone) or a "stub" resolver (which we call a recursor)? The hickory-server crate also supports a wide range of protocols which is probably more extensive than that of many other implementations. You didn't mention what version you're working with -- if 0.24.x, I suggest you try 0.25.0-alpha.2 (which should have decent quality) which improved a bunch on the dependency handling front.

kerem commented

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

Author

Owner

@AaronKutch commented on GitHub (Sep 6, 2024):

All the higher level Cargo.tomls have this problem on the current main branch and on 0.25.0-alpha.2 which I am currently using. Even though they are not being used in the code, dependencies and whole extra binaries are being built when they shouldn't, and causing build issues or just adding unnecessary time. cargo build --bin hickory-dns with affected flags will build several binaries and not just the server which adds unnecessary time, and it also brings in openssl when it shouldn't.

I should specify by "standard" that I mean just a DNS server like 1.1.1.1 or 8.8.8.8. It will add some authoritative entries for a VPN overlay network but otherwise needs to cache normal things and act as a public DNS that would work with almost every program. I don't know if I should add on every protocol I can or if there are only some basic ones I should include. Is there anything important I leave out if I exclude all the openssl variants? What does it mean to activate dns-over-openssl and dns-over-rustls at the same time? What are the three dnssec variants each doing?

@AaronKutch commented on GitHub (Sep 6, 2024): All the higher level `Cargo.toml`s have this problem on the current `main` branch and on `0.25.0-alpha.2` which I am currently using. Even though they are not being used in the code, dependencies and whole extra binaries are being built when they shouldn't, and causing build issues or just adding unnecessary time. `cargo build --bin hickory-dns` with affected flags will build several binaries and not just the server which adds unnecessary time, and it also brings in `openssl` when it shouldn't. I should specify by "standard" that I mean just a DNS server like `1.1.1.1` or `8.8.8.8`. It will add some authoritative entries for a VPN overlay network but otherwise needs to cache normal things and act as a public DNS that would work with almost every program. I don't know if I should add on every protocol I can or if there are only some basic ones I should include. Is there anything important I leave out if I exclude all the openssl variants? What does it mean to activate `dns-over-openssl` and `dns-over-rustls` at the same time? What are the three `dnssec` variants each doing?

kerem commented

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

Author

Owner

@marcus0x62 commented on GitHub (Sep 7, 2024):

Hi @AaronKutch, a few things:

to build a DNS server which can query and cache results for arbitrary domains, you'll need to enable either the resolver (to use the "forwarder") or the resolver and the recursor (to build a fully-recursive DNS server.) The recursor isn't quite ready for prime time yet - many common DNS queries will fail to resolve properly. The forwarder works well. The difference between the two is the forwarder simply forwards DNS queries to an upstream recursive DNS server (like quad-1 or quad-8) whereas the recursor resolves the query on its own by consulting the root servers, TLD servers, authoritative servers, etc. for the record in question.

For me, at least, the following works for building a bare-bones server that supports hosting an authoritative zone and is capable of sending forwarding queries to an upstream server:

$ RUST_LOG=debug cargo run --no-default-features --features=resolver --bin hickory-dns -- -p 8853 --zonedir tests/test-data/test_configs --config tests/test-data/test_configs/example_forwarder.toml --debug

Disabling the various TLS options (and DNSSEC) will eliminate support for DNS over HTTPS and DNSSEC, and probably some other things I'm not thinking of, but not regular old unauthenticated DNS-over-UDP/TCP. Note that you can't build support for DNSSEC without also including the dns-over-rustls feature flag.
We're recommending people not expose their hickory servers directly to the Internet at this point - there's still some hardening work to do on the server side, particularly with TCP connections.

@marcus0x62 commented on GitHub (Sep 7, 2024): Hi @AaronKutch, a few things: 1) to build a DNS server which can query and cache results for arbitrary domains, you'll need to enable either the resolver (to use the "forwarder") or the resolver and the recursor (to build a fully-recursive DNS server.) The recursor isn't quite ready for prime time yet - many common DNS queries will fail to resolve properly. The forwarder works well. The difference between the two is the forwarder simply forwards DNS queries to an upstream recursive DNS server (like quad-1 or quad-8) whereas the recursor resolves the query on its own by consulting the root servers, TLD servers, authoritative servers, etc. for the record in question. For me, at least, the following works for building a bare-bones server that supports hosting an authoritative zone and is capable of sending forwarding queries to an upstream server: ``` $ RUST_LOG=debug cargo run --no-default-features --features=resolver --bin hickory-dns -- -p 8853 --zonedir tests/test-data/test_configs --config tests/test-data/test_configs/example_forwarder.toml --debug ``` 2) Disabling the various TLS options (and DNSSEC) will eliminate support for DNS over HTTPS and DNSSEC, and probably some other things I'm not thinking of, but not regular old unauthenticated DNS-over-UDP/TCP. Note that you can't build support for DNSSEC without also including the dns-over-rustls feature flag. 3) We're recommending people not expose their hickory servers directly to the Internet at this point - there's still some hardening work to do on the server side, particularly with TCP connections.

kerem commented

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

Author

Owner

@djc commented on GitHub (Sep 9, 2024):

If I run cargo tree --features dns-over-rustls in the /bin directory and review the resulting dependency tree, I do not see the openssl dependency appear. Can you clarify exactly what dependencies you are enabling?

I tried to clean up the server's feature forwarding a bit in https://github.com/hickory-dns/hickory-dns/pull/2441, please review.

@djc commented on GitHub (Sep 9, 2024): If I run `cargo tree --features dns-over-rustls` in the `/bin` directory and review the resulting dependency tree, I do not see the openssl dependency appear. Can you clarify exactly what dependencies you are enabling? I tried to clean up the server's feature forwarding a bit in https://github.com/hickory-dns/hickory-dns/pull/2441, please review.

kerem commented

2026-03-16 01:11:21 +03:00

Author

Owner

@AaronKutch commented on GitHub (Sep 9, 2024):

@marcus0x62 Thanks, I only needed to add "sqlite" to that for updating capability.

If I run cargo tree --features dns-over-rustls in the /bin directory and review the resulting dependency tree, I do not see the openssl dependency appear.

I could've sworn it was bringing in openssl with any feature last time I tried, it seems to be working perfectly today for whatever reason. It works now and works even better with the PR.

@AaronKutch commented on GitHub (Sep 9, 2024): @marcus0x62 Thanks, I only needed to add "sqlite" to that for updating capability. > If I run cargo tree --features dns-over-rustls in the /bin directory and review the resulting dependency tree, I do not see the openssl dependency appear. I could've sworn it was bringing in `openssl` with any feature last time I tried, it seems to be working perfectly today for whatever reason. It works now and works even better with the PR.

kerem referenced this issue

2026-03-16 02:28:55 +03:00

[PR #986] [MERGED] add TokioAsyncResolver::tokio apis for ease of use #1838