HP OpenVMS Systems Documentation

Content starts here HP TCP/IP Services for OpenVMS

HP TCP/IP Services for OpenVMS

Previous Contents Index



Controls the operation of the BIND server.


rndc [-c config] [-s server] [-p port] ["-V"] [-y key-id] command


The rndc utility controls the operation of a name server. rndc communicates with the name server over a TCP connection, sending commands authenticated with digital signatures. The only supported authentication algorithm is HMAC-MD5, which uses 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.

In BIND Version 9, rndc supports all the commands of the BIND Version 8 ndc utility except start , restart , and stop . Use the BIND startup and shutdown command procedures, as described in Section 6.4, to accomplish these tasks.

The rndc utility reads a configuration file to determine how to contact the name server and to decide what algorithm and key it should use.

A configuration file is required, since all communication with the server is authenticated with digital signatures that rely on a shared secret. The default location for the rndc configuration file is TCPIP$ETC:RNDC.CONF, but an alternate location can be specified with the -c option. If the configuration file is not found, rndc also looks in TCPIP$ETC:RNDC.KEY. The RNDC.KEY file is generated by running rndc_confgen -a . This command provides basic functionality, but it offers less configuration flexibility than modifying the RNDC.CONF file.


For the BIND server to recognize a newly generated RNDC.KEY file, you must stop and restart the BIND server.

Format of the RNDC.CONF File

The configuration file for the rndc utility is TCPIP$ETC:RNDC.CONF. The structure of this file is similar to TCPIP$BIND.CONF. Statements are enclosed in braces and are terminated with semicolons. Clauses in the statements are also terminated with semicolons. For example:

