Hello,
as far as I know I can only put one "tkey-gssapi-credential" in the
named.conf. Now at bind 9.8 there is something new:
* Added a "tkey-gssapi-keytab" option. If set, dynamic updates will be
allowed for any key matching a Kerberos principal
in the specified keytab file. "tkey-gssapi-cre
Hi,
I am experiencing problems to get a working forwarding configuration.
I am using BIND 9.3.6-P1 and the server has the global recursion parameter
on. The server is not on a public network (not on Internet -- no access
to root servers).
I have a zone called "example.com" for which th
You're getting a bit confused, because your configuration is complex. Some of
your observations are in contradiction with your disabling of recursion, so I
believe you are partially mistaken.
- You're mixing authoritative and recursive service in one config. This often
leads to confusion.
- You
What should be clear to all (DNSSEC) administrators is that it is useless
to sign *your* zone(s) if they refer to other, non-signed, zones
themselves !
The danger is that the attacker will not try to cache poison your CNAME,
but the final destination A record !
Cache poisoning - Dan Kaminsky style
Hello,
I have in fact the following problem:
The AXFR is not triggered by a “rndc reload”, neither a stop/start of bind9.
è nothing is seen in the logs
The AXFR is triggered by a “rndc reload zonename”.
=> logs of the master
pr 19 17:32:03 dnscustmaster901 named[5672]: cli
On 4/19/2011 11:42 AM, hugo hugoo wrote:
Hello,
I have in fact the following problem:
The AXFR is not triggered by a “rndc reload”, neither a stop/start of
bind9.
ènothing is seen in the logs
The AXFR is triggered by a “rndc reload zonename”.
=> logs of the master
pr 19 17:32:03 dnscustmast
In my example, the serial number is greater in the master than the serial
number in the slave.
So a zone transfer must be done but it is not done after a "rdnc reload" or a
"start/stop".
The zone transfer is directly done after a "rndc reload zonename"
How can I go on investigating what happ
I have had 2 reports now of people using BIND 9.8.0 on FreeBSD compiled
against openssl 1.0.0d not being able to chroot unless they copy
$PREFIX/lib/engines/libgost.so into the chroot environment.
Traditionally, copying libs into the chroot directory has not been
necessary, so I'm curious. Buil
hugo hugoo wrote:
> How can I go on investigating what happens?
In your previous message you listed these nameservers in the zonefile:
bind9testcarlos.be. 86400 IN NS ns.uat.
bind9testcarlos.be. 86400 IN NS ns2.uat.
Is the slave server you're having problems with
On Tue, 19 Apr 2011, Doug Barton wrote:
I have had 2 reports now of people using BIND 9.8.0 on FreeBSD compiled
against openssl 1.0.0d not being able to chroot unless they copy
$PREFIX/lib/engines/libgost.so into the chroot environment. Traditionally,
copying libs into the chroot directory has
In message <4dadfb29.6080...@dougbarton.us>, Doug Barton writes:
> I have had 2 reports now of people using BIND 9.8.0 on FreeBSD compiled
> against openssl 1.0.0d not being able to chroot unless they copy
> $PREFIX/lib/engines/libgost.so into the chroot environment.
> Traditionally, copying li
On 20 Apr 2011, at 01:11, Mark Andrews wrote:
> In message <4dadfb29.6080...@dougbarton.us>, Doug Barton writes:
>> I have had 2 reports now of people using BIND 9.8.0 on FreeBSD compiled
>> against openssl 1.0.0d not being able to chroot unless they copy
>> $PREFIX/lib/engines/libgost.so into t
12 matches
Mail list logo