DIGITAL TCP/IP Services for OpenVMS
Concepts and Planning

The reception of RIP response packets on a network is used to determine whether that network and interface are functioning correctly. If no RIP response packet is received on an interface, another path may be chosen to route around the interface or the route may be dropped if no alternative is available.

2.5.3 Fragmentation

Fragmentation breaks a large datagram into segments. The IP protocol fragments a datagram when the datagram originates in a network that allows large packets, but to reach its destination, the packet must cross a network that supports a limited packet size. Fragmentation is also used when there is no gateway, but applications send messages that are longer than the Network Interface layer supports. For example, the NFS server transfers information in 8000-byte packets, but Ethernet only supports 1518-byte packets. Therefore, IP fragments the 8000-byte datagram into 6 segments of no more than 1518 bytes each.

A gateway can break up an internet datagram into smaller internet datagram fragments. The fragments can be further broken into smaller fragments at subsequent gateways.

The fragment format is designed so that the destination IP layer can reassemble fragments into their original form before delivering the complete datagram to a user.

2.6 Ports

As explained in Section 2.4, each host on an internet is identified by a unique IP address. However, because numerous processes run concurrently, a client process on a local host needs more than just the remote host's IP address to connect to a server process on the remote host.

In addition to the IP address, the client process must specify the port number of the server process to which it wants to connect. The combination of an IP address and a specific port number identifies the unique connection point of the requested process. Port numbers range from 1 to 65535.

Every client and server process has an associated port number. The UDP header and TCP header each contain the source port number and the destination port number. Because the IP header specifies the protocol, TCP ports are independent of the UDP ports. TCP port 1035, for example, is different from UDP port 1035.

There are numerous advantages to using ports instead of attempting to send messages directly to receiving processes with process names or identification numbers:

• Heterogeneous operating systems define processes differently. To use process names requires that the internet architecture include a definition of each process or process name.
• Not all senders have enough information to identify a particular process on another host.
• Process IDs change.

By convention, port numbers 1 to 255 are called well known ports and are assigned to specific applications on all servers running TCP/IP. For example, some of the most common well known port numbers are:

Port Number	Application
21	FTP (File Transfer Protocol)
23	TELNET
25	SMTP (Simple Mail Transfer Protocol)
69	TFTP (Trivial File Transfer Protocol)
110	POP (Post Office Protocol)

2.6.2 Privileged Ports

In addition to well known ports (1 to 255), port numbers 256 to 1023 are called privileged ports. This meaning of privilege depends on the operating system. In general, when a host receives a message from a privileged port on a remote sender, the local host assumes that the remote host has checked the security or authenticated the application using the port. The remote host is responsible for ensuring that only privileged applications or users can access privileged ports.

Note

Under OpenVMS, a process needs one of the following privileges to bind to the local privileged ports (1 to 1023):

• A system UIC
• SYSPRV
• OPER
• BYPASS

Before requesting a process from a server, a client process is assigned an unused port number (usually ports 1024 to 5000) from its local host. This temporary port number is contained in the header information along with the IP address.

After the server completes the request, it can reply to the client using the port and IP address information contained in the requesting header.

Because the port number assigned to the client process is temporary, it is called an ephemeral port number. When the first client process is finished, the port number is assigned to another process.

2.6.4 Port Binding

To communicate through either TCP or UDP, a process must be bound to a port. This means that the sending and receiving processes establish a connection and exchange command requests. A port that is bound to a process is known as an active port. A process can bind to any number of ports.

2.6.5 Port Assignment

Ports can be permanently associated with specific servers provided by specific image files. An association between a port and an image file is called a port assignment. To create a port assignment, the system manager or a process assigns the port to a server. The server must have an entry in the DIGITAL TCP/IP Services for OpenVMS service database (UCX$SERVICE.DAT).

The server's entry in the UCX service database contains the following information:

• Server file name
• Protocol used by the server (TCP or UDP)
• Port number
• Startup information
• Logging information
• Access information

For more information, see to the SET SERVICE command in the DIGITAL TCP/IP Services for OpenVMS Management Command Reference manual.

2.7 Sockets

As explained in Section 2.6, the unique connection point of a process is identified by the IP address and port number. This point is called a socket. Because network communication consists of two connection points (source and destination), a socket pair fully describes the connection:

{source_IP_address, source_port, destination_IP_address, destination_port} 

For example, the following is a valid socket pair:

{192.43.235.2, 1500, 192.43.235.6, 21} 

