On 7/26/2010 2:27 PM, Pete Vickers wrote:
On 7/26/2010 1:46 PM, Pete Vickers wrote:
Hi list,
I have a BIND9 server in a non public internet connected network. Most of the \
functionality is working correctly but I have a specific problem.
The server 'resides' in a 3rd level zone ( e.g.
my-ns-server.level3.level2.level1. \
) for which it is SOA& NS, in addition it is slave for the level1 zone.
sample from named.conf:
// slave level1 from masters.
zone "level1" {
type slave;
file "slave/level1";
notify no;
masters { 1.2.3.4; 1.2.3.5; };
};
// forward directly to otherlevel2 due to absence delegation from level1
zone "otherlevel2.level1" {
type forward;
forwarders { 2.3.4.5; 2.3.4.6; };
};
(my root.hint also correctly references the private "." servers)
My problem is that when clients query my server for entries within \
"otherlevel2.level1", instead forwarding the queries directly to the declared \
forwarders, instead my server replies with NXDOMAIN (presumably from the
level1 \
slave data.)
any insight appreciated
Make sure an actual delegation exists from level1 to otherlevel2.level1.
The forwarding logic doesn't know to look for a subzone definition
unless it sees a delegation.
- Kevin
hmm. My problem is that the delegation _doesn't_ exist from level1 to
otherlevel2.level1. That is what I'm try to work around with the forward
statement directly referencing the NSs.
The level1 zone is politically immutable, so fixing the problem there is not an
option. Any other ideas ? (being a slave of the otherlevel2.level1. zone is
also not practical).
Politics has left you with precious few options. One of them is to
define otherlevel2.level1 as a "stub" zone. If that zone has any
descendant zones, you may need to take some special care for them to be
resolvable as well.
- Kevin
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
