Re: do not stupidly delete ZSK files

2015-08-08 Thread Tony Finch
Lawrence K. Chen, P.Eng. wrote: > On 2015-07-31 06:33, Tony Finch wrote: > > > > The DNSSEC records come from the zone data like any other records. You > > don't need any special DNSSEC configuration to act as a secondary for a > > signed zone - it just works. > > Is that the case now? I recall w

Re: do not stupidly delete ZSK files

2015-08-07 Thread Lawrence K. Chen, P.Eng.
On 2015-08-07 09:50, Heiko Richter wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 07.08.2015 um 07:16 schrieb Lawrence K. Chen, P.Eng.: On 2015-08-06 19:26, Heiko Richter wrote: Though back then I was still building bind 32-bit, and the hardware as much slower. A full signing was

Re: do not stupidly delete ZSK files

2015-08-07 Thread Heiko Richter
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 07.08.2015 um 07:16 schrieb Lawrence K. Chen, P.Eng.: > > > On 2015-08-06 19:26, Heiko Richter wrote: > >>> Though back then I was still building bind 32-bit, and the >>> hardware as much slower. A full signing was more than 10x >>> longer than

Re: do not stupidly delete ZSK files

2015-08-06 Thread Lawrence K. Chen, P.Eng.
On 2015-08-06 19:26, Heiko Richter wrote: Though back then I was still building bind 32-bit, and the hardware as much slower. A full signing was more than 10x longer than our current hardwarewhich can get it done in just under a minute. (usually) The need for speed is some people expect

Re: do not stupidly delete ZSK files

2015-08-06 Thread Casey Deccio
On Thu, Aug 6, 2015 at 7:55 PM, Lawrence K. Chen, P.Eng. wrote: > Ok, so way back thenthey were running servers that didn't support > NSEC3 RRs and it had nothing to do with what algorithm we were using5 > for RSASHA1 or 7 for RSASHA1-NSEC3-SHA1. > DNSSEC introduces: new records (and typ

Re: do not stupidly delete ZSK files

2015-08-06 Thread Heiko Richter
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 07.08.2015 um 03:36 schrieb Carl Byington: > -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > > On Fri, 2015-08-07 at 02:46 +0200, Heiko Richter wrote: >> Sadly automated KSK rollover isn't supported by most registrars, > > Yes, but I only need one

Re: do not stupidly delete ZSK files

2015-08-06 Thread Carl Byington
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 2015-08-07 at 02:46 +0200, Heiko Richter wrote: > Sadly automated KSK rollover isn't supported by most registrars, Yes, but I only need one registrar to support it :) I have python code that uses the gkg.net API to do automated KSK generation

Re: do not stupidly delete ZSK files

2015-08-06 Thread Heiko Richter
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 07.08.2015 um 02:35 schrieb Dave Warren: > On 2015-08-06 17:26, Heiko Richter wrote: >> Root is signed with RSASHA256 at the moment. There is no sence in >> having a more secure algorithm because anybody who can't crack that >> algorithm may just at

Re: do not stupidly delete ZSK files

2015-08-06 Thread Dave Warren
On 2015-08-06 17:26, Heiko Richter wrote: Root is signed with RSASHA256 at the moment. There is no sence in having a more secure algorithm because anybody who can't crack that algorithm may just attack the weakest link in the chain above you. This only holds while assuming similar key rotation

Re: do not stupidly delete ZSK files

2015-08-06 Thread Heiko Richter
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 07.08.2015 um 01:55 schrieb Lawrence K. Chen, P.Eng.: > > > On 2015-08-06 17:54, Heiko Richter wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> Am 07.08.2015 um 00:23 schrieb Lawrence K. Chen, P.Eng.: >>> >>> >>> On 2015-07-31 06:3

Re: do not stupidly delete ZSK files

2015-08-06 Thread Lawrence K. Chen, P.Eng.
On 2015-08-06 17:54, Heiko Richter wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 07.08.2015 um 00:23 schrieb Lawrence K. Chen, P.Eng.: On 2015-07-31 06:33, Tony Finch wrote: Most zones have four authoritative nameservers, only one of which I manage. Of the three I don't manage, I

Re: do not stupidly delete ZSK files

