Managed keys presumes the operator is actually using RFC5011 timings
to roll their keys. There are very few zones that have publicly
said they are using RFC 5011.
Named gets used on private networks. Those networks can use DNSSEC
they can decide to use trusted-keys rather than RFC 5011.
Mark
> On 9 Feb 2018, at 2:24 am, Matt Larson <m...@kahlerlarson.org> wrote:
>
>>
>> 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
> "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
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
