3

Problem: Separate zones by query source network and return different records for LAN clients compared to WAN clients.

I've implemented this at home on a small alix router with Bind 9.4. One view called "lan" and one view called "wan". The "lan" view had just the root.hints file and one zone.

The "wan" view had many other zones, including a copy of the one zone from the "lan" view, but with different records.

Querying domain1.tld from the LAN would give me local records. Querying domain1.tld from the WAN would give me external records. Querying domain2.tld from the LAN would give me the same records as from the WAN as it only existed in the WAN view.

Now I'm trying to re-implement this on a larger scale and suddenly my view is unable to query anything outside itself. This is natural according to the bind-users list and they suggest I copy all my views into my LAN view.

I'm hoping someone here has a better solution because that means I'll have to copy, and maintain, thousands of zone files in multiple views. This is unfeasible.

My configuration at home resembles this.

acl lanClients {
 192.168.22.0/24;
 127.0.0.1;
};

view "intranet" {
 match-clients { lanClients; };
 recursion yes;
 notify no;

 // Standard zones
 //
 zone "." {
  type hint;
  file "etc/root.hint";
 };

 zone "domain1.tld" {
  type master;
  file "intranet/domain1.tld";
 };
};

view "internet" {
 match-clients { !localnets; any; };
 recursion no;
 allow-transfer { slaveDNS; };

 include "master.zones";
};

Requests from the LAN for domain1.tld give local records, requests from the WAN give remote records. This works fine both at home and in my new Bind 9.7 on a larger scale.

The difference is that at home I have somehow managed to make my LAN get remote records from domains in master.zones, without specifying those zones as duplicates in the "intranet" view.

Trying this on a larger scale with Bind 9.7 I get no results at all except for the zones specified in the view. What am I missing? I've tried the same configuration for Bind 9.7.

1 Answer 1

0

Each view have a separate set of zones, so one view will not answer for zones specified only in another view, thus the behavior you have is somewhat expected. But, once all your WAN zones are properly delegated to your server from the parent zone, intranet view will follow the delegation chain, come back to your own server, and query itself for that zone.

I guess you problem is either - you testing your server, and did not delegate the zones yet, or BIND's source of your queries falls into lanClients ACL and thus creates infinite loop.

The trick is to use query-source 1.2.3.4;, where 1.2.3.4 is some external interface IP which does not fall into lanClients ACL.

Another option is to add forward only; and forwarders 1.2.3.4; to your intranet view - this way delegation chain does not matter, and this will work also behind NAT.

In any case, queries made by bind itself have to be excluded from the lanClients view.

2
  • @Stefan M I don't know if query-source may be specified on per-view basis. If you happen to test it, drop here a line.
    – Sandman4
    Oct 25, 2012 at 13:30
  • I believe you're spot on because I've seen other examples doing what you describe. Namely a separate interface and query-source. Btw after some talking on IRC and the bind-users list I believe the reason my home DNS was working as intended was because it was a hidden master and was forwarding the queries to its slaves so I could get a response for a zone that was not in my LAN view.
    – Stefan M
    Oct 27, 2012 at 13:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .