ation.
>
> This advice may be misunderstood. Use of dlv.isc.org is usually
> implied, not explicitly stated in named.conf, typically via
>
> dnssec-lookaside auto;
>
> (or "yes"). This should (most probably) be changed to
>
> dnssec-lookaside no;
>
&g
amed.conf, typically via
dnssec-lookaside auto;
(or "yes"). This should (most probably) be changed to
dnssec-lookaside no;
I don't have the cross-reference of what the default value has been
for this option up through the history of BIND, so explicitly setting
it to "no&qu
We apparently let our signatures on dlv.isc.org expire. We are fixing it now.
We apologize for this.
This was an accident - we did *not* do this on purpose - but infact, this is a
good time for anyone who still has dlv.isc.org configured to REMOVE it from
your BIND configuration. The zone is
Hello,
I unfortunately got hit by the key expiration or whatever just happened about
an hour ago that caused the "dnssec-lookaside auto" command to crush all of our
DNS queries.
I realize that it wasn't doing anything but we left the command in there
because i
-lookaside auto. Lo and behold, everything works
fine.
And the contents of /etc/bind.key are? Also the contents in the
chroot area if you are using chroot.
Changed /etc/bind.keys to /etc/bind/bind.keys, via config (and it reeds
it, you can see in logs). Contents were given
#53
After some googling and finding
http://www.mail-archive.com/bind-users@lists.isc.org/msg06660.html
and even better
http://www.mail-archive.com/bind-users@lists.isc.org/msg05689.html
I've changed to dnssec-lookaside auto. Lo and behold, everything works fine.
However, this presents the following
-users@lists.isc.org/msg05689.html
I've changed to dnssec-lookaside auto. Lo and behold, everything works fine.
dnssec-lookaside auto just imports the managed-keys statement from
[source-tree]/bind.keys. Compare that carefully with your explicit
managed-keys statement.
We are using managed-keys
-archive.com/bind-users@lists.isc.org/msg06660.html
and even better
http://www.mail-archive.com/bind-users@lists.isc.org/msg05689.html
I've changed to dnssec-lookaside auto. Lo and behold, everything works fine.
And the contents of /etc/bind.key are? Also the contents in the
chroot area
;
dnssec-lookasideauto;
blackhole { bogon; };
};
// Authentication for communicating with rndc --- only listen on the
loopback
// port 953 for control connections
key rndc-key {
algorithm hmac-md5;
secret MrCkB0CphF4MKmcTY5q/9Q==;
};
controls {
inet
Is there a way of using dnssec-lookaside and forcing bind not to
maintain a managed-keys-zone for certain views?
Sure, just do it the old way, without dnssec-lookaside auto.
Put these in the view statement:
dnssec-lookaside . trust-anchor dlv.isc.org;
trusted-keys
On 18/07/2010 17:58:15, Evan Hunt wrote:
Is there a way of using dnssec-lookaside and forcing bind not to
maintain a managed-keys-zone for certain views?
Sure, just do it the old way, without dnssec-lookaside auto.
Put these in the view statement:
dnssec-lookaside . trust-anchor
On Sun, Jul 18, 2010 at 3:28 PM, Matthew Seaman
m.sea...@infracaninophile.co.uk wrote:
Think I'll just drop the external-chaos view. Some script kiddie
working out I'm running the latest version of bind is likely to be lower
risk and a lot less harmful than dealing with broken dnssec chains of
On 07/18/10 12:28, Matthew Seaman wrote:
Think I'll just drop the external-chaos view. Some script kiddie
working out I'm running the latest version of bind is likely to be lower
risk and a lot less harmful than dealing with broken dnssec chains of trust.
I agree, and to take it one step
to use DLV without having a managed-keys zone created at all.
In 9.7.1 and above, you can use managed-keys statements at the view level
as well as globally. (This was a known limitation in 9.7.0.) You can also
use dnssec-lookaside auto at the view level.
You'll want to set a managed-keys
14 matches
Mail list logo
