| Previous | Contents | Index |
example_com.db_signed |
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.
Note
For the BIND server to recognize a newly generated RNDC.KEY file, you must stop and restart the BIND server.
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:
$ rndc_confgen |
reload
Reloads configuration file and zones.reload zone [class [view]]
Reload the given zone.refresh zone [class [view]]
Schedule zone maintenance for the given zone.reconfig
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.stats
Writes server statistics to the statistics file, TCPIP$BIND.STATS.querylog
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.dumpdb
Dumps the server's caches to the dump file, TCPIP$BIND_DUMP.DB.trace
Increments the servers debugging level by one.trace level
Sets the server's debugging level to an explicit value.notrace
Sets the server's debugging level to 0.flush
Flushes the server's cache.flush-updates
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.)status
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."-V"
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.
-a
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.
Note
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.-h
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 127.0.0.1.
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 rdataIn 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.
-d
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:
Kname.157-random_PRIVATEFor historical reasons, the file Kname.157-random_KEY must also be present.
-v
Specifies that nsupdate use the TCP protocol instead of the UDP protocol. By default, nsupdate sends update requests using UDP.file-name
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.show
Displays the current message, containing all of the prerequisites and updates specified since the last send command.send
Sends the current message. This is equivalent to entering a blank line.
| #1 |
|---|
$ TYPE NSUPD.TXT
update delete www.nads.zn.
update add www.nads.zn. 60 CNAME ivy18.nads.zn
$ NSUPDATE NSUPD.TXT
|
This example shows how to supply a file (NSUPD.TXT) to the nsupdate utility.
| #2 |
|---|
$ NSUPDATE
> update delete oldhost.example.com A
> update add newhost.example.com 86400 A 172.16.1.1
>
|
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 172.16.1.1 is added. The newly added record has a TTL value of 86400 seconds (one day).
| #3 |
|---|
$ NSUPDATE
> 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:
The TCP/IP Services product provides the following utilities for diagnosing problems with the BIND server:
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
@server
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.name
Specifies the name of the resource record to look up.type
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.class
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 11.12.13.10.in-addr.arpa 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.
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