Table of Contents 
DOS
The Domain Name System is a standard protocol with STD number 13. Its status is recommended. It is described in RFC 1034 and RFC 1035. This section explains the implementation of the Domain Name System, and the implementation of name servers. See Domain Name System for an overview of the Domain Name System and its relationship to the IP addressing scheme.
The Domain Name System uses the concept of a distributed name space. Symbolic names are grouped into zones of authority, or more commonly zones. In each of these zones, one or more hosts has the task of maintaining a database of symbolic names and IP addresses and providing a server function for clients who wish to translate between symbolic names and IP addresses. These local name servers are then (through the internet on which they are connected) logically interconnected into a hierarchical tree of domains. Each zone contains a part or a subtree of the hierarchical tree and the names within the zone are administered independently of names in other zones. Authority over zones in vested in the name servers. Normally, the name servers which have authority for a zone will have domain names belonging to that zone, but this is not required. Where a domain contains a subtree which falls in a different zone, the name server(s) with authority over the superior domain are said to delegate authority to the name server(s) with authority over the subdomain. Name servers may also delegate authority to themselves; in this case, the domain name space is still divided into zones moving down the domain name tree, but authority for two zones is held by the same server. The division of the domain name space into zones is accomplished using resource records stored in the Domain Name System:
The results of this scheme are:
Note: Although domains within the namespace will frequently map in a logical fashion to networks and subnets within the IP addressing scheme, this is not a requirement of the Domain Name System. Consider a router between two subnets: it has two IP addresses, one for each network adapter, but it would not normally have two symbolic names.
Domain resolution is a client/server process. The
client function (called the resolver or name resolver) is
transparent to the user and is called by an application to resolve symbolic
high-level names into real IP-addresses or vice versa. The name server (also
called a domain name server) is a server application providing the
translation between high-level machine names and the IP addresses. The basic
process is shown in Figure - Using a Full
Resolver for Domain Name Resolution and
Figure - Using a Stub Resolver for Domain
Name Resolution. The former shows a program called a full
resolver, which is a program distinct from the user
program, which forwards all queries to a name server for processing.
Responses are cached by the name server for future use,
and often by the name server. The latter shows a stub
resolver, which is a routine linked with the user
program, which forwards the queries to a name server for processing. Responses
are cached by the name server but not usually by the resolver although this is
implementation dependent. On UNIX, the stub resolver is implemented by two
library routines: gethostbyname() and gethostbyaddr() for
converting host names to IP addresses and vice versa. Other platforms have the
same or equivalent routines. Stub resolvers are much more common than full
resolvers.
Figure: Using a Full Resolver for Domain Name Resolution
Figure: Using a Stub Resolver for Domain Name Resolution
Domain name queries can be one of two types: recursive or iterative (also termed non-recursive). A flag bit in the domain name query specifies whether the client desires a recursive query and a flag bit in the response specifies whether the server supports recursive queries. The difference between a recursive and an iterative query arises when the server receives a request for which it cannot supply a complete answer by itself. A recursive query requests that the server should issue a query itself to determine the requested information and return the complete answer to the client. An iterative query means that the name server should return what information it has available and also a list of additional servers for the client to contact to complete the query.
Domain name responses can be one of two types: authoritative and non-authoritative. A flag bit in the response indicates which type a response is. When a name server receives a query for a domain in a zone over which it has authority, it returns all of the requested information in a response with the authoritative answer flag set. When it receives a query for a domain over which it does not have authority, its actions depend upon the setting of the recursion desired flag in the query.
Each name server has authority for zero or more zones. There are three types of name server:
When a domain is registered with the root and a separate zone of authority established, the following rules apply:
It is also recommended that name servers which delegate authority also apply these rules, since the delegating name servers are responsible for the behavior of name servers under their authority.
The Domain Name System's distributed database is composed of resource records (RRs). They provide a mapping between domain names and network objects. The most common network objects are the addresses of Internet hosts, but the Domain Name System is designed to accommodate a wide range of different objects. The general format of a resource record is:
name ttl class type rdata
where:
The different types are described in detail in RFCs
1034, 1035 and 1706. Each type has a name and a value. Commonly used types
include:
All messages in the Domain Name System protocol use a
single format. This format is shown in
Figure - DNS Message Format. This frame is
sent by the resolver to the name server. Only the header and the question
section are used to form the query. Replies and/or forwarding of the query use
the same frame, but with more sections filled in (the
answer/authority/additional sections).
Figure: DNS Message Format
The header section is always present and has a fixed length of 12 bytes. The other sections are of variable length.
The next section contains the queries for the name server. It contains
QDcount (usually 1) entries, each in the format shown in
Figure - DNS Question Format.
Figure: DNS Question Format - All of the fields are byte-aligned.
The alignment of the Type field on a 4-byte boundary is for example purposes
and is not required by the format.
X'07'
"raleigh"
X'03'
"ibm"
X'03'
"com"
X'00'
Thus the entry in the question section for raleigh.ibm.com would require 21
bytes: 17 to store the domain name and 2 each for the Qtype and Qclass fields.
These three sections contain a variable number of resource records. The
number is specified in the corresponding field of the header. The resource
records are in the format shown in
Figure - DNS Answer Record Entry Format.
Figure: DNS Answer Record Entry Format - All of the fields are
byte-aligned. The alignment of the Type field on a 4-byte boundary is for
example purposes and is not required by the format.
Where the fields before the TTL field have the same meanings as for a question
entry and:
In order to reduce the message size, a compression
scheme is used to eliminate the repetition of domain names in the various RRs.
Any duplicate domain name or list of labels is replaced with a pointer to the
previous occurrence. The pointer has the form of a 2-byte field:
Consider a stand-alone network (no outside
connections), consisting of two physical networks: one has an internet network
address 129.112, the other has a network address 194.33.7, interconnected by an
IP gateway (VM2).
Figure: A Simple Configuration - Two networks connected through an
IP gateway.
Let us assign the name server function to VM1. Remember that the domain hierarchical tree forms a logical tree, completely independent of the physical configuration. In this simple scenario, there is only one level in the domain tree. Let's give this configuration the domain name test.example.
The zone data for the name server will then be as shown in
Figure - Zone Data for the Name Server.
Consider the case where a connection is made to a third network (129.113)
which has an existing name server with authority for that zone.
Let us suppose that the domain name of the other network is tt.ibm.com and
that its name server is located in VM9.
All we have to do is add the address of this name server to our own name
server database, and to reference the other network by its own name server. The
following two lines are all that is needed to do that:
Domain Name System Messages are transmitted either as
datagrams (UDP) or via stream connection (TCP).
Server port 53 (decimal).
Messages carried by UDP are restricted to 512 bytes. Longer messages are
truncated and the TC bit is set in the header. Since UDP frames can be lost, a
retransmission strategy is required.
Server port 53 (decimal).
In this case, the message is preceded by a 2-byte field indicating the total
message frame length.
STD 3 - Host Requirements requires that:
The following RFCs define the Domain Name System standard and the
information kept in the system:
Three common utilities for querying name servers are
provided with many DNS implementations:
All of the IBM TCP/IP platforms use stub resolvers in
each client application. All except OS/400 and DOS include a name server
implementation, which we will discuss in detail in the following sections.
TCP/IP for VM allows for the use of a local site tables or the use of the
Domain Name System.
The use of local site tables or the use of the Domain Name System is
specified in the TCPIP DATA file using the NSINTERADDR statement. If this
statement is omitted, then TCP/IP will use a local site table. If this
statement exists, TCP/IP will use the Domain Name System. If the parameter on
the NSINTERADDR statement is the loopback address (127.0.0.1)
(12)then the local name server will
be used. Otherwise one (or more) more remote name servers specified on the
NSINTERADDR statements will be used. This provides a total of five possible
configurations.
To use a local site table, omit the NSINTERADDR statement from the TCPIP
DATA file. Name resolvers need access to a site table
to resolve symbolic names. The source for this is the
HOSTS LOCAL file which must be converted into a machine-readable form by
running the MAKESITE utility. MAKESITE generates two files, HOSTS ADDRINFO and
HOSTS SITEINFO, which comprise the site table. The site table is used if no
name server is available, that is, if no name server is specified or if the
specified name server(s) are unavailable. The only exception is SMTP, which
never uses the site tables if it is configured to use a name server.
The resolver program obtains the IP addresses of the remote name server(s)
from the NSINTERADRR statement(s) in the TCPIP DATA file. If multiple
NSINTERADDR statements are found, then connections to the remote name servers
are attempted in the order they appear in this configuration file. The number
of times that each connection is tried and the timeout interval for the server
to respond to the UDP datagram containing the query are specified on the
RESOLVERUDPRETRIES and RESOLVERTIMEOUT statements.
The name server software is run in a service virtual machine, normally
called NAMESRV. Resolver programs use the loopback address specified on the
NSINTERADDR statement in the TCPIP DATA file. The server does not have any data
available locally, other than a set of resource records specifying the IP
addresses name servers to query for particular domains (and possibly an initial
set of other resource records). However, the server caches data locally so that
subsequent queries for the same domain name can be quickly answered, and it
also provides for recursion if recursive resolution is asked by the client
resolver. The only data required are the IP addresses of the remote server(s).
The name server configuration file name is specified in the PROFILE EXEC on
the NAMESRV 191 minidisk as an argument to the NSMAIN command which starts the
name server. The default is NSMAIN DATA. In this configuration file, the entry:
The name server software is run in the NAMESRV service virtual machine and
resolver programs use the loopback address. The name server can operate as a
primary and/or a secondary name server. The domain data is stored in an SQL/DS
table.
Mail eXchanger (MX) records are supported. They
are only used by SMTP ( see SMTP and the Domain
Name System for more details about the use of MX records).
The NSMAIN DATA contains PRIMARY and/or SECONDARY statements instead of a
CACHINGONLY statement. An example is shown in
Figure - Sample NSMAIN DATA File for VM.
VM provides the NSLOOKUP and DIG programs to query name servers. For more
information on these programs, please refer to IBM TCP/IP Version 2 Release
3 for VM: User's Guide.
Note: Consult IBM TCP/IP Version 3 Release 1 for MVS:
Customization and Administration Guide for information on the search order
used for TCP/IP data sets.
TCP/IP for MVS supports both local site tables and the Domain Name System.
The use of local site tables or the use of the Domain Name System is
specified in the TCPIP.DATA data set using the NSINTERADDR statement. If this
statement is omitted, TCP/IP will use a local site table. If this statement
exists TCP/IP will use the Domain Name System. If the parameter on the
NSINTERADDR statement is the loopback address (127.0.0.1)
(13)then the local name server will
be used, otherwise one (or more) more remote name servers specified on the
NSINTERADDR statements will be used. This provides a total of five possible
configurations.
To use a local site table, omit the NSINTERADDR statement from the
TCPIP.DATA data set. Name resolvers need access to a site table
to resolve symbolic names. The source for this is the
HOSTS.LOCAL data set, which must be converted into a machine-readable form by
running the MAKESITE utility. MAKESITE generates two data sets, HOSTS.ADDRINFO
and HOSTS.SITEINFO, which comprise the site table. The site table is used if no
name server is available, that is, if no name server is specified or if the
specified name server(s) are unavailable. The only exception is SMTP, which
never uses the site tables if it is configured to use a name server.
The resolver program obtains the IP addresses of the remote name server(s)
from the NSINTERADRR statement(s) in the TCPIP.DATA data set. If multiple
NSINTERADDR statements are found then connections to the remote name servers
are attempted in the order they appear in this configuration file. The number
of times that each connection is tried and the timeout interval for the server
to respond to the UDP datagram containing the query are specified on the
RESOLVERUDPRETRIES and RESOLVERTIMEOUT statements.
The name server software is run in a separate address space. Resolver
programs use the loopback address specified on the NSINTERADDR statement in the
TCPIP DATA file. The server does not have any data available locally, other
than a set of resource records specifying the IP addresses name servers to
query for particular domains (and possibly an initial set of other resource
records). However, the server caches data locally so that subsequent queries
for the same domain name can be quickly answered, and it also provides for
recursion if recursive resolution is asked by the client resolver. The only
data required are the IP addresses of the remote server(s).
The NSMAIN.DATA configuration data set contains the entry:
The name server software is run in a separate address space and resolver
programs use the loopback address. The name server can operate as a primary
and/or a secondary name server. The domain data is stored in a DB2 SQL table.
The name server software is run in the NAMESRV service virtual machine and
resolver programs use the loopback address. The name server can operate as a
primary and/or a secondary name server. The domain data is stored in an SQL/DS
database.
Mail eXchanger (MX) records are supported. They
are only used by SMTP (see SMTP and the Domain
Name System for more details about the use of MX records).
The NSMAIN DATA contains PRIMARY and/or SECONDARY statements instead of a
CACHINGONLY statement. An example is shown in
Figure - Sample NSMAIN DATA File for MVS.
A sample DB2 configuration is shown schematically in
Figure - DB2 Storage Group, Tablespace, and
Table Definition.
MVS provides the NSLOOKUP and DIG programs to query name servers. For more
information on these programs, please refer to IBM TCP/IP Version 3 Release
1 for MVS: User's Guide.
For more information on their installation, please refer to the IBM
TCP/IP Version 3 Release 1 for MVS: Customization and Administration Guide.
TCP/IP on OS/400 systems does not support the name server function but can
use a remote name server (that is, the user applications include a stub
resolver). A flat name space is supported and the local host table is
configured using the OS/400 TCP/IP configuration panels.
Domain name services are fully implemented in AIX/6000. AIX/ESA provides
similar services. We shall concentrate on the AIX/6000 implementation here.
The following types of name server are supported:
The AIX resolver routines, gethostbyaddr() and gethostbyname(), attempt to
resolve names using the following procedure:
The named daemon provides the name server
function. It is controlled by the AIX SRC (system resource control). It can be
started automatically with each system restart by either using the smit
stnamed fastpath command or by editing the rc.tcpip file to uncomment the
line:
An AIX host can be configured to use a name server by using the following
steps:
The daemon also supports resource records for mail of types MB (mailbox
domain name), MR (mail rename domain name), MG (mail group member), MINFO
(mailbox or mail list information) and MX (mail exchange).
AIX/6000 includes the host and nslookup programs. AIX/6000 also provides the
dig program to query name servers.
TCP/IP for OS/2 provides a similar implementation to that in AIX. The
following types of name server are supported:
In order to use any of the first three, the named server which is
included in the Domain Name Server kit is required.
The OS/2 resolver routines, gethostbyaddr() and gethostbyname() attempt to
resolve names using the following procedure:
The named daemon provides the name server
function. It is configured using the \TCPIP\ETC\NAMEDB\NAMED.BT file.
The HOST and NSLOOKUP programs are included in TCP/IP for OS/2.
Please refer to IBM TCP/IP Version 2.0 for OS/2: User's Guide for
more details about the HOST and NSLOOKUP commands.
TCP/IP for DOS system does not support the name server function but can use
a remote name server (that is, the user applications include a stub resolver).
A flat name space is supported and the local host table is found in the
\TCPDOS\ETC\HOSTS file.
The HOST program is included with TCP/IP for DOS.
Please refer to IBM TCP/IP Version 2.1.1 for DOS: User's Guide for
more details about the HOST command.
;note: an SOA record has no TTL field
;
$origin test.example. ;note 1
;
@ IN SOA VM1.test.example. ADM.VM1.test.example.
(870611 ;serial number for data
1800 ;secondary refreshes every 30 mn
300 ;secondary reties every 5 mn
604800 ;data expire after 1 week
86400) ;minimum TTL for data is 1 week
;
@ 99999 IN NS VM1.test.example. ;note 2
;
VM1 99999 IN A 129.112.1.1 ;note 3
99999 IN WKS 129.112.1.1 TCP (SMTP ;note 4
FTP
TELNET
NAMESRV)
;
RT1 99999 IN A 129.112.1.2
IN HINFO IBM RT/PC-AIX ;note 5
RT2 99999 IN A 129.112.1.3
IN HINFO IBM RT/PC-AIX
PC1 99999 IN A 129.112.1.11
PC2 99999 IN A 194.33.7.2
PC3 99999 IN A 194.33.7.3
;
;VM2 is an IP gateway and has 2 different IP addresses
;
VM2 99999 IN A 129.112.1.4
99999 IN A 194.33.7.1
99999 IN WKS 129.112.1.4 TCP (SMTP FTP)
IN HINFO IBM-3090-VM/CMS
;
4.1.112.129.in-addr.arpa. IN PTR VM2 ;note 6
;
;Some mailboxes
;
central 10 IN MX VM2.test.example. ;note 7 and 8
;
;a second definition for the same mailbox, in case VM2 is down
;
central 20 IN MX VM1.test.example.
waste 10 IN MX VM2.test.example.
Figure: Zone Data for the Name Server
**** Notes ****
4.5.6 Extended Scenario
Figure: Extended Configuration - A third network is connected to the
existing configuration.
tt.ibm.com. 99999 IN NS VM9.tt.ibm.com.
VM9.tt.ibm.com. 99999 IN A 129.113.1.9
This simply indicates that VM9 is the authority for the new network, and that
all queries for that network will be directed to that name server.
4.5.7 Transport
UDP usage
TCP usage
4.5.8 References
4.5.9 DNS Applications
4.5.10 Implementations
4.5.10.1 VM
Using a local site table
Using a remote name server
Caching-only name server
CACHINGONLY fn ft fm
specifies the file name of the data file to be used. The information is written
in standard resource record format, for example:
PARIS.IBM.COM IN NS VMA.PARIS.IBM.COM
LAHULPE.IBM.COM IN NS MIDVMB.LAHULPE.IBM.COM
.. IN NS SRI-NIC.ARPA
SRI-NIC.ARPA IN A 10.0.0.51
IN A 26.0.0.73
VMA.PARIS.IBM.COM IN A 9.37.17.2
MIDVMB.LAHULPE.IBM.COM IN A 9.36.1.4
This simply means that all queries for domain PARIS.IBM.COM will be forwarded
to VMA.PARIS.IBM.COM, all queries for LAHULPE.IBM.COM to
MIDVMB.LAHULPE.IBM.COM, and all others to the root server SRI-NIC.ARPA.
Full-function name server
;***********************************************************
; This file is read by the name server upon initialization.
; The default name of this file is NSMAIN DATA *.
; A different file may be read by suppling a parameter when
; the name server is started... NSMAIN MY FILE B for example.
;
; This file contains the startup parameter values which define
; the name server as authoritative for stn.mlv.fr and
; tst.mlv.fr. The data for stn.mlv.fr is defined locally,
; whereas the data for tst.mlv.fr is defined remotely and zone
; transferred to the local name server.
;
; If you are not using SQL, remove all PRIMARY and SECONDARY
; statements and use the CACHINGONLY statement to define a
; database of remote name servers.
;***********************************************************
;
; The PRIMARY and SECONDARY statements are used if you are using an
; SQL database.
;
PRIMARY stn.mlv.fr STN ; Use authoritative tables STN0 & STN1
SECONDARY tst.mlv.fr TST 152.9.271.2
; ; Use authoritative tables TST0 & TST1
; ; Transfer domain data for tst.mlv.fr into tables
; ; TST0 and TST1 from 152.9.271.2
;
; The CACHINGONLY statement is used to define a caching only name server
; that obtains all records from remote name servers.
;
; CACHINGONLY NSMAIN CACHE A ; Sample CACHINGONLY data file
;
;
NEGATIVECACHING ; The NS will store negative query answers
STANDARDQUERYCACHE 100 ; The number of Standard queries to cache
INTERMEDIARYQUERYCACHE 50 ; The number of Intermediary queries to cache
INVERSEQUERYCACHE 5 ; The number of Inverse queries to cache
DATABASEQUERYCACHE 5 ; The number of Data Base queries to cache
;
;
LRUTIME 300 ; Time an entry must be in the cache before it
; can be replaced by the LRU algorithm
HOSTNAMECASE LOWER ; Host names in the SQL tables are in lower case
DOMAINNAMEPORT 53 ; Listen on port N, default is 53
; UDPONLY ; Use UDP only when contacting a remove NS
UDPRETRYINTERVAL 5 ; After N seconds, try next remote NS
; NORECURSION ; Prevents NS from performing recursion
MSGNOH ; Specifies the NS use CP MSGNOH, not CP MSG
SMSGUSERFILE VALIDUSR EXEC A ; SMSG userid authorization file
TRACE QUEUE ; Display query origination and query name
Figure: Sample NSMAIN DATA File for VM
User Applications
4.5.10.2 MVS
Using a local site table
Using a Remote Name Server
Caching-only name server
CACHINGONLY data_set_name
which gives the name of the data set containing these IP addresses. The
information is written in standard resource record format, for example:
PARIS.IBM.COM IN NS MVSA.PARIS.IBM.COM
LAHULPE.IBM.COM IN NS MIDVMB.LAHULPE.IBM.COM
.. IN NS SRI-NIC.ARPA
SRI-NIC.ARPA IN A 10.0.0.51
IN A 26.0.0.73
MVSA.PARIS.IBM.COM IN A 9.37.17.2
MIDVMB.LAHULPE.IBM.COM IN A 9.36.1.4
This simply means that all queries for domain paris.ibm.com will be forwarded
to mvsa.paris.ibm.com, all queries for lahulpe.ibm.com to
midvmb.lahulpe.ibm.com, and all others to the root server sri-nic.arpa.
Full-function name server
;
DB2SYSNAME SYS1 ; Define Local DB2 subsystem
PRIMARY watson.ibm.com WATSON ; Use authoritative tables WATSON0, WATSON1
SECONDARY ibm.com IBM 129.34.128.245
; ; Transfer domain data for ibm.com into tables
; ; IBM0 and IBM1 from 129.34.128.245
;
NEGATIVECACHING ; The NS will store negative query answers
STANDARDQUERYCACHE 100 ; The number of Standard queries to cache
INTERMEDIARYQUERYCACHE 50 ; The number of Intermediary queries to cache
INVERSEQUERYCACHE 5 ; The number of Inverse queries to cache
;
;
LRUTIME 300 ; Time an entry must be in the cache before it
; can be replaced by the LRU algorithm
HOSTNAMECASE UPPER ; Host names in the DB2 tables are in upper case
DOMAINNAMEPORT 53 ; Listen on port N, default is 53
UDPONLY ; Use UDP only when contacting a remove NS
UDPRETRYINTERVAL 5 ; After N seconds, try next remote NS
; NORECURSION ; Prevents NS from performing recursion
TRACE QUEUE ; Display query origination and query name
Figure: Sample NSMAIN DATA File for MVS
Figure: DB2 Storage Group, Tablespace, and Table Definition
User Applications
4.5.10.3 OS/400
4.5.10.4 AIX
#start /etc/named "$src_running"
The named daemon can also be started by issuing the startsrc -s named
command.
domain itsc.raleigh.ibm.com
nameserver 9.67.38.101
nameserver 9.67.38.96
User Applications
4.5.10.5 OS/2
User Applications
4.5.10.6 DOS
User Applications
Simple
Mail Transfer Protocol (SMTP)