ignoring forwarder zone statements..

Pete Vickers pete at systemnet.no
Mon Jul 26 18:27:18 UTC 2010


> 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).



/Pete









More information about the bind-users mailing list