Bind dns config file

The file is parsed and checked for syntax errors, along with all files included by it. In case of any changes done in bind configuration, I recommend checking the DNS configuration file before restarting service. Above command will show nothing if there is no error found in the configuration file. In case of any error will displayed as output. If they both become unavailable, your services and applications that rely on them will cease to function properly.

This is why it is recommended to set up your DNS with at least one secondary server, and to maintain working backups of all of them. Where would you like to share this to? Twitter Reddit Hacker News Facebook. Share link Tutorial share link. Sign Up. DigitalOcean home. Community Control Panel. Hacktoberfest Contribute to Open Source. By Justin Ellingwood Published on September 6, Not using Debian 9?

Choose a different version or distribution. Debian 9. Introduction An important part of managing server configuration and infrastructure includes maintaining an easy way to look up network interfaces and IP addresses by name, by setting up a proper Domain Name System DNS. Prerequisites To complete this tutorial, you will need the following infrastructure.

Create each server in the same datacenter with private networking enabled : A fresh Debian 9 server to serve as the Primary DNS server, ns1 Recommended A second Debian 9 server to serve as a Secondary DNS server, ns2 Additional servers in the same datacenter that will be using your DNS servers On each of these servers, configure administrative access via a sudo user and a firewall by following our Debian 9 initial server setup guide.

Example Infrastructure and Goals For the purposes of this article, we will assume the following: We have two servers which will be designated as our DNS name servers. We will refer to these as ns1 and ns2 in this guide. We have two additional client servers that will be using the DNS infrastructure we create. We will call these host1 and host2 in this guide.

All of these servers exist in the same datacenter. We will assume that this is the nyc3 datacenter. All of these servers have private networking enabled and are on the You will likely have to adjust this for your servers. Since our DNS system will be entirely internal and private, you do not have to purchase a domain name.

However, using a domain you own may help avoid conflicts with publicly routable domains. About the authors. Justin Ellingwood. Still looking for an answer? Ask a question Search for more help. Comments Follow-Up Questions. Before you can do that To complete this action, sign in to your Community account or create a new one.

Sign In Sign Up. In situations where the zone files are highly dynamic, practical considerations may require that one or all of the zones be slaved from a single source. Avoid this configuration if possible, if not, as minimum secure the transfers with allow-transfer statements in the master zone clause and it may be worth considering use of TSIG to authenticate zone transfers.

BIND provides three more parameters to control caching, max-cache-size and max-cache-ttl neither of which will have much effect on performance in the above case and allow-recursion which uses a list of hosts that are permitted to use recursion all others are not - a kind of poor man's 'view'.

If security is not the primary requirement then the view clause may be used to provide 'Authoritative only' services to external users and more comprehensive services to internal users. The view clause may be used to return different IP addresses to provide, say, geographically dispersed users with minimum access latency or even a level of load-balancing if you understand the service source-ip access profile in this case the source-ip ranges in the example would be based on some analysis of incoming traffic not just geographic location.

At some point BIND, in its infinite wisdom, removed this feature. The rule, since at least BIND 9. Problems, comments, suggestions, corrections including broken links or something to add? Please take the time from a busy life to 'mail us' at top of screen , the webmaster below or info-support at zytrax. You will have a warm inner glow for the rest of the day. This work is licensed under a Creative Commons License. If you are happy it's OK - but your browser is giving a less than optimal experience on our site.

Page Resources. Open Source Initiative Creative Commons. Contents tech info guides home dns articles intro contents 1 objectives big picture 2 concepts 3 reverse map 4 dns types quickstart 5 install bind 6 samples reference 7 named. Search web zytrax. The number of queries the resolver sent at the domain zone. The number of lame servers the resolver detected at the domain zone. The number of times the resolver was unable to send a query because it had exceeded the permissible fetch quota for a server.

The number of erroneous results that the resolver encountered in sending queries at the domain zone. The number of unexpected responses other than lame to queries sent by the resolver at the domain zone.

Failures to resolve remote server addresses. This is a total number of failures throughout the resolution process. Validation failures are counted throughout the resolution process not limited to the domain zone , but should only happen in domain. A parental agent is the entity that the zone has a relationship with to change its delegation information defined in RFC Note: primaries is a synonym for the original keyword masters , which can still be used, but is no longer the preferred terminology.

This is the grammar of the options statement in the named. The options statement sets up global options to be used by BIND. This statement may appear only once in a configuration file. If there is no options statement, an options block with each option set to its default is used. This option allows multiple views to share a single cache database. Each view has its own cache database by default, but if multiple views have the same operational policy for name resolution and caching, those views can share a single cache to save memory, and possibly improve resolution efficiency, by using this option.

