---
title: "3bf305731dd26307.nzf: file not found error"
slug: "aa-00903"
description: "This error was seen when creating new zone files in older versions of BIND."
updated: 2018-10-30T19:28:51Z
published: 2018-10-30T19:28:51Z
---

> ## Documentation Index
> Fetch the complete documentation index at: https://kb.isc.org/llms.txt
> Use this file to discover all available pages before exploring further.

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

@(Info)(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`.

@(Info)(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`.

@(Info)(.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.