The Domain Name Service (DNS) is a vital part of any network. The DNS allows a node to quickly resolve hostnames to IP addresses or vise-versa. The global DNS is composed of a hierarchy of name servers that each contain authoritative or valid information about the nodes contained within its zone. Each name server keeps information about a group of nodes for which it is responsible for, this group of nodes is called a zone. A domain may be contained within one zone or multiple zones. Other zones may also exist within each of those zones. In this manner, the global database of hostnames to IP Addresses is delegated evenly across the internet. Hostnames and IP Addresses are resolved efficiently through name server to name server queries.

The chapter begins with an in depth discussion of the functionality of the Domain Name Service System. The key files that make up the local name server are defined and explained through various examples. The second half of the chapter describes the configuration process for a Caching Only Name Server and then an Authoritative Name Server.

DNS systems communicate with each other to transfer zone information or to make single hostname queries. User Datagram Protocol is usually used for queries because of its connectionless nature. The reliability of TCP is used for zone transfers between a secondary and a primary DNS.

A DNS is only concerned with the machines that is assigned to keep track of. For any host information that is not within its zone, the DNS queries another DNS for the information. The DNS may or may not know the answer to a query, and it may continue to forward the query until it finds a DNS that knows the answer. The forwarding of queries is not an random act, there are authoritative DNS systems that relate to specifically defined zones. Within these zones there exist other zones, other DNS systems, and so forth. A recursive DNS is one that can forward queries to other authoritative DNS systems. Authoritative simply means that the DNS responsible for the zone in question. The DNS process works by assigning zones to individual DNS systems and then building an architecture of connected DNS servers to share information. A Domain Name Service Server may also be referred to as a name server.

As in the picture above, the internet is divided to primary domains that are called top domains. These domains are then divided into subdomains that make up the networks around the world. There are six top level domains in use plus the hundreds of country domains such as fr ,as shown on the far left in the figure above.

As discussed previously, name servers answer a machine's query for a hostname to IP address match. Name servers query other name servers for information that it is unaware of. The named daemon handles all of the requests for applications. The name resolver performs the actual process of answering an applications query. The resolver may find the answer in its cache or it may forward the query to another name server as previously described. The information the resolver receives from a name server is stored temporarily in a cache to reduce network traffic. Consecutive queries for a recently cached hostname or IP address will then be locally resolved

The name server may reply to the resolver with a direct answer or it may reply with the address of another name server that should know the answer. The resolver repeats the request to the new name server and proceeds until an answer is achieved. Alternatively, the resolver may chose to query a recursive name server. A recursive name server will forward the query itself if it cannot make the necessary IP match. The answer will then be cached by both the recursive name server and the original resolver.

Name servers communicate to each other using a specific header format. The header is divided into separate fields, each of which provide specific information about the query or answer.

The DNS Header communicates information between name servers. The Question Field lists the hostname or IP address that needs to be resolved. If the question can be answered, the answer would be contained in the Answer field. If the query cannot be answered by a name server, it will reply and fill the Authority field with information about authoritative name servers that should be able to answer the question. The Additional field is used to provide more information about the suggested authoritative name servers.

The Header Field is used to describe the DNS message. There are several sub-fields in the Header Field. The QR Sub-Field defines the message as a query (0) or a response (1). The OpCode Sub-Field is used to define the query as a standard query (0), an inverse query (1), or a server status query (2). The AA field is set to one when the answer is from an authoritative name server. The TC Sub-Field is set to 1 to identify that the message has been truncated due to excessive length. The RD Sub-Field is set to 1 by a resolver that is querying for a recursive answer. A recursive name server will note this field and forward the query itself to obtain an answer. The RA Sub-Field is set to one during a name servers response. A 1 in the RA Sub-Field announces that the name server is capable of performing recursive queries. The Z Sub-Field is reserved for later use, it currently serves no purpose. The RCODE Sub-Field identifies errors or a an unanswered query. If set to 0, there were no problems with the query and either an answer or forwarding information has been provided.

