1.2 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.2.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. Below the top-level domains, the domain namespace is further divided into subdomains representing individual organizations.
A list of top-level domains is available at the Internet Assigned Numbers Authority Web site.
Generic Top-Level Domain
The following table shows the top-level DNS domains and the organization types that use them:
The DNS hierarchy is shown in the illustration below.
Figure 1-1 DNS Hierarchy
Country Code Top-Level Domain
Top-level domains organize domain namespace geographically.
Infrastructure Top-Level Domain
The .arpa (Address and Routing Parameter Area) top-level domain is used extensively for Internet infrastructure. It contains subdomains such as in-addr.arpa and ntwk_ipv6_nw.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.
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 the domain names are a-z, A-Z, 0-9, hyphens, and underscores. 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.
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.
NOTE: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.arpadata 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.
Cuts can be made between any two adjacent nodes in the namespace. After all cuts are made, each group of connected namespaces 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, a cut could be made between the chicago.companya.com domain and the companya.com domain, then the chicago.companya.com zone could be delegated. Companya.com would have no authority over chicago.companya.com. Company A would have two domains:
-
companya.com zone, which has authority over the companya.com, washington.companya.com, and providence.companya.com domains
-
chicago.companya.com zone, which has authority over the chicago.companya.com domain
1.2.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 an internetwork. 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 using data in their zones or cache. 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 internetwork 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 would provide 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.
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 up, 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. Currently, there are 13 name servers available, which contain information of the name servers for all top-level domains.
DNS Resolver
Resolvers are programs. They connect 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 get the referrals (name server info) for edu. zone. Now, s1 will again initiates a query for the A record of www.mit.edu to the name server (using the referrals received) of edu.zone gets the referrals for mit.edu.zone. Server s1 again initiates a query for the A record of www.mit.edu to the name server (using the referrals received) of mit.edu. zone 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.2.3 Resource Records
Resource records (RRs) contain the host information maintained by the name servers and make up the DNS database. Different types of records contain different types of host information. For example, an Address record provides the name-to-address mapping for a given host, and a Start of Authority (SOA) record specifies the start of authority for a given zone.
A DNS zone must contain several types of resource records in order for DNS to function properly. Other RRs can be present, but the following records are required for standard DNS:
-
Name Server (NS): Binds a domain name with a hostname for a specific name server.
The DNS zone must contain NS records (for itself) for each primary and secondary name server of the zone. It must also contain NS records of the lower-level zones (if any) to provide links within the DNS hierarchy.
-
Start of Authority (SOA): Indicates the start of authority for the zone.
The name server must contain only one SOA record, specifying its zone of authority.
For example, the name server for a zone must contain the following:
-
An SOA record identifying its zone of authority
-
An NS record for the primary name server within the zone
-
An NS record for each secondary name server within the zone
-
NS records for delegated zones, if any
-
A records for the NS record (if applicable)
For more information about Resource Record types and their RDATA (Resource Record data), see Section A.2, Types of Resource Records.
Deleting Empty Resource Records
A new command line utility (dnsmaint.nlm) that supports deletion of empty RRs that have accumulated over time is introduced in NetWare 6.5 SP3 release.
This utility must be executed on a NetWare 6.5 SP3 machine in the eDirectory tree. The usage of the utility is specified below.
dnsmaint -User [-Password] [-Zonelist] [-LocatorObject] [-NotUsedSince]
The command line options are listed in the table below:
Table 1-1 Command Line Options for Resource Records
Examples:
For all the samples, it is assumed that the eDirectory distinguished name of DNS locator object is dns-dhcp.novell.
-
To delete all the empty RRs from all the zones in the eDirectory tree:
dnsmaint -User:admin.novell -Password:novell -LocatorObject:.dns-dhcp.novell
-
To delete all the empty RRs not used for three days from all the zones:
dnsmaint -User:admin.novell -Password:novell -LocatorObject:.dns-dhcp.novell -NotUsedSince:3
-
To delete all empty RRs from the zone blr.novell.com, which is under the eDirectory context dns-zones:
dnsmaint -User:admin.novell -Password:novell Zonelist:blr_novell_com.dns-zones
NOTE:All the “.” (dots) in the zone name blr.novell.com are replaced with “_” (underscores).
-
To delete empty RRs not used for five days from the zone 155.72.143.IN-ADDR.ARPA,which is under the eDirectory context novell.
dnsmaint -User:admin.novell -Password:novell -Zonelist:155_99_164_IN-ADDR_ARPA.novell -NotUsedSince:5
1.2.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 Novell 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 novell.com zone, and the secondary DNS server 2 provides backup support for 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
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 will be 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.
-
$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:This directive is not supported in the Management utilities. Use the ICE utility to use this directive.
-
$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, the SOA minimum TTL is used as the default.
The syntax is:
$TTL default-ttl [comment]