How does BIND know what addresses to use?

Any computer on which BIND will be running is likely to have several interfaces, each of which may have multiple IP addresses; both IPv4 and IPv6.

When the named process is started it needs to know which of these addresses it should be using for the various jobs it needs to perform.

There are several configuration statements that control what named wants to use and how it discovers what's available to be used. These are:

• listen-on for IPv4 addresses.
• listen-on-v6 for IPv6 addresses.
• query-source for IPv4 addresses.
• query-source-v6 for IPv6 addresses.
• Other -source statements.
• interface-interval, which controls periodic scanning, if any.
• automatic-interface-scan, which controls whether automatic scanning happens.

What are the listen-on[-v6] statements and how do they work?

These statements allow you to limit which addresses named listens on for incoming messages: by default it listens on all available addresses.

BIND has always listened on IPv4 addresses, but before version 9.10 did not listen on IPv6 addresses automatically; those had to be be listed explicilty using the listen-on-v6 statement.

Starting with version 9.10 IPv6 support is now automatic.

If the configuration contains no listen-on (or listen-on-v6) statements, named will listen for incoming traffic on all addresses of all functioning interfaces (that have been discovered by scanning).

However, if either/both listen-on[-v6] exist in the configuration then named limits itself to only listening on those addresses, ignoring all others that may exist in the system. There may be multiple listen-on[-v6] statements, to allow named to listen for traffic arriving on several different, but defined, addresses.

But what if an address is not available?

Its configuration may say listen-on 192.2.0.1;, for example. But what if the interface with that address doesn't exist on this system, or is currently down? This is where interface scanning comes in, to determine what is actually available.

What is interface scanning?

When the named process is started, one of the tasks it performs is to scan the interfaces available on the system in which it is running, to determine what IP addresses are available for use - both for listening for incoming queries and other messages and for making outbound queries, sending NOTIFY messages etc.

Scanning is important because, as noted above, if the configuration contains a line such as listen-on 192.2.0.1; but scanning detects that no interface with that address exists (or is up), named cannot do its job.

An initial scan is one thing. That sets the working addresses available at the time named was started. But addresses can change: operators may edit interface parameters manually, or interfaces can flap, or other automatic processes external to named may affect the addresses that can be used on this box. Therefore named needs to be able to keep track of any such changes and update its internal view of what is available. It can do this in two ways:

Periodic interface scanning

As it is running, every so often named will (by default) perform another interface scan, like it did at startup, to check what exists now.

Periodic scanning is controlled either by the statement interface-interval or by an initial (startup) test to check whether the operating system has the ability to notify processes of interface changes; something known as routing sockets.

The interface-interval statement takes a numeric value, which represents the number of minutes between scans (default 60). If this parameter is set to zero, scheduled scanning is disabled and it happens only at startup, or each time the server is reloaded.

Automatic interface scanning

The automatic-interface-scan statement takes a boolean value (default 'yes'), which controls whether an interface scan can be prompted by a notification from the operating system, potentially complementing any scheduled scanning.

routing sockets

If named detects that the system does support routing sockets, periodic scanning is disabled because event-driven scanning happens only when necessary and is thus more efficient. If this is the case then a startup log message will be issued saying:

Disabling periodic interface re-scans timer

If this message is not displayed in the set of startup log messages then the system does not support routing sockets, or the capability could not be determined. Either way, periodic scanning is still enabled, unless disabled deliberately in the configuration. This would be a bad idea because named would then have no way of knowing about interface and address changes as it is running.

Linux capabilities

When named first starts it runs several tasks as a privileged user because these are necessary to get the system up and running; the initial interface scan is one such task.

However, following initial startup named drops to being an unprivileged user, for security. In this state it may not be allowed to perform further interface scans, however they are initiated. This is where Linux capabilities come into play, which allow non-privileged processes to perform certain privileged task, even without being run as, or teporarily elevated to root.

From version 9.13.2 the libcap library is required (when building on Linux) to allow process privileges.

If the system on which named is running is static and stable, the inability to perform further scans might not matter. No changes are anticipated whilst the server is up and stable and if any changes need to be made they would happen during a scheduled maintenance window, during which time it is likely that named would be stopped, reconfigured and started again anyway.

If this is the case then building named with the option --disable-linux-caps may be OK, if security is what you are focussing on.

But if the system is designed for change whilst running - e.g. using dynamic routeing protocols as part of an anycast setup, where addresses may come and go, or interfaces change state regularly, or VRRP then ongoing scans are necessary and therefore we recommend not using the --disable-linux-caps option when building named.

Another way to achieve this, if BIND is being started by systemd, would be to configure the necessary privileges in the unit file using the CapabilityBoundingSet= and AmbientCapabilities= directives. Such configuration is beyond the scope of this article.