[GH-ISSUE #3089] hickory-resolver ignores validate = true if DNSSEC feature is not enabled #1130

New issue

Closed

opened 2026-03-16 01:41:29 +03:00 by kerem · 2 comments

kerem commented

2026-03-16 01:41:29 +03:00

Owner

Originally created by @cr-tk on GitHub (Jun 26, 2025).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3089

Describe the bug
The resolver library falls back to validate = false behavior if the __dnssec feature isn't active, for example if the the dnssec-ring feature is accidentally not specified. This can be problematic for programs relying on the DNSSEC security properties.

I think the relevant code here issues tracing::warn!("validate option is only available with dnssec features");, but this is still effectively a silent fallback to insecure behavior from the perspective of (most?) users. During brief testing, I couldn't get the warning to print in example code, even with RUST_LOG=trace and similar environment variables.

To Reproduce

Example program:

use hickory_resolver::{
    Resolver,
    config::{ResolverConfig, ResolverOpts},
    name_server::TokioConnectionProvider,
};

#[tokio::main]
async fn main() {
    let mut resolver_builder =
        Resolver::builder_with_config(ResolverConfig::google(), TokioConnectionProvider::default());

    let mut resolver_options = ResolverOpts::default();
    // turn on validation
    resolver_options.validate = true;

    *resolver_builder.options_mut() = resolver_options;
    let resolver = resolver_builder.build();

    let response = resolver.lookup_ip("www.example.com.").await.unwrap();

    println!("{response:?}");
}

[dependencies]
hickory-resolver = { version = "0.25.2", features = [
    "tokio",
    # "dnssec-ring", # for DNSSEC
] }
tokio = { version = "1.45.0" }

Expected behavior
Triggering clear errors at build- or runtime which notify about the attempted use of a security feature that's unavailable, potentially aborting the program or build due to misconfiguration.

System:

OS: Linux
rustc version: 1.87.0 (stable)

Version:
Crate: hickory-resolver
Version: 0.25.2

Additional context
While the README.md has a section on how to turn on DNSSEC, the ResolverOpts code documentation doesn't mention any special crate requirements and suggests this functionality is available immediately:

    /// Use DNSSEC to validate the request
    pub validate: bool,

This could be improved as well.

Originally created by @cr-tk on GitHub (Jun 26, 2025). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3089 **Describe the bug** The resolver library falls back to `validate = false` behavior if the `__dnssec` feature isn't active, for example if the the `dnssec-ring` feature is accidentally not specified. This can be problematic for programs relying on the DNSSEC security properties. I think the relevant code [here](https://github.com/hickory-dns/hickory-dns/blob/527c9f470a418cf6b92da902ea0aaa5749963d59/crates/resolver/src/resolver.rs#L91-L104) issues `tracing::warn!("validate option is only available with dnssec features");`, but this is still effectively a silent fallback to insecure behavior from the perspective of (most?) users. During brief testing, I couldn't get the warning to print in example code, even with `RUST_LOG=trace` and similar environment variables. **To Reproduce** Example program: ```Rust use hickory_resolver::{ Resolver, config::{ResolverConfig, ResolverOpts}, name_server::TokioConnectionProvider, }; #[tokio::main] async fn main() { let mut resolver_builder = Resolver::builder_with_config(ResolverConfig::google(), TokioConnectionProvider::default()); let mut resolver_options = ResolverOpts::default(); // turn on validation resolver_options.validate = true; *resolver_builder.options_mut() = resolver_options; let resolver = resolver_builder.build(); let response = resolver.lookup_ip("www.example.com.").await.unwrap(); println!("{response:?}"); } ``` ```toml [dependencies] hickory-resolver = { version = "0.25.2", features = [ "tokio", # "dnssec-ring", # for DNSSEC ] } tokio = { version = "1.45.0" } ``` **Expected behavior** Triggering clear errors at build- or runtime which notify about the attempted use of a security feature that's unavailable, potentially aborting the program or build due to misconfiguration. **System:** - OS: Linux - rustc version: 1.87.0 (stable) **Version:** Crate: `hickory-resolver` Version: `0.25.2` **Additional context** While the `README.md` has a section on how to turn on DNSSEC, the `ResolverOpts` code documentation doesn't mention any special crate requirements and suggests this functionality is available immediately: ```Rust /// Use DNSSEC to validate the request pub validate: bool, ``` This could be improved as well.

kerem closed this issue

2026-03-16 01:41:34 +03:00

kerem commented

2026-03-16 01:41:40 +03:00

Author

Owner

@djc commented on GitHub (Jun 26, 2025):

Fair point. See #3091.

@djc commented on GitHub (Jun 26, 2025): Fair point. See #3091.

kerem commented

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

Author

Owner

@cr-tk commented on GitHub (Jun 27, 2025):

I tested this against the newest commit 82c85dcfdb, and agree that your change fixes the behavior 👍

Instead of compiling and then throwing warnings during runtime that (sometimes?) don't reach the user, the Rust compiler will now abort compilation of any code that uses the validate field without having the required feature enabled:

error[E0609]: no field validate on type ResolverOpts

I think that's a much safer construction. Thanks for patching!

@cr-tk commented on GitHub (Jun 27, 2025): I tested this against the newest commit 82c85dcfdbee165e81d8392575b1183d644ae922, and agree that your change fixes the behavior 👍 Instead of compiling and then throwing warnings during runtime that (sometimes?) don't reach the user, the Rust compiler will now abort compilation of any code that uses the `validate` field without having the required feature enabled: >error[E0609]: no field `validate` on type `ResolverOpts` I think that's a much safer construction. Thanks for patching!

kerem referenced this issue

2026-03-16 04:20:45 +03:00

[PR #1130] [MERGED] update client README.md example #1993

kerem referenced this issue

2026-03-16 04:24:02 +03:00

[PR #1130] [MERGED] update client README.md example #1999