options {
    default-server    localhost;
    default-key       samplekey;

server localhost {
    key               samplekey;

key samplekey {
    algorithm         hmac-md5
    secret            "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW";

Three statements are used in the RNDC.CONF file:

  • The options statement contains three clauses:
    • The default-server clause is followed by the name or address of a name server. This host is used when the name server is not specified as an argument to rndc .
    • The default-key clause is followed by the name of a key, which is represented by a key statement and is used when the key-id is not specified on the rndc command line and when no key clause is found in a matching server statement. This key is used to authenticate the server's commands and response.
    • The default-port clause is followed by the port to connect to on the remote name server. This port is used if no -p port statement is supplied on the rndc command line and no port clause is included in a matching server statement.
  • The server statement specifies a host name or address for a name server. The statement may include the key clause and the port clause. The key name must match the name of a key statement in the file. The port number specifies the port to connect to.
  • The key statement specifies the name of a key. The statement has two clauses:
    • algorithm specifies the encryption algorithm for rndc to use (HMAC-MD5).
    • A secret clause containing the 64-bit encoding of the algorithm's encryption key. The base-64 string is enclosed in quotation marks.
      To generate the base-64 string for the secret clause, use the rndc_confgen utility. For example, enter the following command:

      $ rndc_confgen

      A complete RNDC.CONF file, including the randomly-generated key, is automatically generated. The rndc_confgen command also displays commented key and controls statements for the TCPIP$BIND.CONF file.



Reloads configuration file and zones.

reload zone [class [view]]

Reload the given zone.

refresh zone [class [view]]

Schedule zone maintenance for the given zone.


Reloads the configuration file and loads new zones, but does 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.


Writes server statistics to the statistics file, TCPIP$BIND.STATS.


Toggles query logging. Query logging can also be enabled by explicitly directing the queries category to a channel in the logging section of TCPIP$BIND.CONF.


Dumps the server's caches to the dump file, TCPIP$BIND_DUMP.DB.


Increments the servers debugging level by one.

trace level

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


Sets the server's debugging level to 0.


Flushes the server's cache.


Saves any pending dynamic updates being stored in the zone journal (_JNL) files to the master zone files. (This command is available on OpenVMS systems only.)


Displays the status of the server. The number of zones includes the internal /CH zone, and the default ./IN hint zone if no root zone has been explicitly configured.


-c config-file

Uses config-file as the configuration file instead of the default, TCPIP$ETC:RNDC.CONF.

-s server

Specifies 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 option statement of the configuration file is used.

-p port

Send commands to the specified TCP port instead of the default control channel port, 953.


Enables verbose logging. Use quotation marks to preserve uppercase options.

-y keyid

Use the specified keyid from the configuration file specified with the -c option. If the configuration file was not specified on the command line, the rndc configuration file, RNDC.CONF, is used. The keyid must be known by the BIND server with the same algorithm and secret string in order for control message validation to succeed.

If no keyid is specified, rndc first looks 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 that are used to send authenticated control commands to name servers. Therefore, the file should not have general read or write access.


Generates the configuration files used by the rndc utility.


rndc_confgen [-a] [-b keysize] [-c keyfile] [-h] [-k keyname] [-p port] [-r randomfile] [-s address]


The rndc_confgen utility generates configuration files for the rndc utility. It can be used as a convenient alternative to writing the RNDC.CONF file and the corresponding controls and key statements in TCPIP$BIND.CONF by hand. The utility can be run with the -a option to set up an RNDC.KEY file, thereby avoiding the need for an RNDC.CONF file and a controls statement.



Configures rndc automatically. This option creates the file RNDC.KEY in TCPIP$ETC that is read by both rndc and the BIND server on startup. The RNDC.KEY file defines a default command channel and authentication key, allowing rndc to communicate with the BIND server with no further configuration.

Using the -a option allows BIND Version 9 and rndc to be used as drop-in replacements for BIND Version 8 and ndc , with no changes to the existing TCPIP$BIND.CONF file. For information about BIND Version 8, see Appendix D.


For the BIND server to recognize a newly generated RNDC.KEY file, you must stop and restart the BIND server.

-b keysize

Specifies the size of the authentication key in bits. Must be between 1 and 512 bits; the default is 128.

-c keyfile

Used with the -a option to specify an alternate location for RNDC.KEY.


Prints a short summary of the options and arguments to rndc_confgen .

-k keyname

Specifies the key name of the rndc authentication key. This must be a valid domain name. The default is rndc-key .

-p port

Specifies the command channel port where the BIND server listens for connections from rndc . The default is 953.

-r randomfile

Specifies a source of random data for generating the authorization. The default source of randomness is keyboard input. randomfile specifies the name of a file containing random data to be used instead of the default. The special value keyboard indicates that keyboard input should be used.

-s address

Specifies the IP address where the BIND server listens for command channel connections from rndc . The default is the loopback address


Updates Domain Name System (DNS) servers interactively.


nsupdate [-d] [-y keyname:secret | -k keyfile] [-v] [file-name]


The nsupdate utility creates dynamic updates, which are sent to a DNS server to update the zone database. nsupdate uses the DNS resolver library to send dynamic updates to a DNS server requesting the addition or deletion of resource records. The zone must be configured to accept dynamic updates for the nsupdate utility to work.

The nsupdate command can accept either a command or the name of a command file.

Zones that are under dynamic control (with nsupdate or a DHCP server) should not be edited by hand. Manual updates could conflict with dynamic updates, causing data to be lost.

If you use a file to supply the updates, the data in the file must be in the following format:

category section name ttl type rdata

In this format:

  • category is any one of the following keywords:
    • update
    • zone
    • prereq
  • section is any one of the following keywords:
    • add
    • delete
    • nxdomain
    • yxdomain
    • nxrrset
    • yxrrset
  • name is the name of the entry being added.
  • ttl is the time to live (in seconds) for this entry. After this time period, the name server no longer serves the entry.
  • type specifies the RR type (for example, A, CNAME, NS, MX, TXT).
  • rdata specifies the data appropriate for the RR type being updated.

Lines beginning with a semicolon are comments and are ignored.



Specifies debug mode.

-y keyname:secret

Generates a signature, where keyname specifies the name of the key and secret is a base-64 encoded secret. This option is not recommended because it displays the shared secret in plain text. Instead, use the -k option.

-k keyfile

Specifies a file that contains the shared secret. The file name has the following format:


For historical reasons, the file Kname.157-random_KEY must also be present.


Specifies that nsupdate use the TCP protocol instead of the UDP protocol. By default, nsupdate sends update requests using UDP.


Specifies a file that contains nsupdate commands.

If you do not specify the name of a command file, the NSUPDATE command prompts for a command line. Enter one or more of the following commands.


server servername [port]

Sends all dynamic update requests to the specified name server. When no name server is specified, the nsupdate utility sends updates to the master server of the correct zone. The MNAME field of that zone's SOA record identifies the master server for that zone. port is the port number to which the dynamic update requests are sent on the specified name server. If no port number is specified, the default DNS port number of 53 is used.

local address [port]

Sends all dynamic update requests using the local address. When no local address is provided, the nsupdate utility sends updates using an address and port chosen by the system. Specify port to make requests come from a specific port. If no port number is specified, the system assigns one.

zone zonename

Specifies that all updates are to be made to the specified zone. If no zone command is provided, the nsupdate utility attempts to determine the correct zone to update based on the rest of the input.

key keyname secret

Specifies that all updates are to be TSIG signed, using the specified keyname and key secret pair.

The key command overrides any key specified on the command line using the -y or -k options.

prereq nxdomain domain-name

Requires that no resource record of any type exist with the specified domain name.

prereq yxrset domain-name type [data]

Makes the presence of an RR set of the specified type owned by domain-name a prerequisite to performing the update. This requires that a resource record of the specified type, class, and domain name must exist. If class is omitted, IN (Internet) is assumed.

prereq nxrrset domain-name [class] {type}

Makes the nonexistence of an RRset of type owned by domain-name a prerequisite to performing the update specified in successive update commands. This requires that no resource record exist of the specified type, class, and domain name. If class is omitted, IN (Internet) is assumed.

The data from each set of prerequisites of this form sharing a common type, class, and domain name are combined to form a set of resource records. This set of resource records must exactly match the set of resource records on the zone at the given type, class, and domain name. The data is written in the standard text representation of the resource record's RDATA.

prereq yxdomain domain-name

Makes the existence of the specified domain-name a prerequisite to performing the update. This requires that the domain name has at least one resource record of any type.

update delete domain-name ttl [class] [type] [rdata]

Deletes any resource records with the specified domain name. If type and data are provided, only matching resource records are removed. If class is omitted, IN (Internet) is assumed. The ttl value is ignored and is included only for compatibility.

update add domain-name ttl [class] type data

Adds a new resource record with the specified ttl, class, and data to the zone. The ttl value, the type, and the data must be included. The class is optional and defaults to IN.


Displays the current message, containing all of the prerequisites and updates specified since the last send command.


Sends the current message. This is equivalent to entering a blank line.



update delete www.nads.zn.
update add www.nads.zn. 60 CNAME ivy18.nads.zn



This example shows how to supply a file (NSUPD.TXT) to the nsupdate utility.


> update delete oldhost.example.com A
> update add newhost.example.com 86400 A


This example shows how the nsupdate utility is used interactively to insert and delete resource records from the example.com zone. Notice that the input contains an extra blank line so that a group of commands are sent as one dynamic update request to the master name server for example.com .

Any A records for oldhost.example.com are deleted, and an A record for newhost.example.com with IP address is added. The newly added record has a TTL value of 86400 seconds (one day).


> prereq nxdomain nickname.example.com
> update add nickname.example.com 86400 CNAME somehost.example.com

This example tells the BIND server to verify the prerequisite condition that no resource records of any type exist for nickname.example.com . If any records exist, the update request fails. If no records with that name exist, a CNAME is added for it.

This prerequisite condition is an RFC restriction that has been relaxed to allow for SIG, KEY, and NXT records to exist.

After entering data in interactive mode, press Return (or Enter) on a line with no data to complete the input. Alternatively, you can issue the SEND command. The nsupdate utility then processes all update entries in one operation.

6.11 Solving Bind Server Problems

To solve BIND server problems, see the following sections:

6.11.1 BIND Server Diagnostic Tools

The TCP/IP Services product provides the following utilities for diagnosing problems with the BIND server:

  • The dig utility
  • The host utility
  • The nslookup utility

The following sections describe these utilities.


The nslookup utility is no longer recommended. Use the dig utility instead.


Gathers information from the Domain Name System servers.


dig [@server] [-option] [name] [type] [class] [queryopt...]


dig is a flexible tool for interrogating DNS name servers. It performs DNS lookups and displays the answers that are returned from the name servers that were queried. Most DNS administrators use dig to troubleshoot DNS problems because of its flexibility, ease of use and clarity of output. Other lookup tools tend to have less functionality than dig .

Although dig normally is used with command-line arguments, it also has a batch mode of operation for reading lookup requests from a file. A brief summary of its command-line arguments and options is printed when the -h option is given. Unlike earlier versions of BIND, the BIND Version 9 implementation of dig allows multiple lookups to be issued from the command line.

Unless it is told to query a specific name server, dig tries each of the servers listed in your resolver configuration. When no command line arguments or options are given, dig performs an NS query for "." (the root).

dig has two modes: simple interactive mode, for a single query, and batch mode, which executes a query for each in a list of several query lines. All query options are accessible from the command line.

To get online help for the dig utility, enter the -h option on the command line. For example:

$ dig -h



Specifies the name or IP address of the name server to query. This can be either an IPv4 address in dotted-decimal notation or an IPv6 address in colon-delimited notation. When the supplied server argument is a host name, dig resolves that name before querying that name server. If no server argument is provided, dig consults your resolver configuration and queries the name servers listed there. The reply from the name server that responds is displayed.


Specifies the name of the resource record to look up.


Indicates the type of query required (ANY, A, MX, SIG, and so forth). If the type parameter is not supplied, dig performs a lookup for an A record.


Specifies the DNS query class. The default is class IN (Internet).


-b address

Sets the source IP address of the query to address. This must be a valid address on one of the host's network interfaces.

-c class

Specifies the query class. class is any valid class, such as HS for hesiod records or CH for CHAOSnet records. The default query class is IN (Internet).

-f filename

Makes dig operate in batch mode by reading a list of lookup requests to process from the specified file. The file contains a number of queries, one per line. Each entry in the file should be organized in the same way that dig queries are presented using the command-line interface.

-k filename

Allows you to sign the DNS queries sent by dig and their responses using transaction signatures (TSIG). Specify a TSIG key file for filename.

-p port

Allows you to specify a nonstandard port number. port is the port number that dig uses to send its queries instead of the standard DNS port number 53. You can use this option to test a name server that has been configured to listen for queries on a nonstandard port number.

-t type

Sets the query type to type, which can be any valid query type supported in BIND Version 9. The default query type is A, unless the -x option is supplied to indicate a reverse lookup. A zone transfer can be requested by specifying a type of AXFR. When an incremental zone transfer (IXFR) is required, type is set to ixfr=N . The incremental zone transfer contains the changes made to the zone since the serial number in the zone's SOA record was N.

-x addr

Specifies reverse lookups (mapping addresses to names). addr is either an IPv4 address in dotted-decimal notation or a colon-delimited IPv6 address. This option eliminates the need to provide the name, class, and type arguments. dig automatically performs a lookup for a name like and sets the query type and class to PTR and IN, respectively. By default, IPv6 addresses are looked up using the IP6.ARPA domain and binary labels as defined in RFC 2874. To use the older RFC 1886 method using the IP6.INT domain and nibble labels, specify the -n (nibble) option.

-y name:key

Allows you to specify the TSIG key itself on the command line. name is the name of the TSIG key and key is the actual key. The key is a base-64 encoded string, typically generated by dnssec_keygen . When using TSIG authentication with dig , the name server that is queried needs to know the key and algorithm that is being used. In BIND, this is done by providing appropriate key and server statements in TCPIP$BIND.CONF.

Query Options

Each query option is identified by a keyword preceded by a plus sign (+). Some keywords set or reset an option. These can be preceded by the string no to negate the meaning of that keyword. Other keywords (like that which sets the timeout interval) assign values to options. These types of keywords have the form +keyword=value .

Previous Next Contents Index