The AAAA record is a parallel to the IPv4 A record. It specifies the entire address in a single record. For example:

$ORIGIN example.com. host 3600 IN AAAA 3ffe:8050:201:1860:42::1

6.5.4.2 Address-to-Name Lookups Using Nibble Format

As in IPv4, when looking up an address in nibble format, the address components are simply reversed and ip6.arpa. is appended to the resulting name. For example, the following provides reverse name lookup for a host with address 3ffe:8050:201:1860:42::1:

$ORIGIN 0.6.8.1.1.0.2.0.0.5.0.8.e.f.f.3.ip6.arpa. 1.0.0.0.0.0.0.0.0.0.0.0.2.4.0.0 14400 IN PTR host.example.com.

6.5.5 DNS Notify

DNS Notify allows master name servers to notify their slave servers of changes to a zone's data. In response to a NOTIFY message from a master server, the slave checks to see whether its version of the zone is the current version. If it is not, the slave initiates a transfer. For more information, see the description of the notify option in Table 6-7.

6.5.6 Incremental Zone Transfers (IXFR)

The incremental zone transfer (IXFR) protocol is a way for slave servers to transfer only changed data instead of having to transfer the entire zone. The IXFR protocol is documented in RFC 1995.

When acting as a master, BIND Version 9 supports IXFR for those zones in which the necessary change history information is available. These include master zones maintained by dynamic update and slave zones whose data was obtained by IXFR, but not manually maintained master zones and slave zones obtained by performing a full zone transfer (AXFR). When acting as a slave, BIND attempts to use IXFR unless it is explicitly disabled. For more information about disabling IXFR, see the description of the request-ixfr clause of the server statement in Section 6.5.3.7.

6.5.7 Dynamic Updates

With dynamic updates, the BIND server can add, modify, or delete records or RRsets in the master zone files.

Dynamic updating is enabled on a zone-by-zone basis by including an allow-update or update-policy clause in the zone statement. Dynamic updating is described in RFC 2136.

Updating of secure zones (zones using DNSSEC) is presented in RFC 3007. SIG and NXT records affected by updates are automatically regenerated by the server using an online zone key. Update authorization is based on transaction signatures and on an explicit server policy.

6.5.7.1 The Journal File

All changes made to a zone using dynamic update are stored in the zone's journal file. This file is automatically created by the server when the first dynamic update takes place. The name of the journal file is formed by appending _JNL to the name of the corresponding zone file. The journal file is in a binary format and should not be edited manually.

The server also occasionally writes (or "dumps") the complete contents of the updated zone to its zone file. This is not done immediately after each dynamic update; that would be too slow when a large zone is updated frequently. Instead, the dump is delayed by 15 minutes, allowing additional updates to take place.

When a server is restarted after a shutdown or failure, it replays the journal file to incorporate into the zone any updates that took place after the last zone dump. Changes that result from incoming incremental zone transfers are journaled in a similar way.

The zone files of dynamic zones should not be edited because they are not guaranteed to contain the most recent dynamic changes---those are only in the journal file.

If you have to make changes to a dynamic zone manually, use the following procedure:

1. Flush any dynamic updates in _JNL files to the master zone files using the following command:

   $ rndc flush-updates

2. Shut down the server using the following command:

   $ @SYS$STARTUP:TCPIP$BIND_SHUTDOWN.COM

3. Remove the zone's _JNL file.
4. Edit the zone file.
5. Restart the server using the following command:

   $ @SYS$STARTUP:TCPIP$BIND_STARTUP.COM

Removing the _JNL file is necessary because the manual edits are not present in the journal, rendering it inconsistent with the contents of the zone file.

6.5.7.2 Dynamic Update Policies

BIND Version 9 supports two methods of granting clients the right to perform dynamic updates to a zone. You can configure them using either the allow-update option or the update-policy option.

The allow-update clause works the same way as in previous versions of BIND. It grants given clients the permission to update any record of any name in the zone.

The update-policy clause is new in BIND 9 and allows more fine-grained control over what updates are allowed. A set of rules is specified, where each rule either grants or denies permissions for one or more names to be updated by one or more identities. The rules apply to master zones only.

The update-policy statement only examines the signer of a message; the source address is not relevant. If the dynamic update request message is signed (that is, it includes either a TSIG or SIG(0) record), the identity of the signer can be determined.

If an allow-update statement appears when the update-policy statement is present, a configuration error occurs.

Use the following format to define rules:

( grant | deny ) identity nametype name [ types ]

Each rule grants or denies privileges. Once a message has successfully matched a rule, the operation is immediately granted or denied and no further rules are examined. A rule is matched when the signer matches the identity field, the name matches the name field, and the type is specified in the type field. The rule definition includes the following fields:

• grant or deny specifies whether to grant or deny privileges.
• identity specifies the signer of the message. Use a name or a wildcard in the identity field.
• name specifies the name to be updated.
• nametype specifies one of the following:
  • name, which matches when the updated name is the same as the name in the name field.
  • subdomain , which matches when the updated name is a subdomain of the name in the name field (including the name itself).
  • wildcard , which matches an updated name that is a valid expansion of the wildcard name in the name field.
  • self , which matches when the updated name is the same as the message signer. The name field is ignored.