where 192.43.235.2 is the source IP address and 1500 is the source port number and 192.43.235.6 is the destination IP address and 21 is the destination port number. (It's also interesting to note that 1500 is an ephemeral port number and 21 is the well know port number for FTP.)

2.7.1 Socket Communication APIs

The concept of a socket is important to creating networked applications. The socket communication API consists of calls that programmers use to write application programs that transfer data between two hosts. Each application generally needs to contain both client and server functionality.

The following is a typical sequence of socket calls a client process could use to access a server:

• Create a socket with a call to socket().
• Connect the socket to the server with a call to connect().
• Send and receive data with calls to send() and recv().
• Shut down the connection with a call to shutdown() and close().

A server process needs to prepare itself before it can accept clients. To do this, it might use a sequence of calls such as the following:

• Create a socket with a call to socket().
• Register the socket with a well known port address with a call to bind().
• Create a queue where clients can place connection requests with a call to listen().
• Accept client request with a call to accept().

For more detailed information about socket calls, see the DIGITAL TCP/IP Services for OpenVMS System Services and C Socket Programming manual.

2.7.2 UCX Socket APIs

The DIGITAL TCP/IP Services for OpenVMS product supports two socket communication APIs:

• OpenVMS system services
• C socket interface

In both of these APIs, three characteristics must be specified to create a socket:

• Address family
• Protocol type
• Protocol

An address family is the set of collective common properties of processes that communicate through sockets. The DIGITAL TCP/IP Services for OpenVMS product supports the Internet (AF_INET) address family.

2.7.2.2 Socket Type

Socket types are the communication properties visible to the user. Normally, processes communicate only between sockets of the same type. The available socket types are: stream, datagram, and raw.

• A stream socket (TCP) supports a bidirectional, reliable, and sequenced flow of data without duplication or record boundaries. The data is guaranteed to arrive at the receiving processes in sequence, without duplication.
• A datagram socket (UDP) provides a bidirectional flow of data that does not guarantee the receiving process gets the messages in sequence, without duplication, or at all. The record boundaries of the data are preserved.
• A raw socket (IP) provides access to the underlying communication protocols that support sockets. Users developing new communication protocols, for example, can take advantage of raw sockets to provide direct access to the IP protocol.

In most cases, the socket protocol properties are either TCP or UDP. TCP is used for connection-oriented sockets and is more complex than the lower-overhead connectionless sockets of UDP.

See the DIGITAL TCP/IP Services for OpenVMS System Services and C Socket Programming manual for detailed information.

The DIGITAL TCP/IP Services for OpenVMS (UCX) software supports the Berkeley Internet Name Domain (BIND) service, which is a UNIX-style implementation of the Domain Name Service (DNS). Before you add BIND servers to your network, it is useful to understand basic BIND service concepts. This chapter describes:

• Overview of the BIND Service (Section 3.1)
• BIND Service Components (Section 3.2)
• Domains (Section 3.3)
• Domain Names (Section 3.4)
• Zones (Section 3.5)
• Reverse Translation Domain (Section 3.6)
• BIND Server Functions (Section 3.7)
• BIND Server Files (Section 3.8)
• BIND Clients (Section 3.9)

The BIND service is a directory lookup service used by an internet to map names to IP addresses and to provide name-to-address translations in response to queries. DNS includes a hierarchical, distributed namespace.

The BIND service is based on a client/server model. Name servers maintain databases of host names, addresses, mail records, text records, and other network objects. When client systems require this information, they query the servers.

Note

DIGITAL's UCX BIND server also responds to Hesiod queries from remote hosts.

The Internet Network Information Center (InterNIC) provides the Internet community with services for domain registration, directories and databases, and other information. See Appendix A for information about network and domain registration.

3.2 BIND Service Components

• BIND resolver --- the software interface that exchanges query packets with the BIND server. The BIND resolver can query BIND servers that implement the BIND Request for Comments (RFC) documents.
• BIND server --- a name service that provides network objects used by other hosts. The BIND server on a UCX host is the DNS server in the TCP/IP network. The BIND server allows an application to retrieve user-defined associations between a name, a particular type of service, and information about that service. For example, the BIND server distributes information about network services, hosts, and users.

The Internet name space is based on a hierarchical tree structure. Each node on the tree is referred to as a domain or a subdomain. A domain is an administrative entity that allows for decentralized management of host names, addresses, and user information. Domains can refer to an administrative point on the name space tree or a specific host. A domain is identified by a domain name and includes the name space at or below the domain name.

A subdomain is a domain that is part of a larger domain. You can consider every domain in the name space below the root domain to be a subdomain. You can also refer to any subdomain as a domain.

Figure 3-1 illustrates a typical Internet domain hierarchy.

Figure 3-1 Internet Domain Hierarchy

Countries can register with the InterNIC as top-level domains provided they name themselves after a two-letter country code listed in the international standard ISO-3166. If a country code is identical to a state code that the U.S. Postal Service uses, the country can request a three-letter code.

Table 3-1 lists some of the commonly used top-level domains.

Table 3-1 Top-Level Domains

Domain	Description
arpa	The Arpanet (gradually being phased out)
ca	Canada
com	Commercial institutions
edu	Educational institutions
gov	Government departments or agencies
mil	Military organizations
net	Network-type organizations, such as network service centers, consortia, and information centers
org	Miscellaneous organizations, such as professional societies and similar nonprofit organizations
us	United States

3.3.2 Domain Administrator Role

Typically, each domain has a domain administrator responsible for coordinating and managing the domain. The domain administrator registers a second-level or lower domain by interacting with the domain administrator in the next higher level domain.

The domain administrator's duties include:

• Understanding the concepts and procedures of the BIND service
• Ensuring reliable service
• Ensuring that the BIND data is current
• Taking prompt action when necessary, for example, if protocols are violated or other serious misbehavior occurs
• Controlling the assignments of the host and domain names

The domain administrator furnishes users with access to names and name-related information both inside and outside the local domain.

3.4 Domain Names

The InterNIC assigns names for all top-level domains as well as domains directly below the top-level domains. Individuals are responsible for assigning lower-level domains and host names.

Each domain (or subdomain) has a label. For example, the label for the top-level domain for commercial organizations is com. A label is unique within its parent domain.

The concatenation of all the domain labels from the top-level domain to the lowest-level domains listed from right to left and separated by dots is called the domain name. For example, the domain name for a subdomain within the com domain, would be abc.com; abc is the label for the ABC company's subdomain, and com is the label for the commercial domain. This structure allows administration and data maintenance to be delegated down the hierarchical tree.

Notes

The term domain name is sometimes used when referring to a specific domain label.

The name of the root domain of the name space is a dot (.) .

There are two types of domain names: the fully qualified name and the relative name.

• The fully qualified name represents the complete domain name. This is also known as the absolute or canonical name. For example:

  chicago.cities.dec.com 
  

  
  A domain name that is fully qualified is absolute. You should not append further BIND extensions to the name.
• The relative name represents the starting name (label) of an absolute domain name. Relative names are incomplete, but are completed by the BIND service, using knowledge of the local domain. Relative host names such as chicago.cities are automatically expanded to the fully qualified domain name when given in a typical command.

Hosts and resources often have more than one name that identifies them. The BIND service supports the use of canonical names and aliases. A canonical name is a host's or resource's "official" name, while other names that identify the same host or resource are considered aliases or nicknames. Nicknames are useful if a host changes its canonical name. People who continue to use the nickname can still reach the right host or resource.

3.4.3 Domain Name Format

Domain and host labels have the following format:

• Any character
• A maximum of 63 characters for each label
• A maximum of 255 characters in a fully qualified domain name

In addition, you can use the following characters:

• Double quotes (" ") to indicate characters that would otherwise be special (for example, space or tab characters, but not quotes or new line characters)
• Backslash (\) to indicate any special character, including quotes and new lines
• Double backslashes (\\) to place a backslash in a name

Note

Characters in the range of 128 through 255 are subject to having their high bit cleared because some software does not preserve the high bit.

Although label names can contain up to 63 characters, it is best to choose names that are 12 characters or less because the canonical (fully qualified) domain names are easier to keep track of if they are short. The sum of all the label characters and label lengths is limited to 255.

Note

Domain names are not case sensitive. However, the case of entered names is preserved whenever possible.

Read from right to left for the following fully qualified domain name:
euro.sales.widget.com.

• The com label refers to the commercial top-level domain.
• The widget label refers to the widget domain, a subdomain of the commercial domain.
• The sales label refers to the sales domain, a subdomain of the widget domain.
• The euro label refers to the host called euro, a subdomain of the sales domain.

In addition to domains, the entire internet name space is divided into several zones. Each zone starts at a domain and extends down to the leaf domains (individual host names), or to domains where other zones start. A zone is a subdivision of a domain and is a discrete, non-overlapping entity. A zone usually represents an administrative boundary.

A common zone is a second-level domain abc.com, for example. Many second-level domains divide their zones into smaller zones. For example, a university might divide into zones based on departments. A company might divide into zones based on branch offices or internal divisions.

Zones contains all the domain names from a point in the name space tree downward to a host or to a domain name where another zone begins. These names and other related information about the zone are stored on master servers in zone files.

Each zone is an area of authority for which a master server is responsible. See Section 3.7.2 for a discussion of master servers.

3.5.1 Zone Hierarchy Example

Figure 3-2 shows the hierarchy of the internet, two top-level domains, and some of the major zones. For example, in Figure 3-2, everything below com is in the com top-level domain; the zones are within the dotted-line boxes. The host names are depicted by an x.

Figure 3-2 Hierarchy of BIND Zones and Domains on the Internet

The internet has a special domain used for locating gateways and supporting internet address-to-host name lookups. The mapping of internet addresses to domain names is called reverse translation. The special domain for reverse translation is the IN-ADDR.ARPA domain.

3.7 BIND Server Functions

If a network is entirely local, host names can be translated into host IP addresses by a centralized local hosts database. As soon as a network connects to another network, however, there needs to be a more robust mechanism for identifying IP addresses. When a network is part of the worldwide Internet, in particular, no single server or database can keep track of all addressing information. Millions of hosts and network domains are added, changed, and deleted every day.

The BIND mechanism that UCX uses to translate host names into IP addresses does not rely on one centralized listing of IP addresses. Instead, it uses several different types of name servers to ensure that all queries are resolved quickly and efficiently:

• Root servers
• Master servers (primary and secondary)
• Caching-only servers
• Slave servers
• Forwarder servers

When a client makes a query, a name server can be in one of three possible states:

• It knows the IP address authoritatively, based on addresses residing in its data files.
• It knows the IP address but not authoritatively from data cached in its memory from a previous query.
• It does not know the address and has to query another server.

The following sections discuss the different types of name servers and their primary responsibilities in the distributed environment of BIND and DNS.

3.7.1 Root Servers

Root servers know the top-level domains on the Internet. Root servers are the master servers for an Internet root zone. If a non-root server receives a request for a name not within its zone, the server starts name resolution at the root zone and accesses the root servers to get the needed information.

The InterNIC determines root servers for the Internet. The following root servers are valid:

• ns.nic.ddn.mil
• kava.nisc.sri.com
• aos.brl.mil
• c.nicer.net
• terp.umd.edu
• ns.nasa.gov
• nic.nordu.net
• ns.internic.net

These servers know about all the top-level DNS domains on the Internet. You must know about these servers when making queries about hosts outside of your local domain. The host names and internet addresses of these machines change periodically. Therefore, check with the InterNIC periodically to obtain changes and store them in the hints file of the BIND root name server (usually called NAMED.CA on a UCX system).

3.7.2 Master Servers

A master server is an authority for a zone. There are two types of master servers: primary and secondary.

The master primary server maintains the database for its zone by loading the database from a file on disk. This database is considered authoritative information. The primary server can delegate authority to other secondary servers in its zone, thus allowing them to answer queries for its zone.

A master secondary server receives its authority and database from the primary server. Secondary servers provide backup if a primary server fails, overloads, or goes off-line. You can configure a BIND server so that when a secondary server initially boots, the zone data loads from a backup file.

Once running, the secondary server periodically checks with the primary server for database information changes. If the sequence number of the database has changed, the secondary server copies the database.

Note

The secondary servers poll the master server at predetermined intervals specified in the zone database files. A time lapse between changing the master server's databases and polling of this information to the secondary servers may exist.

Each zone should have at least three master servers, one primary and two secondary. A server can be a master server for more than one zone, acting as the primary server for some zones and a secondary server for others.

3.7.3 Caching-Only Servers

All servers cache the information they receive for use until the data expires. The length of time a server caches the information is based on a time-to-live (TTL) field attached to the data the server receives.

Caching-only servers have no authority for any zone, and thus do not have complete information for any zone. Their database contains information acquired in the process of finding answers to clients' queries.

3.7.4 Slave Servers

Slave servers have no access to the Internet and cannot interact directly with root servers to get information not in local cache. To resolve queries, slave servers use forwarder servers, which are either primary or secondary servers. Until a list is exhausted or a query satisfied, a slave server forwards queries to the list of forwarder servers specified in the UCX configuration file.