BIND zone file backend

• Native: Yes
• Master: Yes
• Slave: Yes
• Superslave: Experimental
• DNSSEC: Yes
• Disabled data: No
• Comments: No
• API: Read-only
• Zone caching: Yes (except in hybrid mode)
• Module name: bind
• Launch: bind

The BIND backend started life as a demonstration of the versatility of PowerDNS but quickly gained in importance when there appeared to be demand for a BIND ‘work-alike’.

The BIND backend parses a BIND-style named.conf and extracts information about zones from it. It makes no attempt to honour other configuration flags, which you should configure (when available) using the PowerDNS native configuration.

Unique to this PowerDNS backend is that it serves from plain zone files, which allows for hand-crafting zone files, only takes a tiny footprint in terms of server resource usage while being performant efficiently.

Note

Because this backend retrieves its configuration from plain files and not a database, the HTTP API is unable to process changes for this backend. This effectively makes the API read-only for zones hosted by the BIND backend.

Configuration Parameters

bind-config

Location of the BIND configuration file to parse.

PowerDNS does not support every directive supported by BIND. It supports the following blocks and directives:

• options

  • directory
  • also-notify

• zone

  • file
  • type
  • masters
  • primaries (added in version 4.9.0)
  • also-notify

Unknown directives will be ignored.

bind-check-interval

Interval in seconds to check for zone file changes. Default is 0 (disabled).

See Operation section for more information.

bind-dnssec-db

Filename to store and access our DNSSEC metadatabase, empty for none. To run secondary DNSSEC-enabled domains (where the RRSIGS are in the AXFR), a bind-dnssec-db is required. This is because the PRESIGNED domain metadata is set during the zonetransfer.

You can use pdnsutil create-bind-db to make this database file for you.

Warning

If this is left empty on slaves and a presigned zone is transferred, it will (silently) serve it without DNSSEC. This in turn results in serving the domain as bogus.

bind-dnssec-db-journal-mode

SQLite3 journal mode to set. The default is WAL. Set to empty to leave the journal mode alone.

bind-hybrid

Store DNSSEC keys and metadata storage in another backend. See the Hybrid BIND-mode operation documentation.

bind-ignore-broken-records

Setting this option to yes makes PowerDNS ignore out of zone records when loading zone files.

Autoprimary support (experimental)

bind-autoprimaries

Changed in version 4.9.0: This was called bind-supermasters before 4.9.0.

Specifies file where to read list of autoprimaries. BIND backend only checks IP address of primary server.

The file must contain one IP and account per line, separated by whitespace.

BIND backend can only read this file, not write it.

bind-autoprimary-config

Changed in version 4.9.0: This was called bind-supermaster-config before 4.9.0.

When a new zone is configured via the autosecondary mechanism, bindbackend writes a zone entry to this file.

Your bind-config file should have an include statement to make sure this file is read on startup.

bind-autoprimary-destdir

Changed in version 4.9.0: This was called bind-supermaster-destdir before 4.9.0.

Each new zone configured via the autosecondary mechanism gets a zone file in this directory. This directory must be writable.

Operation

On launch, the BIND backend first parses the named.conf to determine which zones need to be loaded. These will then be parsed and made available for serving, as they are parsed. So a named.conf with 100.000 zones may take 20 seconds to load, but after 10 seconds, 50.000 zones will already be available. While a domain is being loaded, it is not yet available, to prevent incomplete answers.

Reloading is currently done only when a request (or zone transfer) for a zone comes in, and then only after bind-check-interval seconds have passed since the last check. If a change occurred, access to the zone is disabled, the file is reloaded, access is restored, and the question is answered. For regular zones, reloading is fast enough to answer the question which lead to the reload within the DNS timeout.

If bind-check-interval is specified as zero, no checks will be performed until the pdns_control reload command is issued.

Please note that also the xfr-cycle-interval setting controls how often a primary would notify a secondary about changes. Especially in ‘hidden primary’ configurations, where servers usually don’t receive regular queries, you may want to lower that setting to a value as low as bind-check-interval.

pdns_control commands

bind-add-zone <domain> <filename>

Add zone domain from filename to PowerDNS’s BIND backend. Zone will be loaded at first request.

Note

This does not add the zone to the bind-config file.

bind-domain-extended-status [domain ...]

New in version 4.3.0.

Output an extended status of a domain or domains, containing much more information than the simple domain status, like the number of records currently loaded, whether pdns is primary or secondary for the domain, the list of primaries, various timers, etc

bind-domain-status [domain ...]

Output status of domain or domains. Can be one of:

• seen in named.conf, not parsed,
• parsed successfully at <time> or
• error parsing at line ... at <time>.

bind-list-rejects

Lists all zones that have problems, and what those problems are.

bind-reload-now <domain>

Reloads a zone from disk immediately, reporting back results.

rediscover

Reread the BIND configuration file (named.conf). If parsing fails, the old configuration remains in force and pdns_control reports the error. Any newly discovered domains are read, discarded domains are removed from memory.

reload

All zones with a changed timestamp are reloaded at the next incoming query for them.

Performance

The BIND backend does not benefit from the packet cache as it is fast enough on its own. Furthermore, on most systems, there will be no benefit in using multiple CPUs for the packetcache, so a noticeable speedup can be attained by specifying distributor-threads=1 in pdns.conf.

Primary/secondary/native configuration

Primary

Works as expected. At startup, no notification storm is performed as this is generally not useful. Perhaps in the future the BIND backend will attempt to store zone metadata in the zone, allowing it to determine if a zone has changed its serial since the last time notifications were sent out.

Changes which are discovered when reloading zones do lead to notifications however.

Secondary

Also works as expected. The BIND backend expects to be able to write to a directory where a secondary domain lives. The incoming zone is stored as ‘zonename.RANDOM’ and atomically renamed if it is retrieved successfully, and parsed only then.

In the future, this may be improved so the old zone remains available should parsing fail.

Native

PowerDNS has the concept of “native” zones that have the type native; in the BIND configuration file. These zones are neither a primary (no notifies are sent) nor a secondary zone (it will never be AXFR’d in). This means that the replication mechanism for these zone is not AXFR but out of band, e.g. using rsync. Changes to native zones are picked up in the same way as primary and secondary zones, see Operation.

Native zones in the BIND backend are supported since version 4.1.0 of the PowerDNS Authoritative Server.

Note

Any zone with no type set (an error in BIND) is assumed to be native.