• types specifies the types of resource records.
  If no types are specified, the rule matches all types except SIG, NS, SOA, and NXT. Types can be specified by name, including ANY. ANY matches all types except NXT, which can never be updated.

If the name server for the domain is configured to accept dynamic updates, you can manually create updates to the domain database file using the nsupdate utility.

You start the utility using the NSUPDATE command, which is defined when you run the TCPIP$DEFINE_COMMANDS.COM procedure.

You can enter commands to the nsupdate utility interactively, or you can specify a file that contains nsupdate commands.

Transaction signatures can be used to authenticate update requests, as described in Section 6.2.3. Signatures rely on a shared secret that should be known to only the nsupdate utility and the name server. TSIG uses the HMAC-MD5 encryption algorithm. It is important to specify the encryption algorithm because additional algorithms will be made available in the future. Use the appropriate configuration options in the server and key statements in TCPIP$BIND.CONF to ensure the name server associates the secret key and algorithm with the IP address of the client application that uses TSIG authentication. The nsupdate utility does not read the TCPIP$BIND.CONF file.

6.5.8 Configuring Cluster Failover and Redundancy

In the same OpenVMS Cluster, multiple BIND master servers can share a common database, thereby providing redundancy and a failover mechanism when one of the servers becomes unavailable.

To configure a DNS cluster failover and redundancy environment, perform the following steps on each node that acts as a BIND master server.

1. Run the TCPIP$CONFIG command procedure, and from the Servers menu enable the BIND service.
2. Edit the BIND configuration file, SYS$SPECIFIC:[TCPIP$BIND]TCPIP$BIND.CONF.
   1. Configure the node as a master server.
   2. Add or edit the options statement. The directory substatement should be as follows:

      options { directory "TCPIP$BIND_COMMON"; };

      
      TCPIP$BIND_COMMON is a logical name defined in the TCPIP$BIND_COMMON_STARTUP.COM command procedure as a search list. The search list consists of the SYS$SPECIFIC:[TCPIP$BIND] directory and the common directory. In the next step, the setup command procedure prompts you to specify the device on which the common directory is to reside. If you do not specify a device, the default device and directory is common_device:[TCPIP$BIND_COMMON], where common_device is generated automatically in the following manner:

      • If the SYSUAF logical is defined, the common disk is determined from its definition.
      • If the SYSUAF logical is not defined, the system uses SYS$SYSDEVICE as the default device.
3. Run the SYS$MANAGER:TCPIP$BIND_CLUSTER_SETUP.COM command procedure.
   This procedure creates two other command procedures that manage the startup and shutdown processes of the BIND component in a cluster environment:
   • SYS$MANAGER:TCPIP$BIND_COMMON_STARTUP.COM
   • SYS$MANAGER:TCPIP$BIND_COMMON_SHUTDOWN.COM
   
   These files define the BIND system logicals and accounting information. To remove the failover setup from your system, first shut down the BIND server by using the TCPIP$BIND_COMMON_SHUTDOWN.COM command procedure, then delete these two files.
4. Place any database files to be shared in the common directory.

   Note Be careful to remove from SYS$SPECIFIC:[BIND] any databases that are to be shared. Using the search list logical, BIND will find any SYS$SPECIFIC:[BIND] databases first and use those. This might not be the result you want.

5. Start up BIND by entering the following command:

   $ @SYS$MANAGER:TCPIP$BIND_STARTUP.COM

If multiple master BIND servers are running in a cluster, and a change is made to the common BIND database, the database must be reloaded on each node that is running the master BIND server. To reload the BIND database on every node in the cluster where the master BIND server is running, enter the following command:

TCPIP> SET NAME_SERVICE /INITIALIZE /CLUSTER=dev:[directory]

The /CLUSTER qualifier takes the directory specification of the common BIND directory as a value. If you omit the device and directory, they default to:

common_device:[TCPIP$BIND_COMMON]

In this case, common_device is generated automatically in the following manner:

• If the SYSUAF logical is defined, the the common disk is determined from its definition.
• If SYSUAF logical is not defined, the system uses SYS$SYSDEVICE as the default device.

To populate the BIND server database files, use one of the following methods:

• Convert an existing host database with the CONVERT/UNIX BIND command.
• Manually edit the ZONE.DB files.

To populate the BIND server database by copying information from the local hosts database and other database files, enter the CONVERT/UNIX BIND command. This command:

• Creates a BIND server database (if needed).
• Extracts data from the local hosts database. (The BIND server uses UNIX style formatted files.)
• Extracts Mail Exchange (MX) information from the routes database.
• Populates the BIND server database with the host and MX records.
• Creates a forward translation file with the following characteristics:
  • It has address, canonical name, and MX entries.
  • If a file with the same name as the output file already exists, the serial number from that file's start-of-authority (SOA) entry increments and becomes the serial number of the new output file.
  • If no previous version of the output file exists, the serial number for the new file is 1.
  
  When you specify forward translation (by omitting the /DOMAIN qualifier), any host in the local hosts database that is not qualified with a domain is included in the target domain. For example, if the local domain is x.y.z. , the CONVERT/UNIX BIND command includes: a , b.x.y.z , c.x.y.z.z but does not include d.x.y.h .
