On 21.02.2013 19:20, Nikita Koshikov wrote:
I haven't tested this in detail but here's what I would try:
I'm trying to "cut" /24 network from the scope of /8 network, here is
example:
zone "11.2.10.in-addr.arpa" {
type forward;
forwarders { 192.168.1.23; 192.168.1.24; };
};
zone "10.in-addr.arpa" {
type master;
file "master/int/10.in-addr.arpa";
};
The local authoritative data takes precedence over a forward zone.
10.in-addr.arpa is just a file that returns NXDOMAIN for any 10.0.0.0/8 ip
address. But I need to forward requests for 10.2.11.0/24 net to other dns
servers and the above config not working.
The easiest way might be to delegate the subdomain with a static-stub:
zone "11.2.10.in-addr.arpa" {
type static-stub;
server-addresses { 192.168.1.23; 192.168.1.24; };
};
zone "10.in-addr.arpa" {
type master;
file "master/int/10.in-addr.arpa";
};
This is a "synthetic" delegation. There could be a problem if a client
queries 2.10.in-addr.arpa. The NXDOMAIN response (instead of nodata) can
be interpreted as "*.2.10.in-addr.arpa. doesn't exist". A "real"
delegation in the zone file is probably better.
If your version of BIND is older than 9.8, you could try to move the
master zone into a view and configure 10.in-addr.arpa as another forward
zone in the client's view.
Hauke.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users