Re: [DNSOP] Why new code/old keys? Re: [Ext] Re: sentinel and timing?

sth...@nethelp.no wrote: Speaking only for myself - I have done many BIND upgrades without config file changes (and I basically expect this to work). i apologize, again, for the config file from last-bind8, not working in all cases with first-bind9. i don't work at ISC any more, but i think

Re: [DNSOP] Why new code/old keys? Re: [Ext] Re: sentinel and timing?

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

Re: [DNSOP] Why new code/old keys? Re: [Ext] Re: sentinel and timing?

On Thu, Feb 08, 2018 at 10:06:02AM -0800, Paul Vixie wrote: > > 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 think that's entirely reasonable, and based on

Re: [DNSOP] Why new code/old keys? Re: [Ext] Re: sentinel and timing?

> On Feb 8, 2018, at 12:32 PM, Paul Vixie 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

Re: [DNSOP] Why new code/old keys? Re: [Ext] Re: sentinel and timing?

Matt Larson wrote: Out of curiosity, what other changes have there been that deliberately invalidated a working config? the big one was last-bind8 to first-bind9. there were also some minor ones over the years like changing the default for allow-query to be localnets rather than any. since

Re: [DNSOP] sentinel and timing?

On 8 Feb 2018, at 13:52, Paul Wouters wrote: > On Thu, 8 Feb 2018, Joe Abley wrote: > >> I don't disagree with the need for more data, but I think the hole you >> mention is not so giant. As far as I can tell it's a result of: > > How do you know without the data? I'm talking

Re: [DNSOP] sentinel and timing?

On Thu, 8 Feb 2018, Joe Abley wrote: I don't disagree with the need for more data, but I think the hole you mention is not so giant. As far as I can tell it's a result of: How do you know without the data? 1. RFC5011 support not being turned on in nameservers that have been upgraded but

Re: [DNSOP] Why new code/old keys? Re: [Ext] Re: sentinel and timing?

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

Re: [DNSOP] Why new code/old keys? Re: [Ext] Re: sentinel and timing?

> > Speaking only for myself - I have done many BIND upgrades without config > > file changes (and I basically expect this to work). > > i apologize, again, for the config file from last-bind8, not working in > all cases with first-bind9. i don't work at ISC any more, but i think i > can safely

Re: [DNSOP] sentinel and timing?

> On 8 Feb 2018, at 5:02 pm, Paul Wouters wrote: > > On Wed, 7 Feb 2018, Robert Story wrote: > >> On Wed 2018-02-07 10:43:16-0500 Paul wrote: >>> How about using this query to also encode an >>> uptime-processstartedtime value? Maybe with accurancy reduced to >>> minutes. I

[DNSOP] Why new code/old keys? Re: [Ext] Re: sentinel and timing?

On 2/8/18, 01:02, "DNSOP on behalf of Paul Wouters" wrote: >We have a giant hole in our understanding of why there are update nameservers >running the latest software with the older keys. If just to spread rumors, I heard the following as early as November, 2016. One of the issues is that

Re: [DNSOP] sentinel and timing?

Hi Paul, (with apologies for breakfast/iPad MIME crime that surely follows) > On Feb 8, 2018, at 01:02, Paul Wouters wrote: > >> On Wed, 7 Feb 2018, Robert Story wrote: >> >>> On Wed 2018-02-07 10:43:16-0500 Paul wrote: >>> How about using this query to also encode an >>>

Re: [DNSOP] Why new code/old keys? Re: [Ext] Re: sentinel and timing?

> 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 -

Re: [DNSOP] Why new code/old keys? Re: [Ext] Re: sentinel and timing?

> 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

Re: [DNSOP] Why new code/old keys? Re: [Ext] Re: sentinel and timing?

On 08/02/2018 14:18, Edward Lewis wrote: > I am not saying this theory has been put to the test, but it is > compelling. This hypothesis is in the ICANN deck on the KSK rollover > used throughout 2017 (until the postponement). Another hypothesis is configurations where the directory in which

Re: [DNSOP] Why new code/old keys? Re: [Ext] Re: sentinel and timing?

> On Feb 8, 2018, at 9:43 AM, Joe Abley 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 >>>