The attach-cache option may also be specified in view statements, in which case it overrides the global attach-cache option. When the named server configures views which are supposed to share a cache, it creates a cache with the specified name for the first view of these sharing views. The rest of the views simply refer to the already-created cache. One common configuration to share a cache is to allow all views to share a single cache.

This can be done by specifying attach-cache as a global option with an arbitrary name. Another possible operation is to allow a subset of all views to share a cache while the others retain their own caches. Views that share a cache must have the same policy on configurable parameters that may affect caching.

The current implementation requires the following configurable options be consistent among these views: check-names , dnssec-accept-expired , dnssec-validation , max-cache-ttl , max-ncache-ttl , max-stale-ttl , max-cache-size , min-cache-ttl , min-ncache-ttl , and zero-no-soa-ttl.

Note that there may be other parameters that may cause confusion if they are inconsistent for different views that share a single cache. For example, if these views define different sets of forwarders that can return different answers for the same question, sharing the answer does not make sense or could even be harmful.

This sets the working directory of the server. Any non-absolute pathnames in the configuration file are taken as relative to this directory. The default location for most server output files e. If a directory is not specified, the working directory defaults to ". The directory specified should be an absolute path, and must be writable by the effective user ID of the named process.

To enable dnstap at compile time, the fstrm and protobuf-c libraries must be available, and BIND must be configured with --enable-dnstap. The dnstap option is a bracketed list of message types to be logged. These may be set differently for each view. Supported types are client , auth , resolver , forwarder , and update.

Specifying type all causes all dnstap messages to be logged, regardless of type. Each type may take an additional argument to indicate whether to log query messages or response messages; if not specified, both queries and responses are logged.

Example: To log all authoritative queries and responses, recursive client responses, and upstream queries sent by the resolver, use:. Logged dnstap messages can be parsed using the dnstap-read utility see dnstap-read - print dnstap data in human-readable form for details. The fstrm library has a number of tunables that are exposed in named. These are:.

The minimum is , the maximum is , and the default is The minimum is 1 second, the maximum is seconds 10 minutes , and the default is 1 second. The minimum is 1 and the default is The default is mpsc multiple producer, single consumer ; the other option is spsc single producer, single consumer. This value must be a power of 2. The minimum is 2, the maximum is , and the default is The minimum is 1 second, the maximum is seconds 10 minutes , and the default is 5 seconds.

For convenience, TTL-style time-unit suffixes may be used to specify the value. Note that all of the above minimum, maximum, and default values are set by the libfstrm library, and may be subject to change in future versions of the library.

See the libfstrm documentation for more information. This configures the path to which the dnstap frame stream is sent if dnstap is enabled at compile time and active. The first argument is either file or unix , indicating whether the destination is a file or a Unix domain socket. The second argument is the path of the file or socket.

If the first argument is file , then up to three additional options can be added: size indicates the size to which a dnstap log file can grow before being rolled to a new file; versions specifies the number of rolled log files to retain; and suffix indicates whether to retain rolled log files with an incrementing counter as the suffix increment or with the current timestamp timestamp.

These are similar to the size , versions , and suffix options in a logging channel. The default is to allow dnstap log files to grow to any size without rolling. Currently, it can only be set once while named is running; once set, it cannot be changed by rndc reload or rndc reconfig.

This specifies an identity string to send in dnstap messages. If set to none , no identity string is sent. This specifies a version string to send in dnstap messages. The default is the version number of the BIND release.

If set to none , no version string is sent. This is the directory where the public and private DNSSEC key files should be found when performing a dynamic update of secure zones, if different than the current working directory. When named is built with liblmdb, this option sets a maximum size for the memory map of the new-zone database NZD in LMDB database format. This database is used to store configuration information for zones added using rndc addzone.

Note that this is not the NZD database file size, but the largest size that the database may grow to. Because the database file is memory-mapped, its size is limited by the address space of the named process. The default of 32 megabytes was chosen to be usable with bit named builds. The largest permitted value is 1 terabyte.

By default, this is the working directory. The directory must be writable by the effective user ID of the named process. If named is not configured to use views, managed keys for the server are tracked in a single file called managed-keys.

Otherwise, managed keys are tracked in separate files, one file per view; each file name is the view name or, if it contains characters that are incompatible with use as a file name, the SHA hash of the view name , followed by the extension.

