Package: bind9 Version: 1:9.10.3.dfsg.P4-6 Architecture: i386 Severity: important
Discussion of this issue can be found at http://bind-users-forum.2342410.n4.nabble.com/Single-slave-zone-definition-for-two-view-cache-file-name-problem-td12.html https://www.linuxquestions.org/questions/linux-server-73/bind-9-10-same-zone-in-two-views-4175572231-print/ Like many people running split DNS (multiple views), a large number of my zones are common to the two. So when setting this up, I did the obvious thing: zone "internal" { match-clients { ... }; recursion yes; include "/etc/bind/named.conf.default-zones"; include "/etc/bind/zones.rfc1918"; include "/etc/bind/named.conf.common"; /* Zones private to this view */ }; zone "external" { match-clients { any; }; recursion no; include "/etc/bind/named.conf.default-zones"; include "/etc/bind/zones.rfc1918"; include "/etc/bind/named.conf.common"; /* Zones private to this view */ }; Where named.conf.common contains various zones my name server is authoritative for, and some zones it is secondary for like like: zone "foo" { type slave; file "/etc/bind/cache/db.cache.foo"; masters { foo_name_servers; }; allow-transfer { any; }; }; While comments from the BIND maintainers suggest that it may have been buggy, it was a sensible thing to do and worked for many years. BIND 9.10 now detects this and fails to start, producing error messages like: Apr 4 20:55:00 ns named[27115]: /etc/bind/named.conf.common:81: writeable file '/etc/bind/cache/db.cache.foo': already in use: /etc/bind/named.conf.common:81 Needless to say, named not starting leads to complete DNS failure and is a pretty unhappy state to upgrade to. (Thus the "Severity: important".) At first, I thought this was a bug (how can a config file line conflict with itself?), but then I realized that the conflict was between the two views. There does not appear to be any simple workaround. The best solution appears to be to use the new BIND 9.10 "in-view" feature, which allows a zone in one view to be a reference to the same zone in a different view. When this is done, both views may share the same cache file. The down side is that this violates one of the important principles of programming: only specify something in one place. Instead, I have to have a "master" definition and several "in-view" declarations referencing the master. I wish BIND would either deal with the problem after noticing it (by automatically doing the equivalent of the in-view), or provide a way to import every zone in a view, avoiding the need for a long list of in-view declarations. In case it helps anyone else, here's my current workaround: One file declares a non-published view "common" as follows: view "common" { match-clients { none; }; zone "foo" { ... }; ... }; Then I use the following sed script on that file (which relies on each "zone" header being on a line by itself, preceded by a tab) # Script to convert each zone in a view to a series of in-view declarations 1i\ // Automatically generated by Makefile and in-view.sed\ // MANUAL EDITS WILL BE LOST /^ zone/{ a\ in-view "common";\ }; p } And I created a Makefile that applies the recipe sed -n -f in-view.sed $< > $@ to produce a series of references that can then be included within each view: zone "foo" { in-view "common"; };
