1.. Copyright (C) Internet Systems Consortium, Inc. ("ISC") 2.. 3.. SPDX-License-Identifier: MPL-2.0 4.. 5.. This Source Code Form is subject to the terms of the Mozilla Public 6.. License, v. 2.0. If a copy of the MPL was not distributed with this 7.. file, you can obtain one at https://mozilla.org/MPL/2.0/. 8.. 9.. See the COPYRIGHT file distributed with this work for additional 10.. information regarding copyright ownership. 11 12.. highlight: console 13 14.. _man_rndc: 15 16rndc - name server control utility 17---------------------------------- 18 19Synopsis 20~~~~~~~~ 21 22:program:`rndc` [**-b** source-address] [**-c** config-file] [**-k** key-file] [**-s** server] [**-p** port] [**-q**] [**-r**] [**-V**] [**-y** key_id] [[**-4**] | [**-6**]] {command} 23 24Description 25~~~~~~~~~~~ 26 27``rndc`` controls the operation of a name server; it supersedes the 28``ndc`` utility. If ``rndc`` is 29invoked with no command line options or arguments, it prints a short 30summary of the supported commands and the available options and their 31arguments. 32 33``rndc`` communicates with the name server over a TCP connection, 34sending commands authenticated with digital signatures. In the current 35versions of ``rndc`` and ``named``, the only supported authentication 36algorithms are HMAC-MD5 (for compatibility), HMAC-SHA1, HMAC-SHA224, 37HMAC-SHA256 (default), HMAC-SHA384, and HMAC-SHA512. They use a shared 38secret on each end of the connection, which provides TSIG-style 39authentication for the command request and the name server's response. 40All commands sent over the channel must be signed by a key_id known to 41the server. 42 43``rndc`` reads a configuration file to determine how to contact the name 44server and decide what algorithm and key it should use. 45 46Options 47~~~~~~~ 48 49``-4`` 50 This option indicates use of IPv4 only. 51 52``-6`` 53 This option indicates use of IPv6 only. 54 55``-b source-address`` 56 This option indicates ``source-address`` as the source address for the connection to the 57 server. Multiple instances are permitted, to allow setting of both the 58 IPv4 and IPv6 source addresses. 59 60``-c config-file`` 61 This option indicates ``config-file`` as the configuration file instead of the default, 62 ``/etc/rndc.conf``. 63 64``-k key-file`` 65 This option indicates ``key-file`` as the key file instead of the default, 66 ``/etc/rndc.key``. The key in ``/etc/rndc.key`` is used to 67 authenticate commands sent to the server if the config-file does not 68 exist. 69 70``-s server`` 71 ``server`` is the name or address of the server which matches a server 72 statement in the configuration file for ``rndc``. If no server is 73 supplied on the command line, the host named by the default-server 74 clause in the options statement of the ``rndc`` configuration file 75 is used. 76 77``-p port`` 78 This option instructs BIND 9 to send commands to TCP port ``port`` instead of its default control 79 channel port, 953. 80 81``-q`` 82 This option sets quiet mode, where message text returned by the server is not printed 83 unless there is an error. 84 85``-r`` 86 This option instructs ``rndc`` to print the result code returned by ``named`` 87 after executing the requested command (e.g., ISC_R_SUCCESS, 88 ISC_R_FAILURE, etc.). 89 90``-V`` 91 This option enables verbose logging. 92 93``-y key_id`` 94 This option indicates use of the key ``key_id`` from the configuration file. For control message validation to succeed, ``key_id`` must be known 95 by ``named`` with the same algorithm and secret string. If no ``key_id`` is specified, 96 ``rndc`` first looks for a key clause in the server statement of 97 the server being used, or if no server statement is present for that 98 host, then in the default-key clause of the options statement. Note that 99 the configuration file contains shared secrets which are used to send 100 authenticated control commands to name servers, and should therefore 101 not have general read or write access. 102 103Commands 104~~~~~~~~ 105 106A list of commands supported by ``rndc`` can be seen by running ``rndc`` 107without arguments. 108 109Currently supported commands are: 110 111``addzone`` *zone* [*class* [*view*]] *configuration* 112 This command adds a zone while the server is running. This command requires the 113 ``allow-new-zones`` option to be set to ``yes``. The configuration 114 string specified on the command line is the zone configuration text 115 that would ordinarily be placed in ``named.conf``. 116 117 The configuration is saved in a file called ``viewname.nzf`` (or, if 118 ``named`` is compiled with liblmdb, an LMDB database file called 119 ``viewname.nzd``). ``viewname`` is the name of the view, unless the view 120 name contains characters that are incompatible with use as a file 121 name, in which case a cryptographic hash of the view name is used 122 instead. When ``named`` is restarted, the file is loaded into 123 the view configuration so that zones that were added can persist 124 after a restart. 125 126 This sample ``addzone`` command adds the zone ``example.com`` to 127 the default view: 128 129 ``rndc addzone example.com '{ type master; file "example.com.db"; };'`` 130 131 (Note the brackets around and semi-colon after the zone configuration 132 text.) 133 134 See also ``rndc delzone`` and ``rndc modzone``. 135 136``delzone`` [**-clean**] *zone* [*class* [*view*]] 137 This command deletes a zone while the server is running. 138 139 If the ``-clean`` argument is specified, the zone's master file (and 140 journal file, if any) are deleted along with the zone. Without 141 the ``-clean`` option, zone files must be deleted manually. (If the 142 zone is of type ``secondary`` or ``stub``, the files needing to be removed 143 are reported in the output of the ``rndc delzone`` command.) 144 145 If the zone was originally added via ``rndc addzone``, then it is 146 removed permanently. However, if it was originally configured in 147 ``named.conf``, then that original configuration remains in place; 148 when the server is restarted or reconfigured, the zone is 149 recreated. To remove it permanently, it must also be removed from 150 ``named.conf``. 151 152 See also ``rndc addzone`` and ``rndc modzone``. 153 154``dnssec`` ( **-status** | **-rollover** **-key** id [**-alg** *algorithm*] [**-when** *time*] | **-checkds** [**-key** *id* [**-alg** *algorithm*]] [**-when** *time*] ( *published* | *withdrawn* )) *zone* [*class* [*view*]] 155 This command allows you to interact with the "dnssec-policy" of a given 156 zone. 157 158 ``rndc dnssec -status`` show the DNSSEC signing state for the specified 159 zone. 160 161 ``rndc dnssec -rollover`` allows you to schedule key rollover for a 162 specific key (overriding the original key lifetime). 163 164 ``rndc dnssec -checkds`` will let ``named`` know that the DS for the given 165 key has been seen published into or withdrawn from the parent. This is 166 required in order to complete a KSK rollover. If the ``-key id`` argument 167 is specified, look for the key with the given identifier, otherwise if there 168 is only one key acting as a KSK in the zone, assume the DS of that key (if 169 there are multiple keys with the same tag, use ``-alg algorithm`` to 170 select the correct algorithm). The time that the DS has been published or 171 withdrawn is set to now, unless otherwise specified with the argument ``-when time``. 172 173``dnstap`` ( **-reopen** | **-roll** [*number*] ) 174 This command closes and re-opens DNSTAP output files. ``rndc dnstap -reopen`` allows 175 the output file to be renamed externally, so that ``named`` can 176 truncate and re-open it. ``rndc dnstap -roll`` causes the output file 177 to be rolled automatically, similar to log files. The most recent 178 output file has ".0" appended to its name; the previous most recent 179 output file is moved to ".1", and so on. If ``number`` is specified, then 180 the number of backup log files is limited to that number. 181 182``dumpdb`` [**-all** | **-cache** | **-zones** | **-adb** | **-bad** | **-expired** | **-fail**] [*view ...*] 183 This command dumps the server's caches (default) and/or zones to the dump file for 184 the specified views. If no view is specified, all views are dumped. 185 (See the ``dump-file`` option in the BIND 9 Administrator Reference 186 Manual.) 187 188``flush`` 189 This command flushes the server's cache. 190 191``flushname`` *name* [*view*] 192 This command flushes the given name from the view's DNS cache and, if applicable, 193 from the view's nameserver address database, bad server cache, and 194 SERVFAIL cache. 195 196``flushtree`` *name* [*view*] 197 This command flushes the given name, and all of its subdomains, from the view's 198 DNS cache, address database, bad server cache, and SERVFAIL cache. 199 200``freeze`` [*zone* [*class* [*view*]]] 201 This command suspends updates to a dynamic zone. If no zone is specified, then all 202 zones are suspended. This allows manual edits to be made to a zone 203 normally updated by dynamic update, and causes changes in the 204 journal file to be synced into the master file. All dynamic update 205 attempts are refused while the zone is frozen. 206 207 See also ``rndc thaw``. 208 209``halt`` [**-p**] 210 This command stops the server immediately. Recent changes made through dynamic 211 update or IXFR are not saved to the master files, but are rolled 212 forward from the journal files when the server is restarted. If 213 ``-p`` is specified, ``named``'s process ID is returned. This allows 214 an external process to determine when ``named`` has completed 215 halting. 216 217 See also ``rndc stop``. 218 219``loadkeys`` [*zone* [*class* [*view*]]] 220 This command fetches all DNSSEC keys for the given zone from the key directory. If 221 they are within their publication period, they are merged into the 222 zone's DNSKEY RRset. Unlike ``rndc sign``, however, the zone is not 223 immediately re-signed by the new keys, but is allowed to 224 incrementally re-sign over time. 225 226 This command requires that the zone be configured with a ``dnssec-policy``, or 227 that the ``auto-dnssec`` zone option be set to ``maintain``, and also requires the 228 zone to be configured to allow dynamic DNS. (See "Dynamic Update Policies" in 229 the Administrator Reference Manual for more details.) 230 231``managed-keys`` (*status* | *refresh* | *sync* | *destroy*) [*class* [*view*]] 232 This command inspects and controls the "managed-keys" database which handles 233 :rfc:`5011` DNSSEC trust anchor maintenance. If a view is specified, these 234 commands are applied to that view; otherwise, they are applied to all 235 views. 236 237 - When run with the ``status`` keyword, this prints the current status of 238 the managed-keys database. 239 240 - When run with the ``refresh`` keyword, this forces an immediate refresh 241 query to be sent for all the managed keys, updating the 242 managed-keys database if any new keys are found, without waiting 243 the normal refresh interval. 244 245 - When run with the ``sync`` keyword, this forces an immediate dump of 246 the managed-keys database to disk (in the file 247 ``managed-keys.bind`` or (``viewname.mkeys``). This synchronizes 248 the database with its journal file, so that the database's current 249 contents can be inspected visually. 250 251 - When run with the ``destroy`` keyword, the managed-keys database 252 is shut down and deleted, and all key maintenance is terminated. 253 This command should be used only with extreme caution. 254 255 Existing keys that are already trusted are not deleted from 256 memory; DNSSEC validation can continue after this command is used. 257 However, key maintenance operations cease until ``named`` is 258 restarted or reconfigured, and all existing key maintenance states 259 are deleted. 260 261 Running ``rndc reconfig`` or restarting ``named`` immediately 262 after this command causes key maintenance to be reinitialized 263 from scratch, just as if the server were being started for the 264 first time. This is primarily intended for testing, but it may 265 also be used, for example, to jumpstart the acquisition of new 266 keys in the event of a trust anchor rollover, or as a brute-force 267 repair for key maintenance problems. 268 269``modzone`` *zone* [*class* [*view*]] *configuration* 270 This command modifies the configuration of a zone while the server is running. This 271 command requires the ``allow-new-zones`` option to be set to ``yes``. 272 As with ``addzone``, the configuration string specified on the 273 command line is the zone configuration text that would ordinarily be 274 placed in ``named.conf``. 275 276 If the zone was originally added via ``rndc addzone``, the 277 configuration changes are recorded permanently and are still 278 in effect after the server is restarted or reconfigured. However, if 279 it was originally configured in ``named.conf``, then that original 280 configuration remains in place; when the server is restarted or 281 reconfigured, the zone reverts to its original configuration. To 282 make the changes permanent, it must also be modified in 283 ``named.conf``. 284 285 See also ``rndc addzone`` and ``rndc delzone``. 286 287``notify`` *zone* [*class* [*view*]] 288 This command resends NOTIFY messages for the zone. 289 290``notrace`` 291 This command sets the server's debugging level to 0. 292 293 See also ``rndc trace``. 294 295``nta`` [( **-class** *class* | **-dump** | **-force** | **-remove** | **-lifetime** *duration*)] *domain* [*view*] 296 This command sets a DNSSEC negative trust anchor (NTA) for ``domain``, with a 297 lifetime of ``duration``. The default lifetime is configured in 298 ``named.conf`` via the ``nta-lifetime`` option, and defaults to one 299 hour. The lifetime cannot exceed one week. 300 301 A negative trust anchor selectively disables DNSSEC validation for 302 zones that are known to be failing because of misconfiguration rather 303 than an attack. When data to be validated is at or below an active 304 NTA (and above any other configured trust anchors), ``named`` 305 aborts the DNSSEC validation process and treats the data as insecure 306 rather than bogus. This continues until the NTA's lifetime has 307 elapsed. 308 309 NTAs persist across restarts of the ``named`` server. The NTAs for a 310 view are saved in a file called ``name.nta``, where ``name`` is the name 311 of the view; if it contains characters that are incompatible with 312 use as a file name, a cryptographic hash is generated from the name of 313 the view. 314 315 An existing NTA can be removed by using the ``-remove`` option. 316 317 An NTA's lifetime can be specified with the ``-lifetime`` option. 318 TTL-style suffixes can be used to specify the lifetime in seconds, 319 minutes, or hours. If the specified NTA already exists, its lifetime 320 is updated to the new value. Setting ``lifetime`` to zero is 321 equivalent to ``-remove``. 322 323 If ``-dump`` is used, any other arguments are ignored and a list 324 of existing NTAs is printed. Note that this may include NTAs that are 325 expired but have not yet been cleaned up. 326 327 Normally, ``named`` periodically tests to see whether data below 328 an NTA can now be validated (see the ``nta-recheck`` option in the 329 Administrator Reference Manual for details). If data can be 330 validated, then the NTA is regarded as no longer necessary and is 331 allowed to expire early. The ``-force`` parameter overrides this behavior 332 and forces an NTA to persist for its entire lifetime, regardless of 333 whether data could be validated if the NTA were not present. 334 335 The view class can be specified with ``-class``. The default is class 336 ``IN``, which is the only class for which DNSSEC is currently 337 supported. 338 339 All of these options can be shortened, i.e., to ``-l``, ``-r``, 340 ``-d``, ``-f``, and ``-c``. 341 342 Unrecognized options are treated as errors. To refer to a domain or 343 view name that begins with a hyphen, use a double-hyphen (--) on the 344 command line to indicate the end of options. 345 346``querylog`` [(*on* | *off*)] 347 This command enables or disables query logging. For backward compatibility, this 348 command can also be used without an argument to toggle query logging 349 on and off. 350 351 Query logging can also be enabled by explicitly directing the 352 ``queries`` ``category`` to a ``channel`` in the ``logging`` section 353 of ``named.conf``, or by specifying ``querylog yes;`` in the 354 ``options`` section of ``named.conf``. 355 356``reconfig`` 357 This command reloads the configuration file and loads new zones, but does not reload 358 existing zone files even if they have changed. This is faster than a 359 full ``reload`` when there is a large number of zones, because it 360 avoids the need to examine the modification times of the zone files. 361 362``recursing`` 363 This command dumps the list of queries ``named`` is currently 364 recursing on, and the list of domains to which iterative queries 365 are currently being sent. 366 367 The first list includes all unique clients that are waiting for 368 recursion to complete, including the query that is awaiting a 369 response and the timestamp (seconds since the Unix epoch) of 370 when named started processing this client query. 371 372 The second list comprises of domains for which there are active 373 (or recently active) fetches in progress. It reports the number 374 of active fetches for each domain and the number of queries that 375 have been passed (allowed) or dropped (spilled) as a result of 376 the ``fetches-per-zone`` limit. (Note: these counters are not 377 cumulative over time; whenever the number of active fetches for 378 a domain drops to zero, the counter for that domain is deleted, 379 and the next time a fetch is sent to that domain, it is recreated 380 with the counters set to zero). 381 382``refresh`` *zone* [*class* [*view*]] 383 This command schedules zone maintenance for the given zone. 384 385``reload`` 386 This command reloads the configuration file and zones. 387 388``reload`` *zone* [*class* [*view*]] 389 This command reloads the given zone. 390 391``retransfer`` *zone* [*class* [*view*]] 392 This command retransfers the given secondary zone from the primary server. 393 394 If the zone is configured to use ``inline-signing``, the signed 395 version of the zone is discarded; after the retransfer of the 396 unsigned version is complete, the signed version is regenerated 397 with new signatures. 398 399``scan`` 400 This command scans the list of available network interfaces for changes, without 401 performing a full ``reconfig`` or waiting for the 402 ``interface-interval`` timer. 403 404``secroots`` [**-**] [*view* ...] 405 This command dumps the security roots (i.e., trust anchors configured via 406 ``trust-anchors``, or the ``managed-keys`` or ``trusted-keys`` statements 407 [both deprecated], or ``dnssec-validation auto``) and negative trust anchors 408 for the specified views. If no view is specified, all views are 409 dumped. Security roots indicate whether they are configured as trusted 410 keys, managed keys, or initializing managed keys (managed keys that have not 411 yet been updated by a successful key refresh query). 412 413 If the first argument is ``-``, then the output is returned via the 414 ``rndc`` response channel and printed to the standard output. 415 Otherwise, it is written to the secroots dump file, which defaults to 416 ``named.secroots``, but can be overridden via the ``secroots-file`` 417 option in ``named.conf``. 418 419 See also ``rndc managed-keys``. 420 421``serve-stale`` (**on** | **off** | **reset** | **status**) [*class* [*view*]] 422 This command enables, disables, resets, or reports the current status of the serving 423 of stale answers as configured in ``named.conf``. 424 425 If serving of stale answers is disabled by ``rndc-serve-stale off``, 426 then it remains disabled even if ``named`` is reloaded or 427 reconfigured. ``rndc serve-stale reset`` restores the setting as 428 configured in ``named.conf``. 429 430 ``rndc serve-stale status`` reports whether serving of stale 431 answers is currently enabled, disabled by the configuration, or 432 disabled by ``rndc``. It also reports the values of 433 ``stale-answer-ttl`` and ``max-stale-ttl``. 434 435``showzone`` *zone* [*class* [*view*]] 436 This command prints the configuration of a running zone. 437 438 See also ``rndc zonestatus``. 439 440``sign`` *zone* [*class* [*view*]] 441 This command fetches all DNSSEC keys for the given zone from the key directory (see 442 the ``key-directory`` option in the BIND 9 Administrator Reference 443 Manual). If they are within their publication period, they are merged into 444 the zone's DNSKEY RRset. If the DNSKEY RRset is changed, then the 445 zone is automatically re-signed with the new key set. 446 447 This command requires that the zone be configured with a ``dnssec-policy``, or 448 that the ``auto-dnssec`` zone option be set to ``allow`` or ``maintain``, 449 and also requires the zone to be configured to allow dynamic DNS. (See 450 "Dynamic Update Policies" in the BIND 9 Administrator Reference Manual for more 451 details.) 452 453 See also ``rndc loadkeys``. 454 455``signing`` [(**-list** | **-clear** *keyid/algorithm* | **-clear** *all* | **-nsec3param** ( *parameters* | none ) | **-serial** *value* ) *zone* [*class* [*view*]] 456 This command lists, edits, or removes the DNSSEC signing-state records for the 457 specified zone. The status of ongoing DNSSEC operations, such as 458 signing or generating NSEC3 chains, is stored in the zone in the form 459 of DNS resource records of type ``sig-signing-type``. 460 ``rndc signing -list`` converts these records into a human-readable 461 form, indicating which keys are currently signing or have finished 462 signing the zone, and which NSEC3 chains are being created or 463 removed. 464 465 ``rndc signing -clear`` can remove a single key (specified in the 466 same format that ``rndc signing -list`` uses to display it), or all 467 keys. In either case, only completed keys are removed; any record 468 indicating that a key has not yet finished signing the zone is 469 retained. 470 471 ``rndc signing -nsec3param`` sets the NSEC3 parameters for a zone. 472 This is the only supported mechanism for using NSEC3 with 473 ``inline-signing`` zones. Parameters are specified in the same format 474 as an NSEC3PARAM resource record: ``hash algorithm``, ``flags``, ``iterations``, 475 and ``salt``, in that order. 476 477 Currently, the only defined value for ``hash algorithm`` is ``1``, 478 representing SHA-1. The ``flags`` may be set to ``0`` or ``1``, 479 depending on whether the opt-out bit in the NSEC3 480 chain should be set. ``iterations`` defines the number of additional times to apply 481 the algorithm when generating an NSEC3 hash. The ``salt`` is a string 482 of data expressed in hexadecimal, a hyphen (`-') if no salt is to be 483 used, or the keyword ``auto``, which causes ``named`` to generate a 484 random 64-bit salt. 485 486 So, for example, to create an NSEC3 chain using the SHA-1 hash 487 algorithm, no opt-out flag, 10 iterations, and a salt value of 488 "FFFF", use: ``rndc signing -nsec3param 1 0 10 FFFF zone``. To set 489 the opt-out flag, 15 iterations, and no salt, use: 490 ``rndc signing -nsec3param 1 1 15 - zone``. 491 492 ``rndc signing -nsec3param none`` removes an existing NSEC3 chain and 493 replaces it with NSEC. 494 495 ``rndc signing -serial value`` sets the serial number of the zone to 496 ``value``. If the value would cause the serial number to go backwards, it 497 is rejected. The primary use of this parameter is to set the serial number on inline 498 signed zones. 499 500``stats`` 501 This command writes server statistics to the statistics file. (See the 502 ``statistics-file`` option in the BIND 9 Administrator Reference 503 Manual.) 504 505``status`` 506 This command displays the status of the server. Note that the number of zones includes 507 the internal ``bind/CH`` zone and the default ``./IN`` hint zone, if 508 there is no explicit root zone configured. 509 510``stop`` **-p** 511 This command stops the server, making sure any recent changes made through dynamic 512 update or IXFR are first saved to the master files of the updated 513 zones. If ``-p`` is specified, ``named(8)`'s process ID is returned. 514 This allows an external process to determine when ``named`` has 515 completed stopping. 516 517 See also ``rndc halt``. 518 519``sync`` **-clean** [*zone* [*class* [*view*]]] 520 This command syncs changes in the journal file for a dynamic zone to the master 521 file. If the "-clean" option is specified, the journal file is also 522 removed. If no zone is specified, then all zones are synced. 523 524``tcp-timeouts`` [*initial* *idle* *keepalive* *advertised*] 525 When called without arguments, this command displays the current values of the 526 ``tcp-initial-timeout``, ``tcp-idle-timeout``, 527 ``tcp-keepalive-timeout``, and ``tcp-advertised-timeout`` options. 528 When called with arguments, these values are updated. This allows an 529 administrator to make rapid adjustments when under a 530 denial-of-service (DoS) attack. See the descriptions of these options in the BIND 9 531 Administrator Reference Manual for details of their use. 532 533``thaw`` [*zone* [*class* [*view*]]] 534 This command enables updates to a frozen dynamic zone. If no zone is specified, 535 then all frozen zones are enabled. This causes the server to reload 536 the zone from disk, and re-enables dynamic updates after the load has 537 completed. After a zone is thawed, dynamic updates are no longer 538 refused. If the zone has changed and the ``ixfr-from-differences`` 539 option is in use, the journal file is updated to reflect 540 changes in the zone. Otherwise, if the zone has changed, any existing 541 journal file is removed. 542 543 See also ``rndc freeze``. 544 545``trace`` 546 This command increments the server's debugging level by one. 547 548``trace`` *level* 549 This command sets the server's debugging level to an explicit value. 550 551 See also ``rndc notrace``. 552 553``tsig-delete`` *keyname* [*view*] 554 This command deletes a given TKEY-negotiated key from the server. This does not 555 apply to statically configured TSIG keys. 556 557``tsig-list`` 558 This command lists the names of all TSIG keys currently configured for use by 559 ``named`` in each view. The list includes both statically configured keys and 560 dynamic TKEY-negotiated keys. 561 562``validation`` (**on** | **off** | **status**) [*view* ...]`` 563 This command enables, disables, or checks the current status of DNSSEC validation. By 564 default, validation is enabled. 565 566 The cache is flushed when validation is turned on or off to avoid using data 567 that might differ between states. 568 569``zonestatus`` *zone* [*class* [*view*]] 570 This command displays the current status of the given zone, including the master 571 file name and any include files from which it was loaded, when it was 572 most recently loaded, the current serial number, the number of nodes, 573 whether the zone supports dynamic updates, whether the zone is DNSSEC 574 signed, whether it uses automatic DNSSEC key management or inline 575 signing, and the scheduled refresh or expiry times for the zone. 576 577 See also ``rndc showzone``. 578 579``rndc`` commands that specify zone names, such as ``reload``, 580``retransfer``, or ``zonestatus``, can be ambiguous when applied to zones 581of type ``redirect``. Redirect zones are always called ``.``, and can be 582confused with zones of type ``hint`` or with secondary copies of the root 583zone. To specify a redirect zone, use the special zone name 584``-redirect``, without a trailing period. (With a trailing period, this 585would specify a zone called "-redirect".) 586 587Limitations 588~~~~~~~~~~~ 589 590There is currently no way to provide the shared secret for a ``key_id`` 591without using the configuration file. 592 593Several error messages could be clearer. 594 595See Also 596~~~~~~~~ 597 598:manpage:`rndc.conf(5)`, :manpage:`rndc-confgen(8)`, 599:manpage:`named(8)`, :manpage:`named.conf(5)`, :manpage:`ndc(8)`, BIND 9 Administrator 600Reference Manual. 601