Note: in earlier releases, file names for views always used the SHA hash of the view name. To ensure compatibility after upgrading, if a file using the old name format is found to exist, it is used instead of the new format. This sets the size threshold expressed as a percentage of the size of the full zone beyond which named chooses to use an AXFR response rather than IXFR when answering zone transfer requests.

The keyword unlimited disables ratio checking and allows IXFRs of any size. This specifies the directory in which to store the configuration parameters for zones added via rndc addzone. If set to a relative path, it is relative to the working directory. The current default is relaxed , but it may be changed to strict in a future release.

If this option is set and tkey-gssapi-credential is not set, updates are allowed with any key matching a principal in the specified keytab. The location of the keytab file can be overridden using the tkey-gssapi-keytab option. This domain is appended to the names of all shared keys generated with TKEY. When a client requests a TKEY exchange, it may or may not specify the desired name for the key.

The server must be able to load the public and private keys from files in the working directory. This is the pathname of the file the server dumps the database to, when instructed to do so with rndc dumpdb.

This is the pathname of the file the server writes memory usage statistics to on exit. If not specified, the default is named. This is the pathname of a file on which named attempts to acquire a file lock when starting for the first time; if unsuccessful, the server terminates, under the assumption that another server is already running.

If not specified, the default is none. Specifying lock-file none disables the use of a lock file. Changes to lock-file are ignored if named is being reloaded or reconfigured; it is only effective when the server is first started. This is the pathname of the file the server writes its process ID in. The PID file is used by programs that send signals to the running name server. Specifying pid-file none disables the use of a PID file; no file is written and any existing one is removed.

Note that none is a keyword, not a filename, and therefore is not enclosed in double quotes. This is the pathname of the file where the server dumps the queries that are currently recursing, when instructed to do so with rndc recursing. This is the pathname of the file the server appends statistics to, when instructed to do so using rndc stats. The format of the file is described in The Statistics File. This is the pathname of a file to override the built-in trusted keys provided by named.

See the discussion of dnssec-validation for details. This is the pathname of the file the server dumps security roots to, when instructed to do so with rndc secroots. This is the pathname of the file into which to write a TSIG session key generated by named for use by nsupdate -l. This is the key name to use for the TSIG session key.

If not specified, the default is local-ddns. This is the algorithm to use for the TSIG session key. Valid values are hmac-sha1, hmac-sha, hmac-sha, hmac-sha, hmac-sha, and hmac-md5. If not specified, the default is hmac-sha The default is This option is mainly intended for server testing; a server using a port other than 53 is not able to communicate with the global DNS. This is the TCP port number the server uses to receive and send unencrypted DNS traffic via HTTP a configuration that may be useful when encryption is handled by third-party software or by a reverse proxy.

This sets the hard quota on the number of active concurrent connections on a per-listener basis. The default value is ; setting it to 0 removes the quota.

The default value is ; setting it to 0 removes the limit. Once the limit is exceeded, the server finishes the HTTP session. Valid values are 0 through It is not configured by default. This specifies a source of entropy to be used by the server; it is a device or file from which to read entropy. If it is a file, operations requiring entropy will fail when the file has been exhausted. It is also used for seeding and stirring the pseudo-random number generator which is used for less critical functions requiring randomness, such as generation of DNS message transaction IDs.

If random-device is not specified, or if it is set to none , entropy is read from the random number generation function supplied by the cryptographic library with which BIND was linked i. The random-device option takes effect during the initial configuration load at server startup time and is ignored on subsequent reloads. If specified, the listed type A or AAAA is emitted before other glue in the additional section of a query response.

This turns on enforcement of delegation-only in TLDs top-level domains and root zones with an optional exclude list. DS queries are expected to be made to and be answered by delegation-only zones. If a delegation-only zone server also serves a child zone, it is not always possible to determine whether an answer comes from the delegation-only zone or the child zone.

RRSIG records are also examined to see whether they are signed by a child zone, and the authority section is examined to see if there is evidence that the answer is from the child zone. Despite all these checks, there is still a possibility of false negatives when a child zone is being served. Similarly, false positives can arise from empty nodes no records at the name in the delegation-only zone when the query type is not ANY. Note that some TLDs are not delegation-only; e.

This list is not exhaustive. Multiple disable-algorithms statements are allowed. Only the best-match disable-algorithms clause is used to determine the algorithms. If all supported algorithms are disabled, the zones covered by the disable-algorithms setting are treated as insecure.

Configured trust anchors in trust-anchors or managed-keys or trusted-keys that match a disabled algorithm are ignored and treated as if they were not configured. This disables the specified DS digest types at and below the specified name. Multiple disable-ds-digests statements are allowed. Only the best-match disable-ds-digests clause is used to determine the digest types. If all supported digest types are disabled, the zones covered by disable-ds-digests are treated as insecure.

