ignoring forwarder zone statements..
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
/Pete
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Re: ignoring forwarder zone statements..
> 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
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: ignoring forwarder zone statements..
>>>
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
>>
> >
> 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
Bingo, at initial testing it appears to work like a charm, even for sub-zones.
thanks !
/Pete
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
