On 12.8.2013 14:30, Loris Santamaria wrote:
El vie, 09-08-2013 a las 16:22 +0200, Petr Spacek escribió:
On 9.8.2013 15:12, Rob Crittenden wrote:
Simo Sorce wrote:
On Fri, 2013-08-09 at 10:42 +0200, Petr Spacek wrote:
On 23.7.2013 10:55, Petr Spacek wrote:
On 19.7.2013 19:55, Simo Sorce
On 9.8.2013 16:22, Petr Spacek wrote:
On 9.8.2013 15:12, Rob Crittenden wrote:
Simo Sorce wrote:
On Fri, 2013-08-09 at 10:42 +0200, Petr Spacek wrote:
On 23.7.2013 10:55, Petr Spacek wrote:
On 19.7.2013 19:55, Simo Sorce wrote:
I will reply to the rest of the message later if necessary,
On 08/09/2013 04:13 PM, Anthony Messina wrote:
On Friday, August 09, 2013 08:49:29 AM Simo Sorce wrote:
Dmitri, Martin and me discussed this proposal in person and the new
plan is: - Elect one super-master which will handle key generation (as
we do with special CA certificates)
I guess we
El vie, 09-08-2013 a las 16:22 +0200, Petr Spacek escribió:
On 9.8.2013 15:12, Rob Crittenden wrote:
Simo Sorce wrote:
On Fri, 2013-08-09 at 10:42 +0200, Petr Spacek wrote:
On 23.7.2013 10:55, Petr Spacek wrote:
On 19.7.2013 19:55, Simo Sorce wrote:
I will reply to the rest of the
On Monday, August 12, 2013 09:34:19 AM Martin Kosek wrote:
On 08/09/2013 04:13 PM, Anthony Messina wrote:
On Friday, August 09, 2013 08:49:29 AM Simo Sorce wrote:
Dmitri, Martin and me discussed this proposal in person and the new
plan is: - Elect one super-master which will handle key
On 23.7.2013 10:55, Petr Spacek wrote:
On 19.7.2013 19:55, Simo Sorce wrote:
I will reply to the rest of the message later if necessary, still
digesting some of your answers, but I wanted to address the following
first.
On Fri, 2013-07-19 at 18:29 +0200, Petr Spacek wrote:
The most important
On Fri, 2013-08-09 at 10:42 +0200, Petr Spacek wrote:
On 23.7.2013 10:55, Petr Spacek wrote:
On 19.7.2013 19:55, Simo Sorce wrote:
I will reply to the rest of the message later if necessary, still
digesting some of your answers, but I wanted to address the following
first.
On Fri,
Simo Sorce wrote:
On Fri, 2013-08-09 at 10:42 +0200, Petr Spacek wrote:
On 23.7.2013 10:55, Petr Spacek wrote:
On 19.7.2013 19:55, Simo Sorce wrote:
I will reply to the rest of the message later if necessary, still
digesting some of your answers, but I wanted to address the following
first.
On Friday, August 09, 2013 08:49:29 AM Simo Sorce wrote:
Dmitri, Martin and me discussed this proposal in person and the new plan
is: - Elect one super-master which will handle key generation (as we do
with special CA certificates)
I guess we can start this way, but how do you determine
On 9.8.2013 15:12, Rob Crittenden wrote:
Simo Sorce wrote:
On Fri, 2013-08-09 at 10:42 +0200, Petr Spacek wrote:
On 23.7.2013 10:55, Petr Spacek wrote:
On 19.7.2013 19:55, Simo Sorce wrote:
I will reply to the rest of the message later if necessary, still
digesting some of your answers, but
On 19.7.2013 19:55, Simo Sorce wrote:
I will reply to the rest of the message later if necessary, still
digesting some of your answers, but I wanted to address the following
first.
On Fri, 2013-07-19 at 18:29 +0200, Petr Spacek wrote:
The most important question at the moment is What can we
I will reply to the rest of the message later if necessary, still
digesting some of your answers, but I wanted to address the following
first.
On Fri, 2013-07-19 at 18:29 +0200, Petr Spacek wrote:
The most important question at the moment is What can we postpone?
How
fragile it can be for
On Tue, 2013-07-16 at 17:15 +0200, Petr Spacek wrote:
On 15.7.2013 21:07, Simo Sorce wrote:
Is there any place I can read about the format and requirements of these
files ?
There is no single format, because it is algorithm-dependent. See below.
AFAIK
it is nothing supported by OpenSSL,
On 15.7.2013 21:07, Simo Sorce wrote:
On Mon, 2013-07-15 at 16:58 +0200, Petr Spacek wrote:
The remaining part is mostly about key management.
Following text mentions 'DNSSEC keys' many times, so I tried to summarize how
keys are used in DNSSEC. Feel free to skip it.
== DNSSEC theory ==
Each
Hello,
first pair of this message quickly concludes discussion about database part of
the DNSSEC support and then key material handling is discussed.
I'm sorry for the wall of text.
On 27.6.2013 18:43, Simo Sorce wrote:
* How to get sorted list of entries from LDAP? Use
On 21.6.2013 16:19, Simo Sorce wrote:
On Thu, 2013-06-20 at 14:30 +0200, Petr Spacek wrote:
On 23.5.2013 16:32, Simo Sorce wrote:
On Thu, 2013-05-23 at 14:35 +0200, Petr Spacek wrote:
It looks that we agree on nearly all points (I apologize if
overlooked
something). I will prepare a design
On Thu, 2013-06-27 at 18:23 +0200, Petr Spacek wrote:
On 21.6.2013 16:19, Simo Sorce wrote:
On Thu, 2013-06-20 at 14:30 +0200, Petr Spacek wrote:
On 23.5.2013 16:32, Simo Sorce wrote:
On Thu, 2013-05-23 at 14:35 +0200, Petr Spacek wrote:
It looks that we agree on nearly all points (I
On Thu, 2013-06-20 at 14:30 +0200, Petr Spacek wrote:
Hello,
On 23.5.2013 16:32, Simo Sorce wrote:
On Thu, 2013-05-23 at 14:35 +0200, Petr Spacek wrote:
It looks that we agree on nearly all points (I apologize if
overlooked
something). I will prepare a design document for transition to
Hello,
On 23.5.2013 16:32, Simo Sorce wrote:
On Thu, 2013-05-23 at 14:35 +0200, Petr Spacek wrote:
It looks that we agree on nearly all points (I apologize if
overlooked
something). I will prepare a design document for transition to RBTDB
and then
another design document for DNSSEC
On 22.5.2013 21:58, Simo Sorce wrote:
On Wed, 2013-05-22 at 17:01 +0200, Petr Spacek wrote:
Wow, it is pretty slow.
Yeah this is what I expected, crypto is not really fast.
[...]
The simplest way how to mitigate problem with slow start-up is:
1) Store signed version of the zone on the
On Thu, 2013-05-23 at 14:35 +0200, Petr Spacek wrote:
It looks that we agree on nearly all points (I apologize if
overlooked
something). I will prepare a design document for transition to RBTDB
and then
another design document for DNSSEC implementation.
ACK
Simo.
--
Simo Sorce * Red
On 21.5.2013 20:30, Simo Sorce wrote:
On Tue, 2013-05-21 at 18:32 +0200, Petr Spacek wrote:
Hello,
I found that we (probably) misunderstood each other. The sky-high level
overview of the proposal follow:
NO CHANGE:
1) LDAP stores all *unsigned* data.
2)
NO CHANGE:
a) bind-dyndb-ldap *on each
On Wed, 2013-05-22 at 17:01 +0200, Petr Spacek wrote:
Right, it is good idea. I never tried really big zone (for some reason?).
Command: /usr/bin/time dnssec-signzone -n 1 -o example.net example.net
Signing was limited to single core (parameter -n 1).
Unsigned zone: 327 285 bytes, ~ 10 000
Hello,
I found that we (probably) misunderstood each other. The sky-high level
overview of the proposal follow:
NO CHANGE:
1) LDAP stores all *unsigned* data.
2)
NO CHANGE:
a) bind-dyndb-ldap *on each server* fetches all unsigned data from LDAP and
store them in *in memory* database (we do
On Tue, 2013-05-21 at 18:32 +0200, Petr Spacek wrote:
Hello,
I found that we (probably) misunderstood each other. The sky-high level
overview of the proposal follow:
NO CHANGE:
1) LDAP stores all *unsigned* data.
2)
NO CHANGE:
a) bind-dyndb-ldap *on each server* fetches all unsigned
On Wed, 2013-05-15 at 17:11 +0200, Petr Spacek wrote:
On 15.5.2013 10:29, Simo Sorce wrote:
I investigated various scenarios for DNSSEC integration and I would like to
hear your opinions about proposed approach and it's effects.
The most important finding is that bind-dyndb-ldap can't
- Original Message -
Hello list,
I investigated various scenarios for DNSSEC integration and I would like to
hear your opinions about proposed approach and it's effects.
The most important finding is that bind-dyndb-ldap can't support DNSSEC
without rewrite of the 'in-memory
On 15.5.2013 10:29, Simo Sorce wrote:
I investigated various scenarios for DNSSEC integration and I would like to
hear your opinions about proposed approach and it's effects.
The most important finding is that bind-dyndb-ldap can't support DNSSEC
without rewrite of the 'in-memory database'
28 matches
Mail list logo
