1.1 DNS
DNS is a distributed database system that provides hostname-to-IP resource mapping (usually the IP address) and other information for computers on a network. Any computer on the Internet can use a DNS server to locate any other computer on the Internet.
DNS is made up of two distinct components: the hierarchy and the name service. The DNS hierarchy specifies the structure, naming conventions, and delegation of authority in the DNS service. The DNS name service provides the actual name-to-address mapping mechanism.
For more information, see:
DNS/DHCP supports the standards of the Internet Request For Comments (RFCs). For more information, see Section A.0, Appendix.
1.1.1 DNS Hierarchy
DNS uses a hierarchy to manage its distributed database system. The DNS hierarchy, also called the domain namespace, is an inverted tree structure, much like eDirectory. Each node in the tree has a text label, which is zero to 63 characters long. The label (zero length) is reserved and is used for the root.
The DNS tree has a single domain at the top of the structure called the root domain. A period or dot (.) is the designation for the root domain. Below the root domain are the top-level domains that divide the DNS hierarchy into segments.
There are three types of top level domains (TLDs): Generic, Country Code, and Infrastructure. Below the top-level domains, the domain namespace is further divided into subdomains representing individual organizations:
A list of TLDs is available at the Internet Assigned Numbers Authority Web site.
The DNS hierarchy is shown in the illustration below.
Figure 1-1 DNS Hierarchy
Generic TLD
The following table shows the top-level DNS domains and the organization types that use them:
Table 1-1 DNS Domains and Organization Types
|
Domain |
Used by |
|---|---|
|
.com |
Commercial organizations, such as novell.com |
|
.edu |
Educational organizations, such as ucla.edu |
|
.gov |
Governmental agencies, such as whitehouse.gov |
|
.mil |
Military organizations, such as army.mil |
|
.org |
Nonprofit organizations, such as redcross.org |
|
.net |
Networking entities, such as nsf.net |
|
.int |
International organizations, such as nato.int |
Country Code TLD
Top-level domains organize domain namespace geographically.
Table 1-2 Country Code Domains
|
Domain |
Used by |
|---|---|
|
.fr |
France |
|
.in |
India |
|
.jp |
Japan |
|
.us |
United States |
Infrastructure TLD
The arpa (Address and Routing Parameter Area) TLD is used extensively for Internet infrastructure. It contains subdomains such as in-addr.arpa and ipv6.arpa.
Domains and Subdomains
A domain is a subtree of the DNS tree. Each node on the DNS tree represents a domain. Domains under the top-level domains represent individual organizations or entities. These domains can be further divided into subdomains to ease administration of an organization’s host computers.
For example, Company A creates a domain called companya.com under the com top-level domain. Company A has separate LANs for its locations in Chicago, Washington, and Providence. Therefore, the network administrator for Company A decides to create a separate subdomain for each division, as shown in Figure 1-2, Domains and Subdomains.
Any domain in a subtree is considered part of all domains above it. Therefore, chicago.companya.com is part of the companya.com domain, and both are part of the .com domain.
Figure 1-2 Domains and Subdomains
Domain Names
The domain name represents the position of an entity within the structure of the DNS hierarchy. The domain name of a node is the list of the labels on the path from the node to the root of the tree. Domain names are not case sensitive and their length is limited to 255 characters. Valid characters for domain names according to RFC 1034/RFC 1035 are a-z (case insensitive), 0-9, and hyphens. Each label in the domain name is delimited by a period. For example, the domain name for the Providence domain within Company A is providence.companya.com, as shown in Figure 1-2.
NOTE:OES DNS supports the underscore character in domain names using the check-names option for coexistence with Windows DNS servers.
Each computer that uses DNS is given a DNS hostname that represents the computer’s position within the DNS hierarchy. Therefore, the hostname for host1 in Figure 1-2 is host1.washington.companya.com.
The domain names in the figure end with a period, representing the root domain. Domain names that end with a period are called fully qualified domain names (FQDNs).
in-addr.arpa Domain
The in-addr.arpa domain (or zone) provides the mapping of IP addresses to names within a zone, enabling a client (or resolver) to request a hostname by providing an IP address. This function, also known as reverse lookup, is used by some security-based applications.
The file that stores the in-addr.arpa data contains pointer (PTR) records and additional name server records, including the Start of Authority (SOA) records, which are similar to the other DNS zone files. Within the in-addr.arpa zone file, IP addresses are listed in reverse order, and in-addr.arpa is appended to the address. A query for a host with an IP address of 10.10.11.1 requires a PTR query with the target address of 1.11.10.10.in-addr.arpa.
Domain Delegation
Domain delegation gives authority to an organization for a domain. Having authority for a domain means that the organization’s network administrator is responsible for maintaining the DNS database of hostname and address information for that domain. Domain delegation helps in distributing the DNS namespace.
A Division can be made between any two adjacent nodes in the namespace. After all divisions are made, each group of connected namespace is considered as a separate zone. The zone is authoritative for all names in the connected region, and these cuts are managed by domain delegation. All the host information for a zone is maintained in a single authoritative database.
For example, in Figure 1-2, the companya.com. domain is delegated to company A, creating the companya.com. zone. There are three subdomains within the companya.com. domain:
-
chicago.companya.com
-
washington.companya.com
-
providence.companya.com
The company A administrator maintains all host information for the zone in a single database and also has the authority to create and delegate subdomains.
For example, if company A’s Chicago location has its own network administrator, they could make a division between the chicago.companya.com domain and the companya.com domain and then delegate the chicago.companya.com zone. Then companya.com would have no authority over chicago.companya.com. Company A would have two domains:
-
companya.com, which has authority over the companya.com, washington.companya.com, and providence.companya.com domains
-
chicago.companya.com, which has authority over the chicago.companya.com domain
1.1.2 DNS Name Service
DNS uses the name service component to provide the actual name-to-IP address mapping that enables computers to locate each other on a network. The name service uses a client/server mechanism in which clients query name servers for host address information.
Name Servers
Name servers are information repositories that make up the domain database. The database is divided into sections called zones, which are distributed among the name servers. The name servers answer queries by using data in their zones or caches. A DNS name server can be either a primary name server or a secondary name server.
In addition to local host information, name servers maintain information about how to contact other name servers. Name servers in an intranet are able to contact each other and retrieve host information. If a name server does not have information about a particular domain, the name server relays the request to other name servers up or down the domain hierarchy until it receives an authoritative answer for the client’s query.
All name servers maintain information about contacting name servers that are available in other parts of the DNS namespace. This process of maintaining information is called linking to the existing DNS hierarchy. This is done by providing information about the root name servers. The administrator also enters information into the database about name servers in the lower-level domains. For example, when creating a subdomain, the administrator provides the name server information of the subzone.
Primary Name Servers
One DNS name server in each administrative zone maintains the read-write copies of hostname database and address information for an entire domain. This name server is the primary name server, and the domain administrator updates it with hostnames and addresses as changes occur. Primary and secondary name servers are also called masters and slaves.
Secondary Name Servers
Secondary name servers have read-only copies of the primary name server’s DNS database. Secondary name servers provide redundancy and load balancing for a domain.
Periodically, and when a secondary name server starts, the secondary name server contacts the primary name server and requests a full or incremental copy of the primary name server’s DNS database. This process is called zone transfer.
If necessary, a primary name server can also function as a secondary name server for another zone.
Forward Name Servers
The Forward DNS server forwards all queries to another DNS server and caches the results. Unlike primary and secondary zones, there is no functional difference between a designated server and other servers.
Root Name Servers
Root name servers contain information for the name servers in all top-level domains. The root server plays a very significant role in resolving DNS queries. It returns a list of the designated authoritative name servers for the appropriate top-level domain.
DNS Resolver
DNS resolvers are client programs. They interface user programs to domain name servers. A resolver receives a request from a user program and returns the desired information. It basically does a name-to-address, address-to-name, and general lookup.
Name Resolution
DNS is a distributed database with multiple servers that maintain different parts of the same tree. The links between the servers are through root server and domain delegation, as shown in the following figure.
Figure 1-3 DNS Namespace
DNS queries can be resolved in two ways:
-
Iterative query: An iterative request from a client expects the best actual answer or referral that the DNS server can immediately provide, without contacting other DNS servers.
For example, in Figure 1-4, Harry initiates an iterative query for the A record of www.mit.edu. After receiving this query, the name server (s1) might return the answer, if the answer is available in the cache. If the answer is not available, the server returns a referral [NS and A rrs] to the other DNS servers that are closer to the names queried by the client.
-
Recursive query: A recursive request from a client expects the actual answer that the DNS server can provide either from its own cache or by contacting other DNS servers.
For example, in Figure 1-3 and Figure 1-4, Harry initiates a recursive query for the A record of www.mit.edu. After receiving this query, the name server (s1) contacts the root server to resolve this query and gets the referrals (name server info) for the .edu zone. Now, s1 again initiates a query for A record of www.mit.edu to the name server (using the referrals received) of edu.zone and will get the referrals for mit.edu.zone. Server s1 will again initiate a query for the A record of www.mit.edu to the name server (using the referrals received) and gets the A record. This A record is returned to Harry.
Figure 1-4 Name Resolution
Caching
Caching is a mechanism to improve the performance of query resolution. The cache memory is empty when a server first starts. This cache is built as it starts resolving queries. It caches all the answers and referrals during recursive queries, and the cached data remains in the cache memory until the Time-To-Live (TTL) expires. The TTL specifies the time interval that the entries can be cached before they are discarded.
1.1.4 DNS Structure
DNS is administered by building a database of information that includes all the resource records of a zone into a text file called a master file. The administration of these files is difficult and cumbersome. Initial versions of the DNS server used Btrieve as its database. Other vendors also use large files to store information required for a DNS zone.
Figure 1-5 represents a traditional DNS strategy. A zone, such as novell.com, uses a primary DNS server to handle queries about the entities within it. A DNS server supports more than one zone, and it has at least one secondary server for backup (redundancy) or load-sharing purposes. The primary DNS server provides DNS name service for two zones: novell.com and other.com. The secondary DNS server 1 provides backup support for the novell.com zone, and the secondary DNS server 2 provides backup support for the other.com zone. When changes occur to the DNS database, the master files corresponding to that zone at the secondary server are updated by zone transfers.
The file storing the resource records for a zone might have hundreds or thousands of entries for different types of resources, such as users’ addresses, hosts, name servers, mail servers, and pointers to other resources.
Figure 1-5 DNS Structure
The next section provides details on the following:
DNS Master File
A DNS master file is a text file that contains resource records that describe a zone. When you build a zone, the DNS objects and their attributes translate into resource records for that zone.
You can import a DNS master file if it conforms to IETF RFCs 1034, 1035, and 1183 and is in BIND master file format. A sample DNS master file is shown in the following example:
$ORIGIN companya.com. @ soa ns.companya.com. admin.novell.com ( 1996091454 /* SOA sr no */ 3600 /* Zone Refresh interval*/ 300 /* Zone retry interval */ 604800 /* Zone Expire interval */ 86400) /* Zone Minimum TTL */ ns ns1.companya.com. ns ns2.companya.com. mx 5 companya.com. $ORIGIN companya.com. ns1 a 123.45.67.89 ns2 a 123.45.68.103; End of file
Master File Directives
The master file directives include $GENERATE, $ORIGIN, $INCLUDE, and $TTL.
-
$GENERATE: Enables you to create a series of resource records that differ from each other only by an iterator.
The syntax is:
$GENERATE range lhs type rhs [comment]
Range: Can be set to start-stop or start-stop/step. All values for start, stop, and step must be positive.
lhs: The owner name of the records to be created. The $ symbols in the lhs are replaced by the iterator value. Using \$ allows a $ symbol in the output. A $ can be optionally followed by a modifier as $[{offset[,width[,base]]}].
A modifier can have an offset, a width, and a base. The offset is used to change the value of the iterator, base specifies the output format in which the values are printed, and width is used for padding. The available base values are decimal (d), octal (o), and hexadecimal (x or X). The default modifier is ${0, 0, d}. If the lhs is not absolute, the current value of $ORIGIN is appended to the name.
Type: The resource record type. The supported types are PTR, CNAME, DNAME, A, AAAA, and NS.
rhs: The domain name. Processed similarly to lhs.
For example,
$ORIGIN 0.0.192.IN-ADDR.ARPA $GENERATE 1-2 0 NS SERVER$.EXAMPLE.com
is equivalent to
0.0.0.192.IN-ADDR.ARPA NS server1.example.com 0.0.0.192.IN-ADDR.ARPA NS server2.example.com
-
$ORIGIN: Enables you to set the domain name as the origin. The origin is appended to all domain names in the zone data file that do not end with a dot.
The syntax is:
$ORIGIN domain-name [comment]
For example,
$ORIGIN example.com. WWW CNAME Web server
is equivalent to
WWW.EXAMPLE.COM. CNAME webserver.example.com.
NOTE:If the $ORIGIN directive is not already included, make sure you include this directive at the start of the zone file.
-
$INCLUDE: Enables you to include another file in the current file. The included file can be read and processed as if it were present in the current file at that point. The domain name can also be specified with the $INCLUDE directive to process the file included with $ORIGIN set to that value. If the origin is not specified, the current $ORIGIN is used.
After the included file is processed, the origin and the domain name values are reset to their previous values before processing the included file.
The syntax is:
$INCLUDE filename [origin] [comment]
NOTE:The $INCLUDE directive is not supported through the management utilities.
-
$TTL: Enables you to set the default time to live for the subsequent resource records without any TTL values. The time range for TTL is from 0 to 214748367 seconds. If the $TTL value is not present in the master file, SOA minimum TTL is used as the default.
The syntax is:
$TTL default-ttl [comment]