This specifies hierarchies which must be or may not be secure signed and validated. If yes , then named only accepts answers if they are secure. The specified domain must be defined as a trust anchor, for instance in a trust-anchors statement, or dnssec-validation auto must be active. It is intended to be used in conjunction with a NAT Each dns64 defines one DNS64 prefix. Multiple DNS64 prefixes can be defined. Bits In addition, a reverse IP6. ARPA to be created if not explicitly disabled using ipv4only-enable.

Each dns64 supports an optional clients ACL that determines which clients are affected by this directive. If not defined, it defaults to any;. If not defined, exclude defaults to ::ffff An optional suffix can also be defined to set the bits trailing the mapped IPv4 address bits.

By default these bits are set to The bits matching the prefix and mapped IPv4 address must be zero. If recursive-only is set to yes , the DNS64 synthesis only happens for recursive queries. If this option is set to no the default , the DO is set on the incoming query, and there are RRSIGs on the applicable records, then synthesis does not happen.

The dnssec-loadkeys-interval option sets the frequency of automatic repository checks, in minutes. The default is 60 1 hour , the minimum is 1 1 minute , and the maximum is 24 hours ; any higher value is silently reduced. This specifies which key and signing policy KASP should be used for this zone. This is a string referring to a dnssec-policy statement.

There are three built-in policies: default , which uses the default policy, insecure , to be used when you want to gracefully unsign your zone, and none , which means no DNSSEC policy. The default is none. See dnssec-policy Grammar for more details. If this option is set to its default value of maintain in a zone of type primary which is DNSSEC-signed and configured to allow dynamic updates see Dynamic Update Policies , and if named has access to the private signing key s for the zone, then named automatically signs all new or changed records and maintains signatures for the zone by regenerating RRSIG records whenever they approach their expiration date.

If the option is changed to no-resign , then named signs all new or changed records, but scheduled maintenance of signatures is disabled. With either of these settings, named rejects updates to a DNSSEC-signed zone when the signing keys are inactive or unavailable to named. A planned third option, external , will disable all automatic signing and allow DNSSEC data to be submitted into a zone via dynamic update; this is not yet implemented.

This specifies the default lifetime, in seconds, for negative trust anchors added via rndc nta. A negative trust anchor selectively disables DNSSEC validation for zones that are known to be failing because of misconfiguration, rather than an attack. When data to be validated is at or below an active NTA and above any other configured trust anchors , named aborts the DNSSEC validation process and treats the data as insecure rather than bogus.

NTAs persist across named restarts. It also accepts ISO duration formats. This specifies how often to check whether negative trust anchors added via rndc nta are still necessary. A negative trust anchor is normally used when a domain has stopped validating due to operator error; it temporarily disables DNSSEC validation for that domain. In the interest of ensuring that DNSSEC validation is turned back on as soon as possible, named periodically sends a query to the domain, ignoring negative trust anchors, to find out whether it can now be validated.

If so, the negative trust anchor is allowed to expire early. Validity checks can be disabled for an individual NTA by using rndc nta -f , or for all NTAs by setting nta-recheck to zero. For convenience, TTL-style time-unit suffixes can be used to specify the NTA recheck interval in seconds, minutes, or hours. The default is five minutes. It cannot be longer than nta-lifetime , which cannot be longer than a week.

This specifies a maximum permissible TTL value in seconds. For convenience, TTL-style time-unit suffixes may be used to specify the maximum value.

When loading a zone file using a masterfile-format of text or raw , any record encountered with a TTL higher than max-zone-ttl causes the zone to be rejected.

The max-zone-ttl option guarantees that the largest TTL in the zone is no higher than the set value. The default value is unlimited. A max-zone-ttl of zero is treated as unlimited. This specifies the TTL to be returned on stale answers. The default is 30 seconds. The minimum allowed is 1 second; a value of 0 is updated silently to 1 second. For stale answers to be returned, they must be enabled, either in the configuration file using stale-answer-enable or via rndc serve-stale on.

Zones configured for dynamic DNS may use this option to set the update method to be used for the zone serial number in the SOA record. With the default setting of serial-update-method increment; , the SOA serial number is incremented by one each time the zone is updated.

When set to serial-update-method unixtime; , the SOA serial number is set to the number of seconds since the Unix epoch, unless the serial number is already greater than or equal to that value, in which case it is simply incremented by one. If full , the server collects statistical data on all zones, unless specifically turned off on a per-zone basis by specifying zone-statistics terse or zone-statistics none in the zone statement.

