[RFC] re-structure named.toml
syntax to reject invalid configurations
#2195
Labels
named.toml
syntax to reject invalid configurations
#2195
According to this comment
The
enable_dnssec
setting is used to enable (runtime) signing of DNS records.Currently, this setting sits at the
zones
level, see belowHowever, in a recursive resolver (a
recursor
store) we don't want to (DNSSEC) sign records; instead we want to DNSSEC validate them. In RFC #2194, the idea is to put the setting inside thestores
field (which maps to theRecursiveConfig
type). Once you pick adnssec_validation
option, theenabled_dnssec
setting one level above becomes irrelevant.Only in the case of authoritative name servers -- the
file
andsqlite
store types -- we want to be able to (DNSSEC) sign records. The forward resolver mode (theforward
store type) should neither DNSSEC sign records nor DNSSEC validate the answers to the queries it forwards. To me that means, thatenable_dnssec
should be insideFileConfig
andSqliteConfig
, that is beneathzones.stores
Overall, it seems that
ZoneConfig
allows representing impossible configurations and storing settings unrelated to the operating mode of the zone (resolver vs authoritative name server). For example,zones.allow_axfr
only applies to (secondary?) name servers that serve a zone filezones.zone_type
toPrimary
(authoritative name server) but thestore
to therecursor
type (recursive resolver) -- those are different roleszones.file
is "a short-hand forStoreConfig::FileConfig
"; what happens if you set bothzones.file
andzones.stores.type = "file"
? which one takes precedence? what happens if you setzones.stores.type
to something other thanfile
.zones.keys
are only going to be used ifenable_dnssec
istrue
but they can be specified whenenable_dnssec
isfalse
and you don't get a warning that they are not used (+)I think it would make sense to:
(1) rework the
ZoneConfig
struct so that in memory one cannot represent impossible configurations nor store settings that won't be used. I think that would mean using an enum-struct to represent theZoneType
. Something like: (NOTE: very rough approximation as per my understanding of hickory's features)(2) lint the
named.toml
file and emit warnings when settings that are not part ofZoneConfig
are used (+)(+) the
toml
crate is lax / permissive in this regard. it does not emit an error when the input includes a field that's not part of thestruct
is being deserialized into ( see example below ). performing the linting might require quite a bit of extra code -- unless serde has some "strict" mode that we could use hereprints
Ok(Config { foo: false })
The text was updated successfully, but these errors were encountered: