EVOLUTION-NINJA

Edit File: man.rndc.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>rndc</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.79.1">
<link rel="home" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
<link rel="up" href="Bv9ARM.ch13.html" title="Manual pages">
<link rel="prev" href="man.rndc.conf.html" title="rndc.conf">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">rndc</th></tr>
<tr>
<td width="20%" align="left">
<a accesskey="p" href="man.rndc.conf.html">Prev</a>�</td>
<th width="60%" align="center">Manual pages</th>
<td width="20%" align="right">�</td>
</tr>
</table>
<hr>
</div>
<div class="refentry">
<a name="man.rndc"></a><div class="titlepage"></div>
<div class="refnamediv">
<h2>Name</h2>
rndc &#8212; name server control utility
</div>
<div class="refsynopsisdiv">
<h2>Synopsis</h2>
<div class="cmdsynopsis"><code class="command">rndc</code> [<code class="option">-b <code>source-address</code></code>] [<code class="option">-c <code>config-file</code></code>] [<code class="option">-k <code>key-file</code></code>] [<code class="option">-s <code>server</code></code>] [<code class="option">-p <code>port</code></code>] [<code class="option">-q</code>] [<code class="option">-r</code>] [<code class="option">-V</code>] [<code class="option">-y <code>key_id</code></code>] {command}</div>
</div>
<div class="refsection">
<a name="id-1.14.39.7"></a><h2>DESCRIPTION</h2>
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.
 
</div>
<div class="refsection">
<a name="id-1.14.39.8"></a><h2>OPTIONS</h2>
<div class="variablelist"><dl class="variablelist">
<dt>-b <code>source-address</code></dt>
<dd>
	 Use <code>source-address</code>
	 as the source address for the connection to the server.
	 Multiple instances are permitted to allow setting of both
	 the IPv4 and IPv6 source addresses.
	 </dd>
<dt>-c <code>config-file</code></dt>
<dd>
	 Use <code>config-file</code>
	 as the configuration file instead of the default,
	 <code class="filename">/etc/rndc.conf</code>.
	 </dd>
<dt>-k <code>key-file</code></dt>
<dd>
	 Use <code>key-file</code>
	 as the key file instead of the default,
	 <code class="filename">/etc/rndc.key</code>. The key in
	 <code class="filename">/etc/rndc.key</code> will be used to
	 authenticate
	 commands sent to the server if the <code>config-file</code>
	 does not exist.
	 </dd>
<dt>-s <code>server</code></dt>
<dd><code>server</code> is
	 the name or address of the server which matches a
	 server statement in the configuration file for
	 rndc. If no server is supplied on the
	 command line, the host named by the default-server clause
	 in the options statement of the rndc
	 configuration file will be used.
	 </dd>
<dt>-p <code>port</code></dt>
<dd>
	 Send commands to TCP port
	 <code>port</code>
	 instead
	 of BIND 9's default control channel port, 953.
	 </dd>
<dt>-q</dt>
<dd>
	 Quiet mode: Message text returned by the server
	 will not be printed except when there is an error.
	 </dd>
<dt>-r</dt>
<dd>
	 Instructs rndc to print the result code
	 returned by named after executing the
	 requested command (e.g., ISC_R_SUCCESS, ISC_R_FAILURE, etc).
	 </dd>
<dt>-V</dt>
<dd>
	 Enable verbose logging.
	 </dd>
<dt>-y <code>key_id</code></dt>
<dd>
	 Use the key <code>key_id</code>
	 from the configuration file.
	 <code>key_id</code>
	 must be
	 known by named with the same algorithm and secret string
	 in order for control message validation to succeed.
	 If no <code>key_id</code>
	 is specified, rndc will first look
	 for a key clause in the server statement of the server
	 being used, or if no server statement is present for that
	 host, then the default-key clause of the options statement.
	 Note that the configuration file contains shared secrets
	 which are used to send authenticated control commands
	 to name servers. It should therefore not have general read
	 or write access.
	 </dd>
</dl></div>
</div>
<div class="refsection">
<a name="id-1.14.39.9"></a><h2>COMMANDS</h2>

 A list of commands supported by rndc can
 be seen by running rndc without arguments.
 

 Currently supported commands are:
 
<div class="variablelist"><dl class="variablelist">
<dt><code>addzone <code>zone</code> [<code>class</code> [<code>view</code>]] <code>configuration</code> </code></dt>
<dd>

	 Add a zone while the server is running. This
	 command requires the
	 allow-new-zones option to be set
	 to <code>yes</code>. The
	 <code>configuration</code> string
	 specified on the command line is the zone
	 configuration text that would ordinarily be
	 placed in <code class="filename">named.conf</code>.
	 

	 The configuration is saved in a file called
	 <code class="filename"><code>name</code>.nzf</code>,
	 where <code>name</code> 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 <code class="literal">example.com</code>
	 to the default view:
	 

<code class="prompt">$ </code><code>rndc addzone example.com '{ type master; file "example.com.db"; };'</code>
	 

	 (Note the brackets and semi-colon around the zone
	 configuration text.)
	 

	 See also rndc delzone and rndc modzone.
	 
</dd>
<dt><code>delzone [-clean] <code>zone</code> [<code>class</code> [<code>view</code>]] </code></dt>
<dd>

	 Delete a zone while the server is running.
	 

	 If the <code class="option">-clean</code> argument is specified,
	 the zone's master file (and journal file, if any)
	 will be deleted along with the zone. Without the
	 <code class="option">-clean</code> 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 <code class="filename">named.conf</code>, 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 <code class="filename">named.conf</code>
	 

	 See also rndc addzone and rndc modzone.
	 
</dd>
<dt><code>dnstap ( -reopen | -roll [<code>number</code>] )</code></dt>
<dd>
	 Close and re-open DNSTAP output files.
	 rndc dnstap -reopen allows the output
	 file to be renamed externally, so
	 that named can truncate and re-open it.
	 rndc dnstap -roll causes the output file
	 to be rolled automatically, similar to log files; the most
	 recent output file has ".0" appended to its name; the
	 previous most recent output file is moved to ".1", and so on.
	 If <code>number</code> is specified, then the
	 number of backup log files is limited to that number.
	 </dd>
<dt><code>dumpdb [-all|-cache|-zones|-adb|-bad|-fail] [<code>view ...</code>]</code></dt>
<dd>
	 Dump the server's caches (default) and/or zones to
	 the dump file for the specified views. If no view
 is specified, all views are dumped.
	 (See the dump-file option in
	 the BIND 9 Administrator Reference Manual.)
	 </dd>
<dt><code>flush</code></dt>
<dd>
	 Flushes the server's cache.
	 </dd>
<dt><code>flushname</code> <code>name</code> [<code>view</code>] </dt>
<dd>
	 Flushes the given name from the view's DNS cache
	 and, if applicable, from the view's nameserver address
	 database, bad server cache and SERVFAIL cache.
	 </dd>
<dt><code>flushtree</code> <code>name</code> [<code>view</code>] </dt>
<dd>
	 Flushes the given name, and all of its subdomains,
	 from the view's DNS cache, address database,
	 bad server cache, and SERVFAIL cache.
	 </dd>
<dt><code>freeze [<code>zone</code> [<code>class</code> [<code>view</code>]]]</code></dt>
<dd>

	 Suspend updates to a dynamic zone. If no zone is
	 specified, then all zones are suspended. This allows
	 manual edits to be made to a zone normally updated by
	 dynamic update. It also causes changes in the
	 journal file to be synced into the master file.
	 All dynamic update attempts will be refused while
	 the zone is frozen.
	 

	 See also rndc thaw.
	 
</dd>
<dt><code>halt [-p]</code></dt>
<dd>

	 Stop the server immediately. Recent changes
	 made through dynamic update or IXFR are not saved to
	 the master files, but will be rolled forward from the
	 journal files when the server is restarted.
	 If <code class="option">-p</code> is specified named's process id is returned.
	 This allows an external process to determine when named
	 had completed halting.
	 

	 See also rndc stop.
	 
</dd>
<dt><code>loadkeys <code>zone</code> [<code>class</code> [<code>view</code>]]</code></dt>
<dd>

	 Fetch all DNSSEC keys for the given zone
	 from the key directory. If they are within
	 their publication period, merge them into the
	 zone's DNSKEY RRset. Unlike rndc
	 sign, however, the zone is not
	 immediately re-signed by the new keys, but is
	 allowed to incrementally re-sign over time.
	 

	 This command requires that the
	 auto-dnssec zone option
	 be set to <code class="literal">maintain</code>,
	 and also requires the zone to be configured to
	 allow dynamic DNS.
	 (See "Dynamic Update Policies" in the Administrator
	 Reference Manual for more details.)
	 
</dd>
<dt><code>managed-keys <code>(status | refresh | sync)</code> [<code>class</code> [<code>view</code>]]</code></dt>
<dd>
	 When run with the "status" keyword, print the current
	 status of the managed-keys database for the specified
	 view, or for all views if none is specified. When run
	 with the "refresh" keyword, force an immediate refresh
	 of all the managed-keys in the specified view, or all
	 views. When run with the "sync" keyword, force an
	 immediate dump of the managed-keys database to disk (in
	 the file <code class="filename">managed-keys.bind</code> or
	 (<code class="filename"><code>viewname</code>.mkeys</code>).
	 </dd>
<dt><code>modzone <code>zone</code> [<code>class</code> [<code>view</code>]] <code>configuration</code> </code></dt>
<dd>

	 Modify the configuration of a zone while the server
	 is running. This command requires the
	 allow-new-zones option to be
	 set to <code>yes</code>. As with
	 addzone, the
	 <code>configuration</code> string
	 specified on the command line is the zone
	 configuration text that would ordinarily be
	 placed in <code class="filename">named.conf</code>.
	 

	 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
	 <code class="filename">named.conf</code>, 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
	 <code class="filename">named.conf</code>
	 

	 See also rndc addzone and rndc delzone.
	 
</dd>
<dt><code>notify <code>zone</code> [<code>class</code> [<code>view</code>]]</code></dt>
<dd>
	 Resend NOTIFY messages for the zone.
	 </dd>
<dt><code>notrace</code></dt>
<dd>

	 Sets the server's debugging level to 0.
	 

	 See also rndc trace.
	 
</dd>
<dt><code>nta
	 [( -class <code>class</code> | -dump | -force | -remove | -lifetime <code>duration</code>)]
	<code>domain</code>
	[<code>view</code>]
	</code></dt>
<dd>

	 Sets a DNSSEC negative trust anchor (NTA)
	 for <code class="option">domain</code>, with a lifetime of
	 <code class="option">duration</code>. The default lifetime is
	 configured in <code class="filename">named.conf</code> via the
	 <code class="option">nta-lifetime</code> option, and defaults to
	 one hour. The lifetime cannot exceed one week.
	 

	 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
	 <code class="filename"><code>name</code>.nta</code>,
	 where <code>name</code> 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
	 <code class="option">-remove</code> option.
	 

	 An NTA's lifetime can be specified with the
	 <code class="option">-lifetime</code> 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 <code class="option">lifetime</code> to zero
	 is equivalent to <code class="option">-remove</code>.
	 

	 If the <code class="option">-dump</code> 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 <code class="option">nta-recheck</code> 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 <code class="option">-force</code> 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 <code class="option">-class</code>.
	 The default is class <code>IN</code>, which is
	 the only class for which DNSSEC is currently supported.
	 

	 All of these options can be shortened, i.e., to
	 <code class="option">-l</code>, <code class="option">-r</code>, <code class="option">-d</code>,
	 <code class="option">-f</code>, and <code class="option">-c</code>.
	 
</dd>
<dt><code>querylog</code> [ on | off ] </dt>
<dd>

	 Enable or disable query logging. (For backward
	 compatibility, this command can also be used without
	 an argument to toggle query logging on and off.)
	 

	 Query logging can also be enabled
	 by explicitly directing the queries
	 category to a
	 channel in the
	 logging section of
	 <code class="filename">named.conf</code> or by specifying
	 querylog yes; in the
	 options section of
	 <code class="filename">named.conf</code>.
	 
</dd>
<dt><code>reconfig</code></dt>
<dd>
	 Reload the configuration file and load new zones,
	 but do not reload existing zone files even if they
	 have changed.
	 This is faster than a full reload when there
	 is a large number of zones because it avoids the need
	 to examine the
	 modification times of the zones files.
	 </dd>
<dt><code>recursing</code></dt>
<dd>
	 Dump the list of queries named is currently
	 recursing on, and the list of domains to which iterative
	 queries are currently being sent. (The second list includes
	 the number of fetches currently active for the given domain,
	 and how many have been passed or dropped because of the
	 <code class="option">fetches-per-zone</code> option.)
	 </dd>
<dt><code>refresh <code>zone</code> [<code>class</code> [<code>view</code>]]</code></dt>
<dd>
	 Schedule zone maintenance for the given zone.
	 </dd>
<dt><code>reload</code></dt>
<dd>
	 Reload configuration file and zones.
	 </dd>
<dt><code>reload <code>zone</code> [<code>class</code> [<code>view</code>]]</code></dt>
<dd>
	 Reload the given zone.
	 </dd>
<dt><code>retransfer <code>zone</code> [<code>class</code> [<code>view</code>]]</code></dt>
<dd>

	 Retransfer the given slave zone from the master server.
	 

	 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.
	 
</dd>
<dt><code>scan</code></dt>
<dd>
	 Scan the list of available network interfaces
	 for changes, without performing a full
	 reconfig or waiting for the
	 interface-interval timer.
	 </dd>
<dt><code>secroots [-] [<code>view ...</code>]</code></dt>
<dd>

	 Dump the server's security roots and negative trust anchors
	 for the specified views. If no view is specified, all views
	 are dumped.
	 

	 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 <code class="filename">named.secroots</code>, but can be
	 overridden via the <code class="option">secroots-file</code> option in
	 <code class="filename">named.conf</code>.
	 

	 See also rndc managed-keys.
	 
</dd>
<dt><code>showzone <code>zone</code> [<code>class</code> [<code>view</code>]] </code></dt>
<dd>

	 Print the configuration of a running zone.
	 

	 See also rndc zonestatus.
	 
</dd>
<dt><code>sign <code>zone</code> [<code>class</code> [<code>view</code>]]</code></dt>
<dd>

	 Fetch all DNSSEC keys for the given zone
	 from the key directory (see the
	 key-directory option in
	 the BIND 9 Administrator Reference Manual). If they are within
	 their publication period, merge them into the
	 zone's DNSKEY RRset. If the DNSKEY RRset
	 is changed, then the zone is automatically
	 re-signed with the new key set.
	 

	 This command requires that the
	 auto-dnssec zone option be set
	 to <code class="literal">allow</code> or
	 <code class="literal">maintain</code>,
	 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.
	 
</dd>
<dt><code>signing [( -list | -clear <code>keyid/algorithm</code> | -clear <code class="literal">all</code> | -nsec3param ( <code>parameters</code> | <code class="literal">none</code> ) | -serial <code>value</code> ) ] <code>zone</code> [<code>class</code> [<code>view</code>]] </code></dt>
<dd>

	 List, edit, or remove the DNSSEC signing state records
	 for the specified zone. The status of ongoing DNSSEC
	 operations (such as signing or generating
	 NSEC3 chains) is stored in the zone in the form
	 of DNS resource records of type
	 sig-signing-type.
	 rndc signing -list converts
	 these records into a human-readable form,
	 indicating which keys are currently signing
	 or have finished signing the zone, and which NSEC3
	 chains are being created or removed.
	 

	 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 <code class="literal">1</code>, representing SHA-1.
	 The <code class="option">flags</code> may be set to
	 <code class="literal">0</code> or <code class="literal">1</code>,
	 depending on whether you wish to set the opt-out
	 bit in the NSEC3 chain. <code class="option">iterations</code>
	 defines the number of additional times to apply
	 the algorithm when generating an NSEC3 hash. The
	 <code class="option">salt</code> is a string of data expressed
	 in hexadecimal, a hyphen (`-') if no salt is
	 to be used, or the keyword <code class="literal">auto</code>,
	 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 <code>zone</code>.
	 To set the opt-out flag, 15 iterations, and no
	 salt, use:
	 rndc signing -nsec3param 1 1 15 - <code>zone</code>.
	 

	 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.
	 
</dd>
<dt><code>stats</code></dt>
<dd>
	 Write server statistics to the statistics file.
	 (See the statistics-file option in
	 the BIND 9 Administrator Reference Manual.)
	 </dd>
<dt><code>status</code></dt>
<dd>
	 Display status of the server.
	 Note that the number of zones includes the internal bind/CH zone
	 and the default ./IN
	 hint zone if there is not an
	 explicit root zone configured.
	 </dd>
<dt><code>stop [-p]</code></dt>
<dd>

	 Stop the server, making sure any recent changes
	 made through dynamic update or IXFR are first saved to
	 the master files of the updated zones.
	 If <code class="option">-p</code> is specified named's process id is returned.
	 This allows an external process to determine when named
	 had completed stopping.
	 
See also rndc halt.
</dd>
<dt><code>sync [-clean] [<code>zone</code> [<code>class</code> [<code>view</code>]]]</code></dt>
<dd>
	 Sync changes in the journal file for a dynamic zone
	 to the master file. If the "-clean" option is
	 specified, the journal file is also removed. If
	 no zone is specified, then all zones are synced.
	 </dd>
<dt><code>thaw [<code>zone</code> [<code>class</code> [<code>view</code>]]]</code></dt>
<dd>

	 Enable updates to a frozen dynamic zone. If no
	 zone is specified, then all frozen zones are
	 enabled. This causes the server to reload the zone
	 from disk, and re-enables dynamic updates after the
	 load has completed. After a zone is thawed,
	 dynamic updates will no longer be refused. If
	 the zone has changed and the
	 ixfr-from-differences option is
	 in use, then the journal file will be updated to
	 reflect changes in the zone. Otherwise, if the
	 zone has changed, any existing journal file will be
	 removed.
	 
See also rndc freeze.
</dd>
<dt><code>trace</code></dt>
<dd>
	 Increment the servers debugging level by one.
	 </dd>
<dt><code>trace <code>level</code></code></dt>
<dd>

	 Sets the server's debugging level to an explicit
	 value.
	 

	 See also rndc notrace.
	 
</dd>
<dt><code>tsig-delete</code> <code>keyname</code> [<code>view</code>]</dt>
<dd>
	 Delete a given TKEY-negotiated key from the server.
	 (This does not apply to statically configured TSIG
	 keys.)
	 </dd>
<dt><code>tsig-list</code></dt>
<dd>
	 List the names of all TSIG keys currently configured
	 for use by named in each view. The
	 list includes both statically configured keys and dynamic
	 TKEY-negotiated keys.
	 </dd>
<dt><code>validation ( on | off | status ) [<code>view ...</code>] </code></dt>
<dd>
	 Enable, disable, or check the current status of
	 DNSSEC validation.
	 Note dnssec-enable also needs to be
	 set to <code>yes</code> or
	 <code>auto</code> to be effective.
	 It defaults to enabled.
	 </dd>
<dt><code>zonestatus <code>zone</code> [<code>class</code> [<code>view</code>]]</code></dt>
<dd>

	 Displays the current status of the given zone,
	 including the master file name and any include
	 files from which it was loaded, when it was most
	 recently loaded, the current serial number, the
	 number of nodes, whether the zone supports
	 dynamic updates, whether the zone is DNSSEC
	 signed, whether it uses automatic DNSSEC key
	 management or inline signing, and the scheduled
	 refresh or expiry times for the zone.
	 

	 See also rndc showzone.
	 
</dd>
</dl></div>
</div>
<div class="refsection">
<a name="id-1.14.39.10"></a><h2>LIMITATIONS</h2>

 There is currently no way to provide the shared secret for a
 <code class="option">key_id</code> without using the configuration file.
 

 Several error messages could be clearer.
 
</div>
<div class="refsection">
<a name="id-1.14.39.11"></a><h2>SEE ALSO</h2>
rndc.conf(5),
 rndc-confgen(8),
 named(8),
 named.conf(5),
 ndc(8),
 BIND 9 Administrator Reference Manual.
 
</div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a accesskey="p" href="man.rndc.conf.html">Prev</a>�</td>
<td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch13.html">Up</a></td>
<td width="40%" align="right">�</td>
</tr>
<tr>
<td width="40%" align="left" valign="top">
<code class="filename">rndc.conf</code>�</td>
<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
<td width="40%" align="right" valign="top">�</td>
</tr>
</table>
</div>
BIND 9.11.36 (Extended Support Version)
</body>
</html>