On 10/5/2011 10:25 AM, michoski wrote:
Your initial hope is what I missed comments on...
Me too; didn't get any that's horribly broken because or any that
looks good feedback, guess I'll just have to review it a couple more
times and hope for the best.
It is recommended that the transition
On Tue, Oct 04, 2011 at 03:49:25PM -0700,
Paul B. Henson hen...@acm.org wrote
a message of 40 lines which said:
Other than knowing a given domain had an issue, you have no idea
what caused it, or what tool they may have been using, and it is
only an assumption that the issue arose from a
On 10/4/11 3:49 PM, Paul B. Henson hen...@acm.org wrote:
dnssec is fairly complicated, and the issue of timing can be complex,
but once the variables are determined than the actual procedures of
implementation are pretty simple. Generate keys with appropriate
publication, activation,
On Wed, Oct 05, 2011 at 12:22:58AM -0700, Stephane Bortzmeyer wrote:
Not true. For every problem reported by the tool, I contacted the
managers of the domain, both to report they have an issue and to ask
them what system they were using. So, I'm pretty confident that
OpenDNSSEC had no such
On Mon, Oct 03, 2011 at 05:32:18PM -0700,
Paul B. Henson hen...@acm.org wrote
a message of 59 lines which said:
Our zone data is maintained in a revision control repository; when
changes are made there is a process that generates a bind format
zone file from the data, checks it for syntax
On 10/3/2011 6:31 PM, Mark Andrews wrote:
Don't ASSUME that the DS will be published in time. Build checks into
your proceedures from the beginning. e.g.
Publish and activate July 1. Change DS records July 8. Check
that DS is published July 15 and set inactivate and deletion
On 10/3/2011 11:45 PM, Stephane Bortzmeyer wrote:
Experience of DNSSEC deployment (see my paper at SATIN
http://conferences.npl.co.uk/satin/papers/satin2011-Bortzmeyer.pdf)
shows that custom programs have many timing bugs. Many things can go
wrong Why not using an existing program such as
We are getting ready to deploy dnssec, and I'd appreciate a quick sanity
check on our configuration and key timings to make sure I didn't miss
anything that would cause things to blow up ;).
Our zone data is maintained in a revision control repository; when
changes are made there is a process
In message 4e8a5412.7050...@acm.org, Paul B. Henson writes:
We are getting ready to deploy dnssec, and I'd appreciate a quick sanity
check on our configuration and key timings to make sure I didn't miss
anything that would cause things to blow up ;).
Our zone data is maintained in a
9 matches
Mail list logo
