FYI: zones created using "rndc addzone" could temporarily fail to inherit option "allow-transfer"

Michael McNally mcnally at isc.org
Fri Dec 15 19:35:26 UTC 2017


We recently received a bug report that newly-added zones (via rndc
addzone) were not inheriting the global allow-transfer directive
and could be transferred using AXFR by anyone able to access the
server to which they had just been added.

Further investigation revealed that the circumstances when this
might occur are very specific, transient, and unlikely to affect
most production environments.  However since we're now aware of
this defect we decided that it would be in the best interests of
our users to share this knowledge so that administrators can judge
whether or not they need to be concerned.

We assessed the effects of the defect and concluded that it does
not meet our policy criteria for handling as a security defect:
https://kb.isc.org/article/AA-00861/

It will be fixed in upcoming releases of BIND:
9.12.0, 9.11.3, 9.10.7, 9.9.11

4836.    [bug]    Zones created using "rndc addzone" could
               temporarily fail to inherit an "allow-transfer"
               ACL that had been configured in the options
               statement. [RT #46603]

BIND administrators need only take notice if they are dynamically
adding zones to views (including the default view) that are completely
empty of zones (no zones via named.conf, and no dynamic zones added
earlier) when named is started.

The effect of this bug is that when a zone is being added dynamically,
named fails to check for and initialize the view option 'allow-transfer'
if this had not already been done previously.  This would be unusual
in most production implementations because view initialization takes
place either when named starts up and loads its already-configured
zones, or when named processes 'rndc reload' or 'rndc reconfig'
control commands for non-empty views.

Additionally, if the dynamic zones are added with their own
zone-specific 'allow transfer' option, then this option will be
properly applied for that zone (but this does not mitigate the bug
for any other zones added without a zone-specific ACL).

In summary, this defect will only affect you if you:
 - Start named with no zones at all in some/all views
 - After named has started, add zones to empty views using 'rndc addzone'
 - Rely on dynamic zones inheriting the global or view-specific
   'allow-transfer' directive rather than specifying it for each zone
 - Don't afterwards issue 'rndc reconfig' or 'rndc reload', or restart named

One further consideration is whether or not it matters that the zones
are temporarily available for zone transfer.

ISC would like to thank Andrew Parnell at easyDNS and Dave Knight
at Snake Hill Labs for bringing this bug to our attention.

Sincerely,
ISC Support


More information about the bind-users mailing list