HP OpenVMS Systems Documentation

Compaq TCP/IP Services for OpenVMS
Release Notes

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).

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
• IPv6
  • 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
• Views
  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
• Multithreading

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 POSIX threads.

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 BIND 8.
    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 transfer-format option has been changed from one-answer to many-answers . If you have slave servers running an old version of TCP/IP Services that does not understand the many-answers zone transfer format, you need to specify the following in either the options or server statement:

    transfer-format one-answer;

  • 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.
    Errors 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 logging statement to use the new categories.
    The logging 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 logging statement. In BIND 8, the new logging configuration took effect immediately after the logging statement was read.
  • The source address and port for Notify messages and Refresh queries is now controlled by the notify-source and transfer-source options, respectively, rather than by the BIND 8 query-source option.
  • 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.
    BIND 9 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, 3.002 ), 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:

    Unexpected end of file

    
    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.
  • The $$ construct for specifying a literal dollar sign ($) in a domain name is not recommended. Use the \$ construct instead.
• New protocol features
  • If you want to accept DNS queries over IPv6, you must specify the following in the TCPIP$BIND.CONF file:

    listen-on-v6 {any; };

    
    This is not the default.
  • EDNS0
    BIND 9 uses EDNS0 to advertise its receive buffer size. It also sets an EDNS flag in queries to indicate it wants to receive DNSSEC responses.
    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 without EDNS0.
    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 fail.
  • Outgoing zone transfers now use the many-answers format by default. This format is not understood by old versions of BIND 4. Use the following option to correct this problem:

    transfer-format one-answer;

    
    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 client/server environment.

    Note 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:

    OpenVMS Version	Minimum Level Patch Kit
    Alpha V7.2-1	VMS721_MAIL-V0100
    Alpha V7.2-1H1	VMS21H1_MAIL-V0100
    	VMS21H1_MAIL-V0200
    Alpha V7.2-2	VMS722_MAIL-V0100
    Alpha V7.3	VMS73_MAIL-V0100

    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 Appendix A.

    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:

    http://web.mit.edu/kerberos/www/.

    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 is authentic.

    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.

    Note 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, terse.mbs.com is a fully qualified domain name; terse 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 terse , not terse.mbs.com .

    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:

    1. Find the host's numeric address. For example:

       $ TCPIP TCPIP> SHOW HOST terse LOCAL database Host address Host name 15.28.311.11 terse

    2. Remove the simple host name. For example:

       TCPIP> SET NOHOST terse/CONFIRM

    3. 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.
    4. Confirm that the first name returned is fully qualified.

       TCPIP> SHOW HOST terse LOCAL database 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.

    1.5.2.1 Initiating an Authenticated TELNET Connection

    To initiate an authenticated connection, perform the following steps:

    1. On a Kerberos-enabled system, enter a KINIT username command. Enter your password when prompted.

       Note 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.

    2. To initiate an authenticated connection, enter the following command:

       $ TELNET/AUTHENTICATE host-name

    3. To use the same ticket on a remote system, you can forward your ticket by entering the following command:

       $ TELNET/AUTHENTICATE/FORWARD host-name

    4. To use your credentials in another realm, enter the following command:

       $ TELNET/AUTHENTICATE/REALM=realm-name.

    ---

    Previous

    Next

    Contents