> On Feb 8, 2018, at 9:43 AM, Joe Abley <jab...@hopcount.ca> wrote:
>> On 8 Feb 2018, at 09:24, sth...@nethelp.no 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
 managed no; // Behave as if this were "trusted-keys"

(But please let's not bikeshed the syntax of a possible implementation...)


DNSOP mailing list

Reply via email to