2015-08-06 Thread Heiko Richter
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 07.08.2015 um 00:23 schrieb Lawrence K. Chen, P.Eng.: > > > On 2015-07-31 06:33, Tony Finch wrote: >>> Most zones have four authoritative nameservers, only one of >>> which I manage. Of the three I don't manage, I'm pretty sure at >>> least two ha

Re: do not stupidly delete ZSK files

2015-08-06 Thread Lawrence K. Chen, P.Eng.
On 2015-07-31 06:33, Tony Finch wrote: Most zones have four authoritative nameservers, only one of which I manage. Of the three I don't manage, I'm pretty sure at least two have no DNSSEC-specific configuration -- a hint that any DNSSEC records they serve come from this hidden primary. The DN

Re: do not stupidly delete ZSK files

2015-07-31 Thread David Newman
On 7/31/15 4:33 AM, Tony Finch wrote: > David Newman wrote: >> On 7/30/15 10:37 AM, Evan Hunt wrote: >>> On Thu, Jul 30, 2015 at 10:30:33AM -0700, David Newman wrote: Hidden primary (not authoritative for this zone): Key still in zone > > I think what you mean here is that the hidden pr

Re: do not stupidly delete ZSK files

2015-07-31 Thread Tony Finch
David Newman wrote: > On 7/30/15 10:37 AM, Evan Hunt wrote: > > On Thu, Jul 30, 2015 at 10:30:33AM -0700, David Newman wrote: > >> > >> Hidden primary (not authoritative for this zone): Key still in zone I think what you mean here is that the hidden primary is not advertised in the zone's NS RRse

Re: do not stupidly delete ZSK files

2015-07-30 Thread David Newman
On 7/30/15 10:37 AM, Evan Hunt wrote: > On Thu, Jul 30, 2015 at 10:30:33AM -0700, David Newman wrote: >> After that second procedure (and also chown'ing the keyfiles to the bind >> user), the command 'dig +dnssec +multi dnskey example.com' gives >> different results depending on which nameserver ge

Re: do not stupidly delete ZSK files

2015-07-30 Thread Evan Hunt
On Thu, Jul 30, 2015 at 10:30:33AM -0700, David Newman wrote: > After that second procedure (and also chown'ing the keyfiles to the bind > user), the command 'dig +dnssec +multi dnskey example.com' gives > different results depending on which nameserver gets the query: > > Hidden primary (not auth

Re: do not stupidly delete ZSK files

2015-07-30 Thread David Newman
On 7/30/15 9:06 AM, Evan Hunt wrote: > On Wed, Jul 29, 2015 at 07:29:29PM -0700, David Newman wrote: >> It's a static zone. The zone file did not have the key in it. > > ... oh, it's inline-signing. Sorry, I also didn't mention that this is a hidden primary server, which may be relevant below...

Re: do not stupidly delete ZSK files

2015-07-30 Thread Evan Hunt
On Wed, Jul 29, 2015 at 07:29:29PM -0700, David Newman wrote: > It's a static zone. The zone file did not have the key in it. ... oh, it's inline-signing. Unfortunately, by its nature, inline-signing gives you less direct control over the signed side of the zone. There are two ways you can go go

Re: do not stupidly delete ZSK files

2015-07-29 Thread David Newman
On 7/29/15 6:24 PM, Evan Hunt wrote: > On Wed, Jul 29, 2015 at 05:56:20PM -0700, David Newman wrote: >> 29-Jul-2015 17:18:19.439 general: warning: >> dns_dnssec_keylistfromrdataset: error reading private key file >> example.com/RSASHA256/36114: file not found > > Delete that key from the DNSKEY rr

Re: do not stupidly delete ZSK files

2015-07-29 Thread Evan Hunt
On Wed, Jul 29, 2015 at 05:56:20PM -0700, David Newman wrote: > 29-Jul-2015 17:18:19.439 general: warning: > dns_dnssec_keylistfromrdataset: error reading private key file > example.com/RSASHA256/36114: file not found Delete that key from the DNSKEY rrset in the zone and reload. If it's a dynamic

do not stupidly delete ZSK files

2015-07-29 Thread David Newman
I created then loaded then deleted a ZSK, all within an hour, so there's no backup. Yes, that was a dumb thing to do. Now when reloading that zone, named.log complains about the missing ZSK: 29-Jul-2015 17:18:19.439 general: warning: dns_dnssec_keylistfromrdataset: error reading private key file