--- title: "How do I prevent BIND from stopping listening on a down interface?" slug: "aa-00420" description: "By default, BIND scans the network interface list every 60 minutes and stops listening on any interfaces that it finds unavailable. This can be overridden." tags: ["listen on", "interface"] updated: 2024-03-22T15:09:25Z published: 2024-03-22T15:09:25Z canonical: "kb.isc.org/aa-00420" --- > ## 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. # 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. `--disable-linux-caps` going forward Please note that starting with version 9.19 (development), which will be the basis for all future production versions of BIND, `--disable-linux-caps` is not available as a build option, so Linux capabilities are always enabled.