On Thu, Mar 06, 2014 at 08:55:28AM +0100, Carsten Strotmann wrote:
I agree that it might be nice to change dnssec-keygen to make the tool
more userfriendly. The current state-of-things is because of historic
developments in how DNSSEC came to birth.
...and lots of people dealing with
Nothing is ever set in stone that hard. Sorry they wrote scripts for it. All
apologies they decided to use Elmer's glue instead of high tensile strength
super carbon based cement. They will just have to amend those temp scripts with
some test cases or you can write a compatibility shim with an
Jason Hellenthal jhellent...@dataix.net wrote:
I recall spending a LOT of time with DNSSEC figuring out all the
nonsense but like anything else stability and friendliness has to start
somewhere. And development should not be impeded by adoption of bad
practices. Fix the root cause not the
On 06/03/14 08:53, Tony Finch wrote:
Jason Hellenthal jhellent...@dataix.net wrote:
I recall spending a LOT of time with DNSSEC figuring out all the
nonsense but like anything else stability and friendliness has to start
somewhere. And development should not be impeded by adoption of bad
Hi Evan,
Evan Hunt e...@isc.org writes:
On Thu, Mar 06, 2014 at 08:55:28AM +0100, Carsten Strotmann wrote:
I agree that it might be nice to change dnssec-keygen to make the tool
more userfriendly. The current state-of-things is because of historic
developments in how DNSSEC came to birth.
there could be a hard-link from a name like tsig-keygen to
dnssec-keygen which changes the type of key created to -n HOST. That
would not require any change to the existing interface. Just an idea.
Thanks, Carsten. I had actually had the same thought after writing my post
last night, though I
At the time of posting this question, I didn't think that this thread will
cause this much of discussion. :)
Thanks to all for nice explanation and help.
Regards,
Gaurav Kansal
-Original Message-
From: bind-users-bounces+gaurav.kansal=nic...@lists.isc.org
On Feb 19 2014, Alan Clegg wrote:
On 2/19/14, 8:59 PM, Chris Thompson wrote:
What is the right way ... or maybe I should be asking IS there a right
way ... to change a zone that has been signed by inline signing (i.e. with
inline-signing yes; auto-dnssec maintain; in it zone statement) to
Hello Evan,
Evan Hunt e...@isc.org writes:
there could be a hard-link from a name like tsig-keygen to
dnssec-keygen which changes the type of key created to -n HOST. That
would not require any change to the existing interface. Just an idea.
Thanks, Carsten. I had actually had the same
Thanks - I have now tried that (set the deletion date to now with
dnssec-settime), and it does work. You end up with a [zone-file].signed
which is not actually signed being served, but being maintained from
[zone-file] in an incremental way.
I suppose this is indeed the way to go with the flow
On Mar 6 2014, Graham Clinch wrote:
Thanks - I have now tried that (set the deletion date to now with
dnssec-settime), and it does work. You end up with a [zone-file].signed
which is not actually signed being served, but being maintained from
[zone-file] in an incremental way.
I suppose this
Hi Chris co,
Using 9.9.5, I get messages exactly like that
when updating the unsigned zone file while there are no keys.
Thanks for the confirmation - I've logged bind9 bug #35502
inline-signed zone, with no keys, does not synchronise changes made in
master file.
Back on topic - I didn't
Hello
We are facing a similar problem by getting an intermittent SERVER FAILS on
several domains and specifically during the high traffic.
Please note that the IPV6 dual stack is not configured in the Operating
system and we are not using any IPV6 option in the BIND configuration file.
1- We
13 matches
Mail list logo
