[RFC] DNSSEC validation: configuration syntax about hickory-dns HOT 11 OPEN

I think we might want to continue supporting that in addition to any future support for the RFC5011 standard. I don't think I see that as an option in your list...

the InitialKey variant (of the Dnssec enum) corresponds to RFC5011. BIND uses the initial-key property (key?) in its settings to configure an initial key that's used to implement RFC5011.

I'm not sure if BIND or unbound hard-code a trust anchor in their source but the bind9 (Debian) package includes the file /etc/bind/bind.keys, which configures key 20326 (from 2017) as an "initial-key"; that is the trust anchor is provided in a separate file, not as part of the binary.

If we want to support a trust anchor built into the hickory-dns binary we could convert the file field in the InitialKey and StaticKey variants into an Option<PathBuf> where the None variant means "use the built-in trust anchor".

from hickory-dns.

update here: as I'm implementing this RFC I realized hickory-dns is using the basic-toml crate which does not support serializing nor deserializing enum variants that have fields like the ones (Dnssec) we want to use here. the toml crate does support such enums so I'll use the toml crate in an initial implementation. we can discuss if we want to switch to toml or change the layout of Dnssec

from hickory-dns.

How does DnssecValidation get represented in TOML? I like that the enum approach is more explicit.

from hickory-dns.

to use an enum with serde/toml we need to give pick a name for the tag field that will hold the enum variant name.

if we give the tag the name "mode" then the TOML would look like this

stores = {
    type = "recursor"
    roots = "/etc/root.hints",

    dnssec_validation = { 
        mode = "Disabled"
    }
    # Or
    dnssec_validation = { 
        mode = "InitialKey",
        file = "/etc/trusted.key"
    }
    # Or
    dnssec_validation = { 
        mode = "StaticKey",
        file = "/etc/trusted.key"
    }
}

from hickory-dns.

That looks good to me.

from hickory-dns.

given that we added a security_aware setting in #2196 we need to consider its interaction with dnssec_validation. to perform dnssec_validation, the recursor needs to be security_aware so we have a few options to represent these two settintgs:

one way is to keep the security_aware boolean next to the dnssec_validation enum we discussed, i.e.

struct RecursorConfig {
    #[serde(default = "false")]
    security_aware: bool,
    #[srede(default = "DnssecValidation::Disabled")]
    dnssec_validation: DnssecValidation,
}

#[non_exhaustive]
pub enum DnssecValidation {
    Disabled,
    // RFC5011
    InitialKey { file: PathBuf },
    // externally-managed key
    StaticKey { file: PathBuf },
    .// ..
}

in this case security_aware: false + DnssecValidation::{InitialKey,StaticKey} should be rejected with an error.

and possibly we'll want to accept this configuration

# security_aware has been omitted
dnssec_validation = { 
    mode = "InitialKey",
    file = "/etc/trusted.key"
}

where the omitted security_aware is understood to be true even though normally it defaults to true

the other set of options are to turn security_aware into an enum that wraps DnssecValidation.

enum SecurityAware {
    No,
    Yes(DnssecValidation),
}

#[non_exhaustive]
pub enum DnssecValidation {
    Disabled,
    // RFC5011
    InitialKey { file: PathBuf },
    // externally-managed key
    StaticKey { file: PathBuf },
    .// ..
}

or use a "flatter" representation with a single enum that captures the 4 cases.

enum Dnssec {
    SecurityUnaware, // default
    ValidationDisabled, // security-aware but no validation
    InitialKey { file: PathBuf },
    StaticKey { file: PathBuf },
}

both of these options don't allow "impossible" configurations (e.g. security_aware: false + DnssecValidation::InitialKey) that need to be linted for after the serde deserialization

from hickory-dns.

I think I prefer the flatter representation.

Can you be explicit about what the difference is between security awareness and validation? In particular, being security aware without validating seems like a strange proposition.

from hickory-dns.

in practice, being a non-validating, security-aware, recursive resolver means that the DO (DNSSEC_OK) flag in client queries is respected, meaning that the response to the client will include DNSSEC data. This lets the client do the validation on its own, like delv does.

A validating (which implies also being security-aware) recursive resolver can be forced into behaving as a non-validating one by setting the CD (Checking Disabled) flag in the client's query.

Finally, a security-unaware, recursive resolver will ignore the DO flag in client queries and never report DNSSEC data back.

unbound and BIND, at least as packaged in Debian, are always security-aware but DNSSEC validation is opt-in.

from hickory-dns.

Makes sense, thanks for the explanation! I think conveying similar context via comments in the configuration/implementation etc would be helpful.

from hickory-dns.

I like this suggestion. Right now we compile in the trust-anchors, from here:

I think we might want to continue supporting that in addition to any future support for the RFC5011 standard. I don't think I see that as an option in your list...

from hickory-dns.

I like the built-in keys as it makes the key management simpler for initializing those roots.

from hickory-dns.