Domain Name Services
The Domain Name System (DNS) converts the name of a Web site (www.oakton.edu) to an IP address (192.234.16.8). This is a critical function as the IP address of a Website, not the Website's name, is used in routing traffic over the Internet.
A DNS name is made up of a host name, domain name and organization type. For example: www.oakton.edu - www is the host name, oakton is the domain name, edu is the organization type. A domain may also have a subdomain; a name in front of the domain name. However, the host name is always first and the organization type is always last in a DNS name. Sometimes the hostname is implied; if left off, it points to a default hostname for the domain (see DNS server setup below).
DNS Queries - Recursive and Iterative
With a recursive name query, the DNS client requires that the DNS server respond to the client with either the requested resource record or an error message stating that the record or domain name does not exist. If a DNS server does not have the requested information (cached locally) when it receives a recursive query, it queries other servers until it gets the information, or until the name query fails. The DNS server cannot just refer the DNS client to a different DNS server. Recursive name queries are generally made by a DNS client to a DNS server, or by a DNS server that is configured to pass unresolved name queries to another DNS server configured to use a forwarder.
An iterative name query is one in which a DNS client allows the DNS server to return the best answer it can give based on its cache or zone data. If the queried DNS server does not have an exact match for the queried name, the best possible information it can return is a referral (that is, a pointer to a DNS server authoritative for a lower level of the domain namespace). The DNS client can then query the DNS server for which it obtained a referral. It continues this process until it locates a DNS server that is authoritative for the queried name, or until an error or time-out condition is met. This process is sometimes referred to as "walking the tree," and this type of query is typically initiated by a DNS server that attempts to resolve a recursive name query for a DNS client.
The below figure shows an example of iterative and recursive queries. This example assumes that none of the servers have the requested information in their caches.
Iterative and Recursive Queries
In the example, a client somewhere on the Internet needs the IP address of noam.reskit.com. The following events take place:
- The client contacts NameServer1 with a recursive query for noam.reskit.com. The server must now return either the answer or an error message.
- NameServer1 checks its cache and zones for the answer, but does not find it, so it contacts a server authoritative for the Internet (that is, a root server ) with an iterative query for noam.reskit.com.
- The server at the root of the Internet does not know the answer, so it responds with a referral to a server authoritative for the .com domain.
- NameServer1 contacts a server authoritative for the .com domain with an iterative query for noam.reskit.com.
- The server authoritative for the .com domain does not know the exact answer, so it responds with a referral to a server authoritative for the reskit.com domain.
- NameServer1 contacts the server authoritative for the reskit.com domain with an iterative query for noam.reskit.com.
- The server authoritative for the reskit.com domain does know the answer. It responds with the requested IP address.
8. NameServer1 responds to the client query with the IP address for noam.reskit.com.
Note that this example shows a DNS server performing direct queries against a root DNS server. This not usually the way DNS lookups are performed due to the overhead involved. Most local DNS servers will refer to an ISP DNS server with a forwarder statement that will cache a larger number of DNS queries eliminating the above overhead.
There are 13 root authoritative DNS servers (root authoriatative) that all DNS servers eventually queryt. These root servers know all the authoritative DNS servers for all the main domains - .com, .net, and the rest amd keep track of all the authorative DNS servers that Web site systems administrators have assigned for their sub domains. For example, when you register your domain example.com, you are actually inserting a record on the .com DNS servers that point to the authoritative DNS servers you assigned for your domain.
Authoritative servers provide the definitive information for your DNS domain, such as the names of servers and Web sites in it. They are the last word in information related to your domain.
Most servers don't ask authoritative servers for DNS directly, they usually ask a caching DNS server to do it on their behalf. The caching DNS servers then store (or cache), the most frequently requested information to reduce the lookup overhead of subsequent queries. If you want to advertise your Web site www.example.com to the rest of the world, then a regular DNS server is what you require.
Name Resolution
All UNIX services reference name resolution for connecting to other systems. The name service switch file determines which name services a system uses to search for information, and in which order the name services are searched. Most LINUX/UNIX systems use the /etc/nsswitch.conf file as the name service switch file. The nsswitch.conf file is loaded with the contents of a template file during depending on the name service that is selected.
The /etc/nsswitch.conf file includes a list of databases that are sources of information about IP addresses, users, and groups. Data for these can come from a variety of sources. For example, host names and host addresses, are located in the /etc/hosts file, NIS, NIS+, LDAP, or DNS. Each database has zero or more sources; the sources and their lookup order are specified in the /etc/nsswitch.conf file
There is an entry in the /etc/nsswitch.conf file for each database. Some typical examples of these entries are:
There might be a single information source listed, in which case the search terminates if the information is not found. If two or more sources are listed, the first listed source is searched before moving on to the next listed source.
· files Specifies that entries be obtained from a file stored in the client’s /etc/hosts file
· nisplus Specifies that entries be obtained from an NIS+ table. For example, the hosts table.
· nis Specifies that entries be obtained from an NIS map. For example, the hosts map.
· dns Specifies that host information be obtained from DNS.
· ldap Specifies that entries be obtained from the LDAP directory.
· user Specifies that printer information be obtained from the ${HOME}/.printers file
When multiple information sources are specified, it is sometimes necessary to define precisely the circumstances under which each source is searched. When a name service is referenced, the attempt to search this source can return one of the following status codes:
· SUCCESS The requested entry was found in the specified source.
· UNAVAIL The source is not configured on this system and cannot be used. In other words, the NIS or NIS+ processes could not be found or contacted.
· NOTFOUND The source responded with No such entry. In other words, the table, map, or file was accessed, but it did not contain the needed information.
· TRYAGAIN The source is busy. It might respond if tried again. In other words, the name service is running and was contacted but could not service the request at that moment.
For each status code, two actions are possible. When the action is not explicitly specified, the default action is to continue the search using the next specified information source, as follows:
· SUCCESS = return
· UNAVAIL = continue
· NOTFOUND = continue
· TRYAGAIN = continue
Specifically for Domain Name Services (DNS) client or resolver, the DNS client will finally reference /etc/host.conf for how to perform name resolution specifically for DNS.
Local name resolution (/etc/hosts)
If the nsswitch ror host.conf file refers to file as the source for name resolution services, the assumption is there is a local static file on the system containing the name and location of the service. For IP name to address resolution, this file is known as /etc/hosts. The format of /etc/hosts is simple an IP address (one per line), a hostname, a fully qualified hostname (or several hostnames). Windows systems include an hosts file; also a version corresponding to NETBIOS (Windows network) hosts called the lmhosts file.
DNS Clients
A DNS client doesn't store DNS information; it must always refer to a DNS server to get it. However, they may cache DNS responses (Windows 2000 and after, current LINUX releases). /etc/resolv.conf file defines the IP address of the DNS server it should use. DNS clients use the /etc/resolv.conf file to determine both the location of their DNS server and the domains to which they belong. The file generally has two columns; the first contains a keyword, and the second contains the desired values separated by commas.
For a client–only, you shouldn't need to configure any other files than /etc/resolv.conf.
/etc/resolv.conf File
Keyword / ValueNameserver / IP address of your DNS nameserver. There should be only one entry per "nameserver" keyword. If there is more than one nameserver, you'll need to have multiple "nameserver" lines.
Domain / The local domain name to be used by default. If the server is bigboy.example.com, then the entry would just be example.com
Search / If you refer to another server just by its name without the domain added on, DNS on your client will append the server name to each domain in this list and do an DNS lookup on each to get the remote servers' IP address. This is a handy time saving feature to have so that you can refer to servers in the same domain by only their servername without having to specify the domain. The domains in this list must separated by spaces.
A sample /etc/resolv.conf:
nameserver 10.1.1.1
domain oakton.edu
search cis238.oakton.edu
DNS resolution maps a fully qualified domain name (FQDN), such as www.oakton.edu, to an IP address. This is known as a forward lookup. The reverse is also true: a reverse DNS lookup determines the fully qualified domain name associated with an IP address.
If using an unqualified name on a forward lookup, domain name will be appended to it to perform a lookup; if that fails, domain names in the search list will be appeneded in sequence and a lookup performed .
Many different Web sites can map to a single IP address using host headers (see Apache), but the reverse isn't true; an IP address can map to only one FQDN. This means that forward and reverse entries frequently don't match. The reverse DNS entries are usually the responsibility of the ISP hosting your site, so it is quite common for the reverse lookup to resolve to the ISP's domain. This isn't an important factor for most small sites, but some e-commerce and E-Mail applications require matching entries to operate correctly.
There are a number of commands you can use do perform DNS lookups. Linux uses the host, nslookup and dig commands, but Windows uses only nslookup.
host Command
The host command accepts arguments that are either the fully qualified domain name or the IP address of the server when providing results.
To perform a forward lookup, use the syntax: host www.oakton.edu
To perform reverse lookup: host 192.234.16.8
The host command is an archaic DNS lookup under UNIX/LINUX.
nslookup Command
The nslookup command is the most widely used commands for DNS queries.
To perform forward lookup: nslookup www.oakton.edu
To perform a reverse lookup: nslookup 1982.234.16.8
Nslookup can also be entered as a standalone for interactive queries. “?” will give you the options to use in interactive mode.
The nslookup command queries the servers in /etc/resolv.conf for an answer. The server answering is listed in the nslookup response. You can change the default query server with the server command in interactive mode.
The default answer is the A (address) record. You can change the type of record returned using the “set q=” option in interactive mode. For example: set q=MX” will query for mail exchange records for a provided domain name – like oakton.edu. “
nslookup
set q=MX
oakton.edu
exit
“set q=any” will return the most complete information under nslookup for a particular domain.
Dig command
Dig comes standard with all the major Linux distributions, and is useful for verifying and troubleshooting DNS problems. It is not currently provided as part of Windows which uses only nslookup for client DNS queries.
To perform a forward lookup, run dig with your domain name as the parameter: dig www.oakton.edu
To perform a reverse lookup, run dig with th IP addres as the parameter: dig 192.234.16.8
The default forward dig answer is the A (address) record of the domain specified (as with nslookyp), but you can specify other records. The MX or Mail eXchange record tells mail servers how to route the email for the domain. You can examine your MX records using dig like this: dig oakton.edu MX. Note that you ask for oakton.edu, not www.oaktobn.edu, since normally when you send email to someone, you send it to the domain and not to one of the subdomains like www or ftp. That is: , not .