...
The lack(?) of a registry is indeed regrettable.
However, there seems to be some historical meaning attached to some of
the other flag bits.
If I look back at Net::DNS::SEC 0.17, bequeathed to me by one Olaf
Kolkman, the DS create() method contains the following mysterious
(perl) lines, for which I can
On 21 okt. 2013, at 17:29, Tim Wicinski tim.wicin...@teamaol.com wrote:
Please review this draft to see if you think it is suitable for adoption by
DNSOP,
and comments to the list, clearly stating your view.
I support adoption although that feels like a formality: Since most responders
to
Dear Chairs,
Some friendly reminders...
On May 21, 2012, at 11:40 AM, Olaf Kolkman wrote:
Chairs, would you like us to incorporate (some of, see comments from Paul H.)
the suggestions in the document _now_ or after you have done your review?
This question has been left unanswered
Thanks for the very detailed review!
Due to family circumstances I cannot be at the dnsop meeting and I will not
have time to review all the points you made before thursday.
However, since you highlighted this point in the hallway, I would like to ask
the working group for guidance.
4.1
On Sep 30, 2010, at 3:03 PM, Matthijs Mekking wrote a long mail starting with:
On the dnssec-deployment list, the Signed TLD status thread [1] evolved
into a discussion how algorithm rollover works in specific use cases. My
feeling is that this discussion belongs to DNSOP and so I want to
On Jul 27, 2010, at 11:31 AM, Jelte Jansen wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
the introduction suggests that the root has not been signed yet.
;-)
In version 05, to appear before the cut-off it reads:
At the time of writing -the root has just been
signed and
Clearly I am trying to get a (hopefully WG last call ready) version 05 of the
document out by the deadline.
Some comments in-line based on specific feedback you provided.
On Aug 5, 2010, at 9:43 AM, Matthijs Mekking wrote:
The KSK RFC5011-based rollover method says that the removed key
Colleagues,
Shortly before the cutt-off I submitted version 3.
In this mail I want to raise a number of points that are up for discussion in
Maastricht (or on the list). For the Maastricht meeting I plan to use _no_
slides but go through the points one by one and discuss/hum etc.
20, 2010, at 8:34 PM, Paul Wouters wrote:
On Sat, 20 Mar 2010, Olaf Kolkman wrote:
- http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/NSEC-NSEC3
That still states:
as well as no algorithm choice for SHA-256
That's been resolved now, see http://www.bind9.net/dns-sec
On Jul 8, 2010, at 7:53 PM, bmann...@vacation.karoshi.com wrote:
On Thu, Jul 08, 2010 at 11:39:33AM +0200, Olaf Kolkman wrote:
I observe though that 4641 is mainly written from the perspective of a
'zone-owner' and that I am not quite sure where to give specific advice to
administrators
On Jun 24, 2010, at 11:59 AM, George Barwood wrote:
It could also note that validators SHOULD NOT check the RRSIG for a DNSKEY
RRset
where all the keys are validated by DS records.
This document (4641-bis) is supposed to give operational guidance only.
Implementation guidance for
On Jun 16, 2010, at 5:25 PM, John Dickinson wrote:
Hi,
Sorry for the very late reply to this issue.
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_configuration
Paul asked for proper use of 5011 to be added to 4641bis. I agree, In fact
could we go further and
You probably noticed I swapped in the document and tackling issues one-by-one.
On Mar 20, 2010, at 8:51 PM, Chris Thompson wrote:
On Mar 20 2010, Paul Wouters wrote:
On Sat, 20 Mar 2010, Olaf Kolkman wrote:
- http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/NSEC-NSEC3
On Mar 24, 2010, at 11:19 PM, Patrik Fältström wrote:
General comment:
The document is not clear enough regarding the roles of the registrant, dns
operator, registrar and registry -- where the dns operator is in the document
implied to be the one that hold the private keys. Further, the
On Jun 17, 2010, at 11:15 PM, Olafur Gudmundsson wrote:
Currently section 3 of the document mandates that all zones be signed using
the KSK+ZSK model, I content this is outdated advice.
Version 02 of the draft offers the choice. And in fact it starts of by saying
(in 3.1 second paragraph)
/NSEC-NSEC3
Complete new section 5.
There is one remaining point there brought up in
From: Florian Weimer fwei...@bfk.de
Subject:Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
Date: February 22, 2010 11:20:16 PM PST
To: Olaf Kolkman o...@nlnetlabs.nl
On Feb 23, 2010, at 8:20 AM, Florian Weimer wrote:
* Olaf Kolkman:
5.3.3. NSEC3 Salt
The salt with NSEC3 is not used to increase the work required by an
attacker attacking multiple domains, but as a method to enable
creating a new set of hash values if at some point that might
can be found below.
--Olaf
--On 22 January 2010 12:04:07 +0100 Olaf Kolkman o...@nlnetlabs.nl wrote:
Strawman text said:
Though some claim all data in the DNS should be considered public, it
sometimes is considered to be more then private, but less then public
data.
That does
On Feb 17, 2010, at 4:03 PM, Paul Wouters wrote:
On Wed, 17 Feb 2010, Olaf Kolkman wrote:
Though all agree DNS data should be accessible through query
mechanisms, a side effect of NSEC is that it allows the contents of a
zone file to be enumerate in full by sequential query. Whilst
On Jan 21, 2010, at 6:52 PM, Paul Wouters wrote:
On Thu, 21 Jan 2010, Olaf Kolkman wrote:
In trying to get a reasonable version 2 out of the door before Anaheim I am
trying to identify and where possibly close open issues.
As a reminder: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open
In trying to get a reasonable version 2 out of the door before Anaheim I am
trying to identify and where possibly close open issues.
As a reminder: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ has
the open issues listed and a per issue highlight of their history.
This thread,
As a reminder: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ has
the open issues listed and a per issue highlight of their history.
This issue is captured in
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ZSK-roll-frequency
current content of that page is replicated
, 2010 at 5:28 AM, Olaf Kolkman o...@nlnetlabs.nl wrote:
As a reminder: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ has
the open issues listed and a per issue highlight of their history.
This issue is captured in
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ZSK-roll
On Jan 21, 2010, at 5:28 PM, Tony Finch wrote:
On Thu, 21 Jan 2010, Olaf Kolkman wrote:
I understand EKR's remark (thanks) in addition to the improvement Scott
suggested there is the argument that if a rollover remains a special
event it is bound to go wrong, while if it is part of regular
On Oct 7, 2009, at 2:44 PM, Eric Rescorla wrote:
From this perspective we might roll a ZSK more frequently than a
KSK because
the ZSK needs to be stored on-line to facilitate re-signing when
the zone
changes. With the KSK we have the option of keeping it off-line, and
arguably the risk
On Oct 7, 2009, at 9:23 AM, Olaf Kolkman wrote:
hope I can address a few of the issues before Yokohama.
s/Yokohama/Hiroshima/
Should I call my travel office? ;-)
--Olaf
Olaf M. KolkmanNLnet Labs
On 16 mrt 2009, at 16:34, Paul Hoffman wrote:
It feels like a lot of DNSSEC questions these days are being
answered by that's covered if you use RFC 5011. If so, then maybe
proper use of RFC 5011 (such as when to assume that a zone is
*really* being signed, not just for practice) should
/trunk/open-issues/
Kind regards,
--Olaf Kolkman
PGP.sig
Description: This is a digitally signed message part
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
then, but not now.
--Olaf Kolkman (NLnet Labs)
PGP.sig
Description: This is a digitally signed message part
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
29 matches
Mail list logo