The QDCOUNT Sub-Field provides the number of queries in the message, and the ANCOUNT Sub-Field provides the number of answers in the message. The NSCOUNT Sub-Field identifies the number of Resource Records in the Authority field. The ARCOUNT Sub-Field identifies the number of Resource Records in the Additional field.

The zone and reverse look-up files contain resource records for each machine in the zone including the name server. There are different types of resource records. The Start of Authority resource record (SOA), is the first record that is listed in each zone file. The A and AAAA resource records are used to match the hostname to an IPv4 address (A) or an IPv6 address (AAAA). The NS resource records identifies the name servers that contain information about the zone. There are also other types of resource records that may be used to identify an email address, to provide additional information about the server, or to identify an alias for a hostname. It is up to the administrator to decide how much information the name server should share. The basic resource record Format is shown on the next page.

The Name Field matches a node or a zone to a resource record. If the record corresponds to a query for portzic, portzic.enst-bretagne.fr would be in this field. The Type Field identifies the type of Resource Record that is listed. As stated previously, a Resource Record may correspond to a network address, a zone, an alias, or other such network information that the name server may provide. The Class Field is usually set to IN to identify the internet class. The TTL field defines the amount of the time that the Resource Record may be valid in a cache. Once the Time-to-Live (TTL) expires, a name server must ask for an update for the expired Resource Record. The Data Length Field identifies the length Resource Record and it includes the actual data to answer the query. The data may be a single address; a hostname, or other multiple amounts of information depending on the type of resource record.

The SOA Resource Record defines a zone and lists all of the information for the machines in the zone. The SOA record matches all of the hostnames in the zone to their respective IP addresses. An example SOA is shown below:

The text grouped by parenthesis includes important information about the zone. The text is placed in parenthesis to indicate that it should all be included on the same line. The data that follows matches all of the hosts to their respective IP addresses. Note that each of these lines is defined by Resource Record type, either an A, AAAA, or NS. The A record class identifies an IPv4 address class, and the AAAA identifies the IPv6 address class. NS denotes that the information refers to a name server.

IN-ADDR-ARPA

For mapping IP addresses to hostnames, the IN-ADDR-ARPA resource record type is used. This type of record is formatted much like the SOA record except that the addresses are on the far left and the hostnames are on the right. In fact, only a portion of the address is actually listed on each line. The IN-ADDR-ARPA record is defined by the first few three or two sections of the IPv4 address, depending on the network. For a file named A.B.C.rev.zone, the file should look like this:

Since the first three numbers in the IPv4 address are pre-defined in the reverse zone file, the only numbers that are necessary inside the actual file is the last number. Comparing the IN-ADDR-ARPA file to the previous SOA file, one can see many similarities. The files provide the same information, the only difference between the two is that actual IP address to hostname format is reversed.

IPv6.INT

The IPv6.INT is used to provide reverse look-ups for IPv6 addresses. The IPv6 address is represented in a byte by byte format and in reverse order.

The IPv6.INT resource record is a new type of record. IPv6 reverse address lookups cannot be defined in the regular IN-ADDR-ARPA record. .

The first section of the file identifies the directory where all of the resource records can be found. It also contains information about another name server that can be queried for unknown information. There are various boot file directive options that can be used with Bind versions 8.1.1 or 4.9.5 and up. These new options are used to enhance security and the overall efficiency of the name server. Some of these options include

The other sections in the file identify zone information. The format of each of these sections is exactly the same. Some of the zone sections contain specific options as mentioned above. The basic options for the zone file are listed below:

The next line defines the responsibility of the name server for the zone. A name server can be authoritative as a master, or non-authoritative as a slave. The hint type is used to describe a zone that is used to resolve queries using recursive methods. That is, if the name server needs to query a domain whose authoritative names server is unknown, it will request information form the root servers listed in the hint file. The hints file lists all of the root servers for the top level domain names in the world.

