Time To Expire — How long in seconds a nameserver should wait prior to considering data from a secondary zone invalid and stop answering queries for that zone. Minimum TTL — How long in seconds that a nameserver or resolver should cache a negative response. Fully qualified hostnames terminated by a period will not append the origin. Record Type — Where the format of a record is defined. You may make errors while writing a zone file.
You can diagnose those errors from the log using the following syntax. After you have successfully added and modified your resource records you can check whether your host is resolved correctly using the following command. The whois command is used to get the details of the owner of the domain. The details may be information like a contact number or phone number.
The rndc command is used to secure your name server from both locally and a remote place. To prevent any unauthorized access to your name server rndc must be configured on the selected port port by default. If you make any change to any of the zone files you can reload the service using the following command.
If you add new zones or you change the configuration of the server you can reload the configuration using the following command. You may also have a look at the following articles to learn more —. Submit Next Question. By signing up, you agree to our Terms of Use and Privacy Policy.
We then inform anyone querying this record that any valid A record for example. Now that we've defined everything we need to for the domain, we can start adding records for any hostnames and subdomains beneath example.
Again, notice that final terminating dot—if you forget it, things are going to get really strange and you'll tear your hair out wondering why none of your records resolve properly! We see A records here for ns1 , ns2 , and mail. These A records work the same way that the A record for the domain itself did—we are telling BIND what IP address to resolve requests for that hostname to. We also have an AAAA record for mail. Once again, we've chosen in our example to use a localhost address.
You'll need to be familiar with AAAA records if you expect to set up your own mailserver—Google stopped being willing to talk to mailservers without fully working IPv6 DNS a few years ago! CNAME records are handy, but they're a bit funky. If you try to set MX mail. CNAME example. If you have access to Linux, Mac, or Windows Subsystem for Linux, by far the best command line tool is dig.
Using dig is as simple as specifying a server to query, the record type you want to look for, and the FQDN it should be associated with. In the example above, we asked the DNS server at In addition to the answers we wanted, we got a ton of diagnostic information—the DNS server we queried did not return an ERROR when queried, it says it is authoritative for the domain in question, and so forth.
If you don't have access to dig , you can generally get by with nslookup. Most commonly, this is a semi-cursed workaround for users sitting at a Windows box without access to Windows Subsystem for Linux, cygwin, or some other way to gain access to more advanced tools than the Windows CLI provides. Here's a sample session:. By setting server You don't have to specify this; if you don't, nslookup will use whatever the default DNS resolver on your machine would.
After optionally setting the server , you can just type a bare hostname into nslookup 's interactive prompt, and it will return any A or AAAA records it can find for that hostname. If you want to query the remote server for a different type of record, you'll need to use a set type command.
It works, and you get your answers If a list of channels is not specified for a category, log messages in that category are sent to the default category instead.
If named is started with the -L option then the default category is:. They would specify the following:. To discard all messages in a category, specify the null channel:. Following are the available categories and brief descriptions of the types of log information they contain. More categories may be added in future BIND releases. Log queries that have been forced to use plain DNS due to timeouts. Note: the log message can also be due to packet loss.
Before reporting servers for non- RFC compliance they should be re-tested to determine the nature of the non-compliance. This testing should prevent or reduce the number of false-positive reports. Note: eventually named will have to stop treating such timeouts as due to RFC non-compliance and start treating it as plain packet loss. At startup, specifying the category queries also enables query logging unless the querylog option has been specified.
After this, the destination address the query was sent to is reported. Start, periodic, and final notices of the rate limiting of a stream of responses that are logged at info severity in this category.
These messages include a hash value of the domain name of the response and the name itself, except when there is insufficient memory to record the name for the final notice. The final notice is normally delayed until about one minute after rate limiting stops.
Various internal events are logged at debug 1 level and higher. Rate limiting of individual requests is logged in the query-errors category. The query-errors category is used to indicate why and how specific queries resulted in responses which indicate an error.
Normally, these messages are logged at debug logging levels; note, however, that if query logging is active, some are logged at info. The logging levels are described below:. The log message looks like this:. The first part before the colon shows that a recursive resolution for AAAA records of www. The last part, enclosed in square brackets, shows statistics collected for this particular resolution attempt.
The domain field shows the deepest zone that the resolver reached; it is the zone where the error was finally detected. The meaning of the other fields is summarized in the following list. 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 would be to allow all views to share a single cache. This can be done by specifying the 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 to 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. 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:. 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.
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 is the pathname of a file on which named attempts to acquire a file lock when starting up 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 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. 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 which algorithms are used. If all supported algorithms are disabled, the zones covered by the disable-algorithms setting are treated as insecure.
Configured trust anchors in trusted-anchors or managed-keys or trusted-keys that match a disabled algorithm are ignored and treated as if they were not configured at all. 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 the disable-ds-digests are treated as insecure.
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. 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.
If this option is set to its default value of maintain in a zone of type master 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. NOTE: Because map -format files load directly into memory, this option cannot be used with them.
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 1 second. The minimum allowed is also 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 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 has to 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. 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 just disables normal refresh processing.
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. 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. If master-only , notifies are only sent for primary zones. If explicit , notifies are sent only to servers explicitly listed using also-notify. If 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 , 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. This is used by the server to determine whether the resolver has talked to it before. Resolvers which do not send a correct COOKIE option may be limited to receiving smaller responses via the nocookie-udp-size option.
The default is not to return stale answers. Stale answers can also be enabled or disabled at runtime via rndc serve-stale on or rndc serve-stale off ; these override the configured setting. Note that if stale answers have been disabled by rndc , they cannot be re-enabled by reloading or reconfiguring named ; they must be re-enabled with rndc serve-stale on , or the server must be restarted.
Information about stale answers is logged under the serve-stale log category. If not set, the system generates a random secret at startup. If there are multiple secrets specified, the first one listed in named. The others are only used to verify returned cookies. The EDNS Padding option is intended to improve confidentiality when DNS queries are sent over an encrypted channel by reducing the variability in packet sizes. If a query:.
If these conditions are not met, the response is not padded. If block-size is 0 or the ACL is none; , this feature is disabled and no padding occurs; this is the default. If block-size is greater than , a warning is logged and the value is truncated to Block sizes are ordinarily expected to be powers of two for instance, , but this is not mandatory. This causes named to send specially formed queries once per day to domains for which trust anchors have been configured via, e.
The key IDs for each domain are sorted smallest to largest prior to encoding. The query type is NULL. By monitoring these queries, zone operators are able to see which resolvers have been updated to trust a new key; this may help them decide when it is safe to remove an old one.
If yes , then an IPv4-mapped IPv6 address matches any address match list entries that match the corresponding IPv4 address.
This option was introduced to work around a kernel quirk in some operating systems that causes IPv4 TCP connections, such as zone transfers, to be accepted on an IPv6 socket using mapped addresses. This caused address match lists designed for IPv4 to fail to match. However, named now solves this problem internally. The use of this option is discouraged. When yes and the server loads a new version of a primary zone from its zone file or receives a new version of a secondary file via zone transfer, it compares the new version to the previous one and calculates a set of differences.
By allowing incremental zone transfers to be used for non-dynamic zones, this option saves bandwidth at the expense of increased CPU and memory consumption at the primary server. In particular, if the new version of a zone is completely different from the previous one, the set of differences is of a size comparable to the combined size of the old and new zone versions, and the server needs to temporarily allocate memory to hold this complete difference set.
It is off for all zones by default. Note: if inline signing is enabled for a zone, the user-provided ixfr-from-differences setting is ignored for that zone. There are three possible settings:. The command rndc sign zonename causes named to load keys from the key repository and sign the zone with all keys that are active.
Note: once keys have been loaded for a zone the first time, the repository is searched for changes periodically, regardless of whether rndc loadkeys is used. The recheck interval is defined by dnssec-loadkeys-interval.
The default setting is auto-dnssec off. If set to yes , DNSSEC validation is enabled, but a trust anchor must be manually configured using a trust-anchors statement or the managed-keys or trusted-keys statements, both deprecated. If there is no configured trust anchor, validation does not take place. The default is auto , unless BIND is built with configure --disable-auto-validation , in which case the default is yes.
The default root trust anchor is stored in the file bind. A copy of the file is installed along with BIND 9, and is current as of the release date. If the root key expires, a new copy of bind. To prevent problems if bind.
Relying on this is not recommended, however, as it requires named to be recompiled with a new key when the root key expires. The file cannot be used to store keys for other zones. The root key in bind. Query logging provides a complete log of all incoming queries and all query errors. The querylog option specifies whether query logging should be active when named first starts.
If querylog is not specified, then query logging is determined by the presence of the logging category queries. Query logging can also be activated at runtime using the command rndc querylog on , or deactivated with rndc querylog off. The default varies according to usage area.
For primary zones the default is fail. For secondary zones the default is warn. For answers received from the network response , the default is ignore. This performs post-load zone integrity checks on primary zones. For MX and SRV records, only in-zone hostnames are checked for out-of-zone hostnames use named-checkzone.
For NS records, only names below top-of-zone are checked for out-of-zone names and glue consistency checks use named-checkzone. Warnings are emitted if the TXT record does not exist; they can be suppressed with check-spf. This is similar to the dnssec-signzone -z command line option. If there is any algorithm for which this requirement is not met, this option is ignored for that algorithm.
0コメント