> On Feb 8, 2018, at 12:32 PM, Paul Vixie <p...@redbarn.org> wrote: > > > > Matt Larson wrote: >> 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. > > tough love is hard to give away. BIND9 ships inside a lot of packaged Linux > systems, and i don't imagine that ISC would ask or that RH would agree to > (another) deliberate invalidation of a working config file.
Out of curiosity, what other changes have there been that deliberately invalidated a working config? > the old one can be made to generate syslog warnings. but there would be some > lengthy crossover period during which both old and new config worked, so that > eventually, ISC and RH could include a python or perl script that would > convert old format to new. > > it's doable, but not in the style you suggest, or in a short time. I appreciate that line of reasoning when applied to invalidating features that don't have harmful consequences if used. But in the specific case we're talking about, the circumstances matter: I suggest that it's better to have the server refuse to start with a clear syslog message to force someone to adjust a harmful config rather than have the server start but fail to resolve queries by mysteriously returning SERVFAIL to everything. I realize that because of islands of security, there are keys other than the root KSK configured statically, so my reasoning does apply to every situation. But I'd bet lots of money that the vast majority of trusted-key statements are configuring KSK-2010. Another option, then, would be to allow trusted-keys in the general case but refuse to start if the trusted-key is for the root. Sometimes the root is special. (I see Ed Lewis approaching the mic now...) At the very least, a "trusted-keys for the root KSK considered harmful" syslog message would be a hopefully easy and non-controversial first step in the right direction. I understand that this is a big request, but I ask the ISC folks to consider it seriously. Matt _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
