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 comp
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
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 thi
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 flo
Hello Evan,
Evan Hunt 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 thou
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
uns
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
[mailto:bind-users-bounce
> 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, t
Hi Evan,
Evan Hunt 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.
>
> ..
On 06/03/14 08:53, Tony Finch wrote:
Jason Hellenthal 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 caus
Jason Hellenthal 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 symptom.
dnssec-keyg
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 e
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 dnsse
13 matches
Mail list logo