table of contents
RNDC(8) | BIND9 | RNDC(8) |
NAME¶
rndc - name server control utility
SYNOPSIS¶
rndc [-b source-address] [-c config-file] [-k key-file] [-s server] [-p port] [-q] [-r] [-V] [-y key_id] {command}
DESCRIPTION¶
rndc controls the operation of a name server. It supersedes the ndc utility that was provided in old BIND releases. If rndc is invoked with no command line options or arguments, it prints a short summary of the supported commands and the available options and their arguments.
rndc communicates with the name server over a TCP connection, sending commands authenticated with digital signatures. In the current versions of rndc and named, the only supported authentication algorithms are HMAC-MD5 (for compatibility), HMAC-SHA1, HMAC-SHA224, HMAC-SHA256 (default), HMAC-SHA384 and HMAC-SHA512. They use a shared secret on each end of the connection. This provides TSIG-style authentication for the command request and the name server's response. All commands sent over the channel must be signed by a key_id known to the server.
rndc reads a configuration file to determine how to contact the name server and decide what algorithm and key it should use.
OPTIONS¶
-b source-address
-c config-file
-k key-file
-s server
-p port
-q
-r
-V
-y key_id
COMMANDS¶
A list of commands supported by rndc can be seen by running rndc without arguments.
Currently supported commands are:
addzone zone [class [view]] configuration
The configuration is saved in a file called name.nzf, where name is the name of the view, or if it contains characters that are incompatible with use as a file name, a cryptographic hash generated from the name of the view. When named is restarted, the file will be loaded into the view configuration, so that zones that were added can persist after a restart.
This sample addzone command would add the zone example.com to the default view:
$rndc addzone example.com '{ type master; file "example.com.db"; };'
(Note the brackets and semi-colon around the zone configuration text.)
See also rndc delzone and rndc modzone.
delzone [-clean] zone [class [view]]
If the -clean argument is specified, the zone's master file (and journal file, if any) will be deleted along with the zone. Without the -clean option, zone files must be cleaned up by hand. (If the zone is of type "slave" or "stub", the files needing to be cleaned up will be reported in the output of the rndc delzone command.)
If the zone was originally added via rndc addzone, then it will be removed permanently. However, if it was originally configured in named.conf, then that original configuration is still in place; when the server is restarted or reconfigured, the zone will come back. To remove it permanently, it must also be removed from named.conf
See also rndc addzone and rndc modzone.
dnstap ( -reopen | -roll [number] )
dumpdb [-all|-cache|-zones|-adb|-bad|-fail] [view ...]
flush
flushname name [view]
flushtree name [view]
freeze [zone [class [view]]]
See also rndc thaw.
halt [-p]
See also rndc stop.
loadkeys zone [class [view]]
This command requires that the auto-dnssec zone option be set to maintain, and also requires the zone to be configured to allow dynamic DNS. (See "Dynamic Update Policies" in the Administrator Reference Manual for more details.)
managed-keys (status | refresh | sync) [class [view]]
modzone zone [class [view]] configuration
If the zone was originally added via rndc addzone, the configuration changes will be recorded permanently and will still be in effect after the server is restarted or reconfigured. However, if it was originally configured in named.conf, then that original configuration is still in place; when the server is restarted or reconfigured, the zone will revert to its original configuration. To make the changes permanent, it must also be modified in named.conf
See also rndc addzone and rndc delzone.
notify zone [class [view]]
notrace
See also rndc trace.
nta [( -class class | -dump | -force | -remove | -lifetime duration)] domain [view]
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 will abort the DNSSEC validation process and treat the data as insecure rather than bogus. This continues until the NTA's lifetime is elapsed.
NTAs persist across restarts of the named server. The NTAs for a view are saved in a file called name.nta, where name is the name of the view, or if it contains characters that are incompatible with use as a file name, a cryptographic hash generated from the name of the view.
An existing NTA can be removed by using the -remove option.
An NTA's lifetime can be specified with the -lifetime option. TTL-style suffixes can be used to specify the lifetime in seconds, minutes, or hours. If the specified NTA already exists, its lifetime will be updated to the new value. Setting lifetime to zero is equivalent to -remove.
If the -dump is used, any other arguments are ignored, and a list of existing NTAs is printed (note that this may include NTAs that are expired but have not yet been cleaned up).
Normally, named will periodically test to see whether data below an NTA can now be validated (see the nta-recheck option in the Administrator Reference Manual for details). If data can be validated, then the NTA is regarded as no longer necessary, and will be allowed to expire early. The -force overrides this behavior and forces an NTA to persist for its entire lifetime, regardless of whether data could be validated if the NTA were not present.
The view class can be specified with -class. The default is class IN, which is the only class for which DNSSEC is currently supported.
All of these options can be shortened, i.e., to -l, -r, -d, -f, and -c.
querylog [ on | off ]
Query logging can also be enabled by explicitly directing the queries category to a channel in the logging section of named.conf or by specifying querylog yes; in the options section of named.conf.
reconfig
recursing
refresh zone [class [view]]
reload
reload zone [class [view]]
retransfer zone [class [view]]
If the zone is configured to use inline-signing, the signed version of the zone is discarded; after the retransfer of the unsigned version is complete, the signed version will be regenerated with all new signatures.
scan
secroots [-] [view ...]
If the first argument is "-", then the output is returned via the rndc response channel and printed to the standard output. Otherwise, it is written to the secroots dump file, which defaults to named.secroots, but can be overridden via the secroots-file option in named.conf.
See also rndc managed-keys.
showzone zone [class [view]]
See also rndc zonestatus.
sign zone [class [view]]
This command requires that the auto-dnssec zone option be set to allow or maintain, and also requires the zone to be configured to allow dynamic DNS. (See "Dynamic Update Policies" in the Administrator Reference Manual for more details.)
See also rndc loadkeys.
signing [( -list | -clear keyid/algorithm | -clear all | -nsec3param ( parameters | none ) | -serial value ) ] zone [class [view]]
rndc signing -clear can remove a single key (specified in the same format that rndc signing -list uses to display it), or all keys. In either case, only completed keys are removed; any record indicating that a key has not yet finished signing the zone will be retained.
rndc signing -nsec3param sets the NSEC3 parameters for a zone. This is the only supported mechanism for using NSEC3 with inline-signing zones. Parameters are specified in the same format as an NSEC3PARAM resource record: hash algorithm, flags, iterations, and salt, in that order.
Currently, the only defined value for hash algorithm is 1, representing SHA-1. The flags may be set to 0 or 1, depending on whether you wish to set the opt-out bit in the NSEC3 chain. iterations defines the number of additional times to apply the algorithm when generating an NSEC3 hash. The salt is a string of data expressed in hexadecimal, a hyphen (`-') if no salt is to be used, or the keyword auto, which causes named to generate a random 64-bit salt.
So, for example, to create an NSEC3 chain using the SHA-1 hash algorithm, no opt-out flag, 10 iterations, and a salt value of "FFFF", use: rndc signing -nsec3param 1 0 10 FFFF zone. To set the opt-out flag, 15 iterations, and no salt, use: rndc signing -nsec3param 1 1 15 - zone.
rndc signing -nsec3param none removes an existing NSEC3 chain and replaces it with NSEC.
rndc signing -serial value sets the serial number of the zone to value. If the value would cause the serial number to go backwards it will be rejected. The primary use is to set the serial on inline signed zones.
stats
status
stop [-p]
See also rndc halt.
sync [-clean] [zone [class [view]]]
thaw [zone [class [view]]]
See also rndc freeze.
trace
trace level
See also rndc notrace.
tsig-delete keyname [view]
tsig-list
validation ( on | off | status ) [view ...]
zonestatus zone [class [view]]
See also rndc showzone.
LIMITATIONS¶
There is currently no way to provide the shared secret for a key_id without using the configuration file.
Several error messages could be clearer.
SEE ALSO¶
rndc.conf(5), rndc-confgen(8), named(8), named.conf(5), ndc(8), BIND 9 Administrator Reference Manual.
AUTHOR¶
Internet Systems Consortium, Inc.
COPYRIGHT¶
Copyright © 2000, 2001, 2004, 2005, 2007, 2013-2021 Internet Systems Consortium, Inc. ("ISC")
2014-08-15 | ISC |