Once Bind-8.1.1 has been successfully compiled as described in Chapter 4, it is necessary to create the necessary files to define the zones. The configuration for a host that will not be a primary name server for any zone will be considerably less complex. For any given non-authoritative host, a caching only name server should be configured. The caching only name server cannot answer queries from any other nodes, it simply queries for its own information and caches it for future use.

A name server that will be authoritative for a zone must be configured with all of the resource files that were previously mentioned. After creating a caching only name server, one can just add the appropriate zone files to upgrade the server to an authoritative server. The next section describes how to set-up a caching only name server. The following sections describe how to upgrade this server into an authoritative name server.

The first line lists the domains that the name server should search in first for information about the query. The line specifies the server to look for the host name in the brestv6.enst-bretagne.fr domain and then in the enst-bretagne.fr. If the hostname is not found on either domain an error to the request is returned, and the user will have to specify the correct domain for the name server. It would be impossible for the name server to guess which domain a host name belongs to if the host name does not belong to any of the listed domains in the search line.

The name server line explicitly defines the name server that this caching only server will query for information. At this point in the installation process, there probably isn't an IPv6 DNS available for queries. The next section will detail its configuration, for now just use any available name server that will accept queries from your machine.

The last step is to start the named daemon. Named can be reloaded or restarted depending on what files were adjusted. It is best to restart named if it isn't already running, this will ensure that all of the files are reread properly. To check if named is already running use the 'ps' command by typing:

The command will output all currently running applications, look for a line that identifies a PID for the named daemon, such as:

If such a line exists, then it will be necessary to restart named using the 'NDC' command:

If NO such line exists to indicate that name is already running, then start named from scratch:

Once named is running, it is time to test the name server using the 'nslookup' program. Type:

If nslookup comes up correctly, try entering a query for a local machine:

venus is a machine that is in the same domain as the caching only name server. As I mentioned previously, the search line instructs the resolver which domains to search for a query in. A query for a machine in the enst-bretagne.fr domain results in this:

Try doing two consecutive queries for the same name, and note that the second answer will be identified as non-authoritative. Once a name has been cached, any consecutive requests will not require the resolver to send a repetitive request. The cache is only temporary, so a request at a much later time may require another query.

The next two sections listed refer to the same zone, but these are reverse mapping zone files. The middle section is the IPv4 reverse mapping zone, and the last section is the IPv6 reverse mapping zone. For reverse mapping zone files, the IP address is listed in reverse order inside of " ".

After the email address is a group of information that belongs to the SOA resource record, thus it is grouped in parenthesis. The first line is the version of the current file, the version format lists the year-the month-the day-the version for the day. This format is easy to read and use, it gives complete information as to when the file was changed and allows secondary servers to update whenever the file is changed. The other lines include other information for the secondary servers to configure their update schedules.

Once the forward mapping zone file has been created it is necessary to create the reverse mapping file It will be necessary to develop two separate reverse mapping files, one for IPv4 and one for IPV6

The format of this file isn't any different than the previous files, the last 20 bytes of the IPv6 address is listed. The necessary file have been created and it is time to test the name server. Restart the name server and try looking up a host from the local zone.

The first query for venus searches for the default A resource record. For the venus IPv6 AAAA resource record, nslookup is instructed to look for only AAAA records by using the nslookup command 'set'. After the IPv6 address for venus is listed, the IPv6 and IPv4 address of the name server is also listed.

Try looking up a machine outside of the local zone:

Several IPv4 addresses are listed for this machine that happens to be a large server for one of the largest universities in the United States, Texas A&M University. A search for an entire domain can be made with the ls command:

This would actually result in the entire /var/named/brestv6.zone file being listed. Note that origin line marks the domain, and that the look-up only listed the hostname for the name server on the first line.

IPv4 reverse look-up uses A records as well, try a query:

IPv6 reverse look-ups should function by setting the query to AAAA. Unfortunately, the reverse look-up is not working properly yet.

The nslookup program provides many useful functions. By typing help at the nslookup prompt, one can find other useful commands.

The nslookup commands are useful for obtaining information about domains and general network administration.