• Creates a reverse translation file if you specify /DOMAIN=(domain.name) and the end of domain.name is IN-ADDR.ARPA.
  The created reverse translation file has the following characteristics:
  • Only records applicable to the domain you specify are placed into the output file.
  • The output file has domain name pointer entries.
  • If a file with the same name as the output file already exists, the serial number from that file's SOA entry increments and becomes the serial number of the new output file.
  • If no previous version of the output file exists, the serial number for the new file is 1.
  • The file selects hosts with IP addresses that match the partial IP address from domain.name. For example, /DOMAIN=16.99.IN-ADDR.ARPA does a reverse translation and selects hosts whose addresses begin with 99.16.

If the BIND server's directory is SYS$SPECIFIC:[TCPIP$BIND] and you have specified domain abc.def.com , the default output file is named SYS$SPECIFIC:[TCPIP$BIND]ABC_DEF_COM.DB.

HP suggests that you do not change the default directory name. If you do, the file is created in your current directory.

On the command line, specify the full OpenVMS file specification. Do not specify a version number, and do not use wildcards. The following example uses the domain ucx.ern.sea.com , creates a UCX_ERN_SEA_COM.DB file, creates a 208_20_9_IN-ADDR_ARPA.DB file, and checks the results by displaying directory listings with the new file.

TCPIP> CONVERT/UNIX BIND /DOMAIN=UCX.ERN.SEA.COM TCPIP> CONVERT/UNIX BIND /DOMAIN=208.20.9.IN-ADDR.ARPA TCPIP> SET DEFAULT SYS$SPECIFIC:[TCPIP$BIND] $ DIRECTORY Directory SYS$SPECIFIC:[TCPIP$BIND] 127_0_0.DB;1 208_20_9_IN-ADDR_ARPA.DB;1 LOCALHOST.DB;1 LOGIN.COM;1 ROOT.HINT;1 TCPIP$BIND.CONF;1 TCPIP$BIND_CONF.TEMPLATE;1 TCPIP$BIND_RUN.LOG;4339 TCPIP$BIND_SERVER.PID;1 UCX_ERN_SEA_COM.DB;5

6.6.2 Manually Editing Zone Files

All name server zone files use the same type of records to define domain database information. HP recommends that you review these resource records before you edit any BIND files. Table 6-21 describes the standard resource records (RRs).

Table 6-21 Standard Resource Record Types

Record Type	Description
A	A host address.
A6	An IPv6 address.
AAAA	An IPv6 address.
CERT	A digital certificate.
CNAME	The canonical name of an alias.
DNAME	Delegation of reverse addresses. Replaces the domain name specified with another name to be looked up. (Described in RFC 2672.)
GPOS	The global position. Superseded by LOC.
HINFO	The host's CPU and operating system.
KEY	A public key associated with a DNS name.
KX	A key exchanger for this DNS name.
MX	A mail exchange for the domain.
NAPTR	A name authority pointer.
NSAP	A network service access point.
NS	The authoritative name server for the domain.
NXT	Used in DNSSEC to securely indicate that RRs with an owner name in a certain name interval do not exist in a zone and to indicate what RR types are present for an existing name. For more information, see RFC 2535.
PTR	A pointer to another part of the domain name space.
SIG	A signature. Contains data authenticated in the secure DNS. For more information, see RFC 2535.
SOA	The start of an authority zone.
SRV	Information about well-known network services. Replaces WKS.
TXT	Text records.
WKS	Information about the well-known network services, such as SMTP, that a domain supports. Replaced by WKS.
X25	Representation of X.25 network addresses. Experimental.

The format of DNS records is as follows:

[name] [ttl] IN type data

In this format:

name	Specifies the name of the domain object referenced by a resource record. The string entered for name is the current domain unless it ends with a dot. If the name field is blank, the record applies to the domain object last named.
ttl	Defines the length of time, in seconds, that the information in this resource record should be kept in cache. Usually, the time-to-live field is left blank, and the default ttl, set for the entire zone SOA record, is used.
IN	Identifies the record as an Internet DNS resource record.
type	Identifies what kind of resource record this is. (See Table 6-21 for the record types you can specify.)
data	Information specific to this type of resource record. For example, in an A record, this is the field that contains the actual IP address.

6.6.2.1 Setting TTLs

The time to live (TTL) of the RR field is a 32-bit integer that represents the number of seconds that an RR can be cached before it should be discarded. The following types of TTL values are used in a zone file:

• SOA
  The last field in the SOA is the negative caching TTL. This controls how long other servers cache no-such-domain (NXDOMAIN) responses from you.
  The maximum time for negative caching is 3 hours (3h).
• $TTL
  The $TTL directive at the top of the zone file (before the SOA) gives a default TTL for every RR without a specific TTL set.
• RR TTLs
  Each RR can have a TTL as the second field in the RR, which controls how long other servers can cache it.

All of these TTLs default to units of seconds, though units can be explicitly specified (for example, 1h30m for 1 hour and 30 minutes).