> On Feb 8, 2018, at 9:43 AM, Joe Abley <[email protected]> wrote:
>
>
>
>> On 8 Feb 2018, at 09:24, [email protected] wrote:
>>
>>> If just to spread rumors, I heard the following as early as November, 2016.
>>> One of the issues is that operators update code without updating
>>> configuration files. I.e., a BIND upgraded today might be using a
>>> configuration file from the pre-managed-key days.
>>
>> Speaking only for myself - I have done many BIND upgrades without config
>> file changes (and I basically expect this to work).
>
> The problem is that until the first KSK rollover,
>
> best current practice for configuring DNSSEC validation in 2008 (without
> RFC5011)
>
> and
>
> best current practice for configuring DNSSEC validation in 2018 (with
> RFC5011)
>
> are functionally identical; there's no failure evident from using
> trusted-keys vs. managed-keys in your configuration, and BIND9's fastidious
> backwards compatibility means that old configurations continue to work even
> if "best current practice" with respect to the facilities implemented in
> BIND9 have changed.
I would love to see BIND's trusted-keys syntax deprecated. Not the ability to
configure a trust anchor statically, mind you, just the syntax. Changing the
syntax and refusing to start with trusted-key in the configuration file would
force those who are dragging old config files behind them unchanged to update.
Maybe something like this:
managed-keys {
"." initial-key 257 3 8
"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
QxA+Uk1ihz0=";
managed no; // Behave as if this were "trusted-keys"
};
(But please let's not bikeshed the syntax of a possible implementation...)
Matt
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
