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.
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 the
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.
-
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
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]:
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
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 happens?
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.
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
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 libs
On 20 Apr 2011, at 01:11, Mark Andrews ma...@isc.org 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
12 matches
Mail list logo
