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