Compaq TCP/IP Services for OpenVMS
1.3 BIND Version 9
The Domain Name System (DNS) maintains and distributes information
about Internet hosts. DNS consists of a heirarchical databases
containing the names of entities on the Internet, the rules for
delegating authority over names, and mail routing information; and the
system implementation that maps the names to Internet addresses.
In OpenVMS environments, DNS is implemented by the Berkeley Internet
Name Domain (BIND) software. Compaq TCP/IP Services for OpenVMS
implements a BIND server based on the Internet Software Consortium's
(ISC) BIND Version 9 (BIND 9).
BIND 9 is supported on Alpha systems only, and future support of BIND
Version 8 (BIND 8) on VAX systems will be limited. Therefore, if you
are using BIND 8 on a VAX system, Compaq recommends that you
upgrade your BIND server to an Alpha system.
For information about managing BIND, refer to Appendix C.
1.3.1 BIND 9 Features
BIND 9 is a major rewrite of nearly all aspects of the underlying BIND
architecture. Some of the important features of BIND 9 are:
- DNS security
- DNSSEC (signed zones)
- TSIG (signed DNS requests)
- Access control lists
- Dynamic update security policies
- TKEY shared secrets
- SIG(0) transaction signatures
- Answers DNS queries on IPv6 sockets
- IPv6 resource records (A6, DNAME, and so forth)
- Bitstring labels
- DNS protocol enhancements
- IXFR, DDNS, Notify, EDNS0
- Improved standards conformance
One server process can provide multiple views of the DNS
name space (for example, an inside view to certain clients, and an
outside view to others).
- Multiprocessor support
The BIND resolver is based on the BIND 8 implementation of DNS.
To take advantage of the multiprocessor and multithreading support
provided with BIND 9, the OpenVMS SYSGEN parameter MULTITHREAD should
be nonzero on multiprocessor systems. Note that this parameter is
systemwide and affects other TCP/IP or OpenVMS components that use
1.3.2 BIND 8 to BIND 9 Migration
BIND 9 is designed to be compatible with BIND 8. The following list
summarizes the differences between them.
- Configuration file compatibility
- BIND 9 supports most but not all of the TCPIP$BIND.CONF options of
If your TCPIP$BIND.CONF file uses an unimplemented option,
the BIND 9 server logs a warning message. A message is also logged
about each option whose default has changed, unless the option is set
explicitly in TCPIP$BIND.CONF.
- The default of the
option has been changed from
. If you have slave servers running an old version of TCP/IP Services that
does not understand the
zone transfer format, you need to specify the following in either the
- In BIND 9, the BIND server will not start if it detects an error in
TCPIP$BIND.CONF. Earlier versions of BIND would start despite errors,
causing the server to run with a partial configuration. Errors detected
during subsequent reloads do not cause the server to exit.
in master files do not cause the server to exit, but they do prevent
the zone from being loaded.
- The set of logging categories in BIND 9 is different from that in
BIND 8. If you have customized your logging on a per-category basis,
you need to modify your
statement to use the new categories.
statement takes effect only after the entire TCPIP$BIND.CONF file has
been read. Therefore, when the server first starts up, any messages
about errors in the configuration file are always logged to the
TCPIP$BIND_RUN.LOG file, regardless of the contents of the
statement. In BIND 8, the new logging configuration took effect
immediately after the
statement was read.
- The source address and port for Notify messages and Refresh queries
is now controlled by the
options, respectively, rather than by the BIND 8
- Multiple classes must be put into explicit views for each class.
- Zone file compatibility
- BIND 9 complies strictly with the RFC 1035 and RFC 2308 rules
regarding omitted time-to-live (TTL) values in zone files. Omitted TTL
values are replaced by the value specified with the $TTL directive or,
if there is no $TTL directive, by the previously specified TTL value.
If there is no $TTL directive and the first resource record (RR) in
the file does not have an explicit TTL field, the zone file is illegal
because the TTL value of the first RR is undefined. BIND 4 and many
versions of BIND 8 accept such files without warning and use the value
of the SOA MINTTL field as a default for missing TTL values.
emulates the nonstandard BIND 4/8 SOA MINTTL behavior and loads the
file (provided the SOA is the first record in the file), but it also
issues the following warning message:
No TTL specified; using SOA MINTTL instead
To avoid problems, use a $TTL directive in each zone file.
- Some versions of BIND allow SOA serial numbers with an embedded
period (for example,
), and converts the numbers into integers. This feature is not
supported in BIND 9; serial numbers must be integers.
- TXT records with unbalanced quotes (for example,
'host TXT "foo'
) do not cause errors in some versions of BIND. In BIND 9, if your zone
files contain such records, potentially confusing error messages like
the following are generated:
This occurs because BIND 9 interprets everything up to the next
quote character as a literal string.
- Some versions of BIND accept RRs that contain line breaks that are
not properly quoted with parentheses, such as the following SOA:
@ IN SOA ns.example. hostmaster.example.
( 1 3600 1800 1814400 3600 )
This is not legal master file syntax; BIND 9 treats it as an error.
To correct the problem, move the opening parenthesis to the first line.
construct for specifying a literal dollar sign ($) in a domain name is
not recommended. Use the
- New protocol features
- If you want to accept DNS queries over IPv6, you must specify the
following in the TCPIP$BIND.CONF file:
This is not the default.
BIND 9 uses EDNS0 to advertise its receive buffer size.
It also sets an EDNS flag in queries to indicate it wants to receive
Most older servers that do not support EDNS0,
including prior versions of BIND, send an error in response to these
queries. When this happens, BIND 9 automatically retries the query
Certain non-BIND name server implementations may
silently ignore these queries, instead of sending an error response.
Name resolution is very slow, or fails, in zones where this type of
server is used.
When BIND 9 communicates with a server that
supports EDNS0, such as another BIND 9 server, responses of up to 4096
bytes may be transmitted as a single UDP datagram, which is subject to
fragmentation at the IP level. If a firewall incorrectly drops IP
fragments, it can cause name resolution to slow down dramatically or
- Outgoing zone transfers now use the
format by default. This format is not understood by old versions of
BIND 4. Use the following option to correct this problem:
To prevent security problems, upgrade the slave servers.
- Zone transfers to Windows 2000 DNS servers sometimes fail to
properly handle DNS messages that are larger than 16K. To correct this
problem, use the following option:
1.4 IMAP Server
The IMAP server for OpenVMS Mail and the Simple Mail Transfer Protocol
(SMTP) server work together to provide reliable mail management in a
IMAP is supported on Alpha systems only. Although images may appear on
VAX systems after installation, these are not supported.
The IMAP server allows users to access their OpenVMS Mail mailboxes
using client applications like Microsoft Outlook to view, move, copy,
and delete messages. The SMTP server also allows the clients to create
and send e-mail messages.
The IMAP server requires a certain level of the operating system. If
you are running one of the following versions of OpenVMS, you must
install the appropriate patch:
||Minimum Level Patch Kit
OpenVMS versions higher than Version 7.3 automatically support the IMAP
server without requiring any patches.
For more information about managing and using the IMAP server, refer to
1.5 Kerberos Enhancements to the TELNET Client and Server
Kerberos is freely available from the Massachusetts Institute of
Technology (MIT), under a copyright permission notice. Kerberos for
OpenVMS is supplied by Compaq Computer Corporation under the terms of
the license from MIT. For more information about the Kerberos license,
see the following web site:
Kerberos is a network authentication protocol designed to provide
strong authentication for client/server applications by using
secret-key cryptography. Kerberos uses strong cryptography so that a
client can prove its identity to a server (and vice versa) across an
insecure network connection. The TCP/IP TELNET service uses Kerberos to
make sure the identity of any user who requests access to a remote host
Compaq TCP/IP Services for OpenVMS Version 5.3 supports the OpenVMS
Kerberos Version 1.0 client, which is based on MIT Kerberos Version 5.
Before you can use the Kerberos TELNET client, the OpenVMS Security
Client software must be configured on the OpenVMS system. For more
information about installing and configuring the OpenVMS Security
Client software, see the Kerberos Version 1.0 for OpenVMS Security
Client Installation Guide and Release Notes.
The Kerberos Security Client kit contains copies of the MIT
documentation listed in the Kerberos Version 1.0 for OpenVMS
Security Client Installation Guide and Release Notes.
It is assumed that anyone using the Kerberos security features in
TCP/IP has expert knowledge of Kerberos.
Encryption is not supported in this version of TCP/IP Services.
1.5.1 Kerberos Principal Names
Before you use the Kerberos TELNET client, make sure the local host
name is fully qualified in the local hosts database. Kerberos realms
form principal names using fully-qualified domain names. For example,
is a fully qualified domain name;
is a simple host name.
Compaq TCP/IP Services for OpenVMS is usually configured so that the host name is entered in
the hosts database as a simple host name. That is, on host TERSE, the
TCP/IP management command SHOW HOST TERSE returns
To correct a mismatch between the Kerberos realm and the TCP/IP Services
configurations, follow these steps from a privileged account at a time
when system usage is low:
- Find the host's numeric address. For example:
TCPIP> SHOW HOST terse
Host address Host name
- Remove the simple host name. For example:
TCPIP> SET NOHOST terse/CONFIRM
- Use the SET HOST command to associate the fully qualified domain
name with the IP address, as shown in the following example:
TCPIP> SET host "terse.mbs.com"/ADDRESS=15.28.311.11 -
_TCPIP> /ALIAS=("TERSE.MBS.COM", "terse", "TERSE")
Specify the /ALIAS qualifier to ensure that applications can handle
host names in uppercase and lowercase.
- Confirm that the first name returned is fully qualified.
TCPIP> SHOW HOST terse
Host address Host name
15.28.311.11 terse.mbs.com, TERSE.MBS.COM, terse, TERSE
1.5.2 Using the Kerberos TELNET Client
The following sections describe how to use the TELNET client to
establish authenticated connections.
18.104.22.168 Initiating an Authenticated TELNET Connection
To initiate an authenticated connection, perform the following steps:
- On a Kerberos-enabled system, enter a KINIT username
command. Enter your password when prompted.
Always specify the user name on the KINIT command line. Kerberos realms
are usually set up with lowercase user names, but on OpenVMS, user
names are stored in uppercase. When you specify the user name, it will
be accepted as lowercase.
- To initiate an authenticated connection, enter the following
$ TELNET/AUTHENTICATE host-name
- To use the same ticket on a remote system, you can forward your
ticket by entering the following command:
$ TELNET/AUTHENTICATE/FORWARD host-name
- To use your credentials in another realm, enter the following