Lawrence K. Chen, P.Eng. lkc...@ksu.edu 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
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
-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 our current
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
On Thu, Aug 6, 2015 at 7:55 PM, Lawrence K. Chen, P.Eng. lkc...@ksu.edu
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
-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
-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
-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:33, Tony Finch
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
-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 attack
On 7/31/15 4:33 AM, Tony Finch wrote:
David Newman dnew...@networktest.com 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
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 gets the
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
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...
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
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
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 rrset in
17 matches
Mail list logo
