Why does named log an error '3bf305731dd26307.nzf: file not found' when starting up?

  • Updated on Oct 30, 2018
  • Published on Jan 25, 2018
  • 2 minute(s) read
  • Suzanne Goldlust

This article may not apply to the version of BIND you are using
Starting with versions 9.11.3 and 9.12.0, BIND will no longer log the messages described below.

When named starts under some configurations, it may log a message like:

03-May-2013 18:42:02.807 open: 3bf305731dd26307.nzf: file not found

Why does it do that?  What is an .nzf file and what happens if named can't find one?

Most BIND operators are familiar with the concept of Dynamic DNS, the BIND feature that allows you to add or remove records from existing zones using UPDATE messages.  

There is a similar mechanism by which BIND can also allow entirely new zones to be created (or removed) while a server is running, although it does not  operate using UPDATE messages; rather, it uses the rndc command to pass zone creation and deletion commands to the server.

If the server is configured to allow new zones with the option:

allow-new-zones yes;

then, using the command rndc addzone, a nameserver operator can add a zone to the running server without requiring a restart, reload, or reconfig. The corresponding command, rndc delzone, can remove a zone, but only if it was added using rndc addzone.

Since BIND 9.11, rndc delzone can also act on zones configured in named.conf
Starting with version 9.11.0, rndc delzone is also applicable to zones that were configured in named.conf. Note, however, that if named.conf is not also modified, the deleted zone will return when named is reloaded.

To allow dynamically added zones to persist across a server restart or reconfigure, BIND keeps track of these dynamically added zones in files, one file per view that you are using. Note that even if you have not explicitly configured views, your zones exist within a view; it is just the default one, "_default". The names of the files used to store these lists of dynamically added zones are constructed from a SHA256 hash of the view name, plus the extension .nzf. So a .nzf is a per-view list of zones that have been added with rndc addzone.

.nzf naming format changed in BIND 9.11
Starting with version 9.11.0, BIND uses the view name for naming the .nzf file, unless the view name contains characters that would be incompatible with use in a file name, in which case BIND falls back to using a part of the SHA256 hash of the view name.

If the allow-new-zones option is set, upon startup named looks for a file called {viewname_or_hash}.nzf for each view in the configuration. If it finds such a file, it loads the zones that are listed in the nzf file into the appropriate view. If it does not find a .nzf file for the view, it emits a log message such as the one at the top of this article and continues normal operation. If you have set allow-new-zones yes; in your configuration but have not yet added any dynamically created zones, it is normal for there to be no .nzf file for named to find and the log message can be safely disregarded.