2

I have recently begun upgrading to bind 9.9.7 and have run into an unfortunate stumbling block with bind.

I setup views in my environment to allow me to differentiate 4 of my zones with different IP addresses based on where the host is running a query from. The other 36 zones I serve do not differentiate IP addresses, but rather should always serve out the same address for each host. To accomplish this, I created a separate list of hosts which then I used an include directive in the named.conf to include those entries in both zones. Here's a short example of the configuration I have been running with on one of my slave servers:

First, a snippet of my named.conf

view "sitea" {
   match-clients {192.168.1.0/24;};
   zone "mydomain.com." IN {
      type slave;
      masters { 192.168.1.100;};
      file "sitea_mydomain.com.db";
   };
   include "/etc/common_zones.conf";
};

view "siteb" {
   match-clients {any; };
   zone "mydomain.com." IN {
      type slave;
      masters {192.168.1.100; };
      file "mydomain.com.db";
   };
   include "/etc/common_zones.conf";
};

And a snippet from the common_zones.conf file:

zone "1.168.192.in-addr.arpa." IN {
   type slave;
   masters {192.168.1.100;};
   file "192.168.1.db";
};

In the time before, bind was perfectly cool with using the same file twice within the view construct, but now it is not. Having a zone file listed twice in two different views causes an error that specifically tells you that bind will not allow this configuration. In this case it tells me it will not start because I have used a duplicate file 192.168.1.db. Specifically the error message is:

writeable file '192.168.1.db': already in use: /etc/common_zones.conf

The problem I have with this is in my real world, I have over 40 zones (reverse zones) that despite the view they come from, they will always be the same answer no matter what. Being able to use a general include as shown above was a wonderful way to allow me to differentiate a few hosts for the domain "mydomain.com". Now, I am faced with possibly needing to have to enter in 40 zones in each view, each pointing to a different file despite the fact that the data is identical.

Does anyone have a clever solution for this?

5
  • This appears to be dynamic DNS related, as with allow-update { none; }; BIND 9.9.7-P2 is cool with this include style, but not if I instead put in an update-policy configuration for the thus shared zones.
    – thrig
    Sep 2, 2015 at 20:06
  • That's what I had thought too, but even explicitly telling it not to allow updates, it still refuses to run with that configuration. I understand the issue, in that two slave zones sharing the same file that get updates from the master - I get the conflict, but darn it, this used to work.
    – Eirik Toft
    Sep 2, 2015 at 21:51
  • Hmm. That be a right square pickle you've got there. Hacks and kluges only come to mind, such as running two different servers, or such?
    – thrig
    Sep 2, 2015 at 23:14
  • @EirikToft It didn't refuse this type of misconfiguration, but it didn't work properly to set it up that way. I think that is actually an important distinction. Sep 3, 2015 at 8:16
  • Can you symlink the files so that they look different to the parser? Sep 3, 2015 at 13:24

2 Answers 2

3

If upgrading to Bind 9.10 is a possibility, the "in-view" statement would solve this perfectly ( http://www.zytrax.com/books/dns/ch7/zone.html#in-view ).

However, if that's not possible, I noticed something quite interesting that I did not know while looking up "in-view". For slave zones, the "file" parameter (it happens to immediately precede "in-view" in the above link) is optional. This might be just the solution you're looking for. I'm assuming the zone would exist only in RAM and get retransferred every time the slave restarted or reloaded the zone. It's worth a shot. (Edit: You'd still need 2 versions of your common file, one for masters with file names, and one without - so this isn't quite a perfect solution)

3
  • That's a great suggestion. I did try that, but as you well stated, it still requires I keep two separate copies of the shared common file. This is the one thing I have been trying to avoid having to do. The big issue is that my older version of Bind should not have allowed me to do what I'm doing now - but it did, and now I'm spoiled. :)
    – Eirik Toft
    Sep 3, 2015 at 15:50
  • @EirikToft Does that mean that proper operation is secondary to the desire to reuse the exact same zone definitions? (That seems to be the implication of having been spoiled by something that didn't really work right.) Sep 3, 2015 at 16:24
  • 1
    After re-reading everything, I'm not certain there's any more maintenance that would be required. It appears that your common file is only tailored for the slaves anyway ("type slave;" in the zones). . . . And welcome to BIND, please leave hopes of upward compatibility at the door! LOL Sep 3, 2015 at 17:21
1

Perhaps with a named.conf configuration of:

view "sitea" {
  include "/etc/common_zones.conf";
  match-clients {localhost; ...; };
};
view "siteb" {
  include "/etc/UNcommon_zones.conf";
  match-clients {any;};
};

And then common_zones.conf is what it currently is, while over in UNcommon_zones.conf you put in forwarders:

zone "..." IN {
  type forward;
  forward only;
  forwarders { 127.0.0.1; };
};

which at least does not error out in quite limited testing with a test virt pulling a master zone and another test virt issuing queries to said test slave NS.

2
  • That's a good suggestion. The one thing I have been trying to accomplish is to not have to create multiple "shared" zone configurations - and rather be able to share the same one between views.
    – Eirik Toft
    Sep 3, 2015 at 15:51
  • Forwarding will only work for recursion requests (queries with RD set), meaning it's entirely dependent on the specific scenario if this approach works at all. Then there's the inefficiency of forwarding, for the scenario where it does work. Sep 3, 2015 at 16:15

You must log in to answer this question.

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