for each PTR in a /64.
/Stephan
--
Stephan Lagerholm
Senior DNS Architect
Secure64 Software Corporation
Cell: 469-834-3940
-Original Message-
From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf
Of Doug Barton
And a revoked key with flag 385 as the high level design calls for RFC
5011 compatible rollovers.
/S
--
Stephan Lagerholm
Senior DNS Architect, M.Sc. ,CISSP
Secure64 Software Corporation, www.secure64.com
Cell: 469-834-3940
key
would be a much better fit. DNSSEC itself would be a strong candidate
here.
Thanks, S
--
Stephan Lagerholm
Senior DNS Architect, M.Sc. ,CISSP
Secure64 Software Corporation, www.secure64.com
Cell: 469-834-3940
-Original
--
Stephan Lagerholm
Senior DNS Architect, M.Sc. ,CISSP
Secure64 Software Corporation, www.secure64.com
Cell: 469-834-3940
-Original Message-
From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf
Of
George Barwood
Sent: Wednesday, June 30, 2010 5:37 AM
--
Stephan Lagerholm
-Original Message-
From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf
Of
Joe Abley
Sent: Thursday, September 30, 2010 4:47 AM
To: George Barwood
Cc: IETF DNSOP WG
Subject: Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust
-Original Message-
From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf
Of
George Barwood
Sent: Thursday, November 11, 2010 4:15 PM
To: Rickard Bellgrim; dnsop@ietf.org
Subject: Re: [DNSOP] Comments on DS Publication draft
- Original Message -
From:
Richard and George,
-Original Message-
From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf
Of
Rickard Bellgrim
Sent: Thursday, November 11, 2010 8:32 PM
To: George Barwood
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] Comments on DS Publication draft
On 12 nov
Antoin Verschuren wrote:
I have read the draft, and I have given it some thought.
Though I advocate a child-parent signalling method for key roll-overs,
I
think this is not the correct way forward, and I'll explain why.
As a registry for .nl we have decided not to accept DS records from
On Thursday, July 21, 2011 9:36 AM Antoin Verschuren wrote:
On 21-07-11 14:15, Stephan Lagerholm wrote:
I suggested to use another flag for the DNSKEY a few months ago here.
The
reaction from the list was that it was too complicated because the
key-id
would change during the lifetime
Mark,
On 12.04.2012, at 14:21, Marc Lampo wrote:
It holds an alternative possibility to overcome the problem
- for operators of validating name servers - of failing domains
because of DNSSEC.
The alternative is to have a parent regularly (no frequency defined)
check the coherence of
Mark Andrews Thursday, April 12, 2012 6:10 PM:
On 12.04.2012, at 14:21, Marc Lampo wrote:
It holds an alternative possibility to overcome the problem
- for operators of validating name servers - of failing domains
because of DNSSEC.
The alternative is to have a parent
Mark Andrews, Thursday, April 12, 2012 11:43 PM:
-Original Message-
From: Mark Andrews [mailto:ma...@isc.org]
Sent: Thursday, April 12, 2012 11:43 PM
To: Stephan Lagerholm
Cc: Ralf Weber; Marc Lampo; Nicholas Weaver; dnsop@ietf.org;
Livingood,
Jason
Subject: Re: [DNSOP] on Negative
Patrik Fältström, Sunday, April 15, 2012 1:34 AM:
...and my point is that the effort should be spent on convincing ATT,
Cox and others to do validation just like Comcast. And to inform the
users, press and others that for example it was NASA and not Comcast
that had problems.
Convincing
David Conrad, Sunday, April 15, 2012 11:15 AM:
I suspect that in most cases, grepping through logs and comparing past
(validated) results with current (unvalidated) results can provide
sufficient information to ensure to an arbitrary level of certainty
that the bad thing either is or is not
Warren Kumari, Monday, February 18, 2013 4:36 PM:
Hi all,
This is a compilation of two earlier drafts, draft-barwood-dnsop-ds-
publish and draft-wkumari-dnsop-ezkeyroll.
The basic idea remains the same -- allow operators to publish new (and
standby) DS records at the parent by publishing
Friday, March 01, 2013 11:58 AM Tony Finch wrote:
I'm hoping to avoid yet another too-large RRset that could cause
problems in abuse situations.
Hmm, I wonder if it would be enough to put only the key tag in the CDS
RDATA,
That wouldn't work because you might have two keys with exactly
Tony Finch Friday, March 01, 2013 12:38 PM:
Friday, March 01, 2013 11:58 AM Tony Finch wrote:
Hmm, I wonder if it would be enough to put only the key tag in the
CDS RDATA,
That wouldn't work because you might have two keys with exactly the
same key-tag. You can't be certain that
17 matches
Mail list logo