The statistical data includes, for example, DNSSEC signing operations and the number of authoritative answers per query type. The default is terse , providing minimal statistics on zones including name and current serial number, but not query type counters.

These statistics may be accessed via the statistics-channel or using rndc stats , which dumps them to the file listed in the statistics-file. See also The Statistics File. For backward compatibility with earlier versions of BIND 9, the zone-statistics option can also accept yes or no ; yes has the same meaning as full. As of BIND 9. If yes and supported by the operating system, this automatically rescans network interfaces when the interface addresses are added or removed.

The default is yes. This configuration option does not affect the time-based interface-interval option; it is recommended to set the time-based interface-interval to 0 when the operator confirms that automatic interface scanning is supported by the operating system. The automatic-interface-scan implementation uses routing sockets for the network interface discovery; therefore, the operating system must support the routing sockets for this feature to work.

If yes , then zones can be added at runtime via rndc addzone. The configuration information is saved in a file called viewname. Configurations for zones added at runtime are stored either in a new-zone file NZF or a new-zone database NZD , depending on whether named was linked with liblmdb at compile time.

See rndc - name server control utility for further details about rndc addzone. This writes memory statistics to the file specified by memstatistics-file at exit. The default is no unless -m record is specified on the command line, in which case it is yes. If yes , then the server treats all zones as if they are doing zone transfers across a dial-on-demand dialup link, which can be brought up by traffic originating from this server.

Although this setting has different effects according to zone type, it concentrates the zone maintenance so that everything happens quickly, once every heartbeat-interval , ideally during a single call. It also suppresses some normal zone maintenance traffic. If specified in the view and zone statements, the dialup option overrides the global dialup option.

This should trigger the zone serial number check in the secondary providing it supports NOTIFY , allowing the secondary to verify the zone while the connection is active. Finer control can be achieved by using notify , which only sends NOTIFY messages; notify-passive , which sends NOTIFY messages and suppresses the normal refresh queries; refresh , which suppresses normal refresh processing and sends refresh queries when the heartbeat-interval expires; and passive , which disables normal refresh processing.

The default is flush-zones-on-shutdown no. If yes , respond to root key sentinel probes as described in draft-ietf-dnsop-kskroll-sentinel Setting this option to no reduces CPU usage on servers and may improve throughput. However, it increases response size, which may cause more queries to be processed using TCP; a server with compression disabled is out of compliance with RFC Section 6.

This option controls the addition of records to the authority and additional sections of responses. Such records may be included in responses to be helpful to clients; for example, NS or MX records may have associated address records included in the additional section, obviating the need for a separate address lookup.

However, adding these records to responses is not mandatory and requires additional database lookups, causing extra latency when marshalling responses. This provides the best server performance but may result in more client queries. The default is no-auth-recursive.

When set to yes , a cache is used to improve query performance when adding address-type A and AAAA glue records to the additional section of DNS response messages that delegate to a child zone. The glue cache uses memory proportional to the number of delegations in the zone. The default setting is yes , which improves performance at the cost of increased memory usage for the zone.

To avoid this, set it to no. This option is deprecated and its use is discouraged. The glue cache will be permanently enabled in a future release. This can reduce the impact of some kinds of attack traffic, without harming legitimate clients.

Note, however, that the RRset returned is the first one found in the database; it is not necessarily the smallest available RRset. Additionally, minimal-responses is turned on for these queries, so no unnecessary records are added to the authority or additional sections. If set to primary-only or the older keyword master-only , notifies are only sent for primary zones. If set to explicit , notifies are sent only to servers explicitly listed using also-notify.

If set to no , no notifies are sent. The notify option may also be specified in the zone statement, in which case it overrides the options notify statement.

It would only be necessary to turn off this option if it caused secondary zones to crash. If yes , and a DNS query requests recursion, then the server attempts to do all the work required to answer the query. If recursion is off and the server does not already know the answer, it returns a referral response. If the authoritative server returns an NSID option in its response, then its contents are logged in the nsid category at level info.

If yes , require a valid server cookie before sending a full response to a UDP request from a cookie-aware client. Setting this to yes results in a reduced amplification effect in a reflection attack, as the BADCOOKIE response is smaller than a full response, while also requiring a legitimate client to follow up with a second query with the new, valid, cookie.

This can only be set at the global options level, not per-view. A mismatch between servers on the same address is not expected to cause operational problems, but the option to disable COOKIE responses so that all servers have the same behavior is provided out of an abundance of caution.