|
Conferences and Events | Online Resources | Programs | Security | Services | Shared Network | Technical Support | Training Home » Technical Support » Domain Name Services (DNS) » DNS Overview, Terminology, Tools and Troubleshooting |
|||||||||||||||||
DNS Overview, Terminology, Tools and TroubleshootingBasic Construction and HierarchyThe Domain Name SystemThe Domain Name System (DNS) is a distributed hierarchical database. Its structure is akin to a computer's filing system of folders and subfolders. Domain name structure can be expressed as a hierarchical tree (Liu, 11-16). Very simply, its purpose is to translate IP numbers that are difficult to remember and accurately type into easily remembered alphanumeric "names." Parent and ChildThe terms "parent" and "child" refer to the adjacent relationships in the tree. The "parent" is to the right of the "child." Domain Name ServersThe programs that store information about domain name space are called name servers. Name servers usually have complete information about some part of the domain name space (a zone), which is loaded from its own internal files or from another name server. The name server has authority for that zone. Name servers can be authoritative for multiple zones (Liu, 21). The standard application for DNS has been BIND (an acronym for Berkeley Internet Name Domain) on UNIX. Most production Internet name servers are based on BIND running on some form of UNIX. There are ports of BIND to other platforms and other similar applications that use various interfaces and proprietary alterations. Microsoft DNS is now heavily used, due to Windows 2003 Active Directory dependence on DNS. Essentially, no matter what the server, the structure of the distributed system remains standardized, so information can be disseminated across the Internet. This document explores the basics of this standardized system. Discussion of BIND or any other DNS server or configurations of such servers are outside its scope. DelegationThe Domain Name System is distributed throughout the Internet in a way that decentralizes administration. The hierarchical relationships are made through a process called delegation. Pointers reside in name servers and point the way to the location of the domain or host information. Queries are directed up the hierarchical tree until the information is found. Primary and Secondary ServersA primary master name server for a zone reads the data for the zone from itself. A secondary master server, also known as a slave, gets its zone data from another name server that is authoritative for the zone (its master server). A secondary can get zone data from either a primary master or another secondary master server. Since servers can serve multiple zones, a server can be master for some of those zones and slave for others (Liu, 24). Domain Name Standards and HierarchyA domain name is a unique designator on the Internet made up of alphanumeric characters and symbols separated by dots, for example, www.more.net. The individual words or characters between the dots are called labels. The label furthest right represents the top-level domain. The second most right represents the second-level domain. Rules have been established for formatting domain names:
Root ZoneThe root zone is the highest level of the domain hierarchy. It is called the ancestor of all zones. It is written as "." and has no labels (DNS Glossary). Currently 13 servers are authoritative for the root zone. They are named a.root-servers.net through m.root-servers.net. These servers are distributed throughout the world and are housed and administered by various cooperating organizations (DNS Glossary). A list of root servers, their operators and IP addresses are available at root-servers.org. The limit of 13 servers is a technical limitation. UDP-based DNS messages can be up to 512 bytes long and only 13 name server (NS) records and their corresponding A records will fit into a DNS message that size (Liu, "Why are there only 13 root name servers?"). Distributed name servers running BIND specifically choose to query a root server based on "round-trip time," a measure of how long it takes the remote name server to respond to a query. If a server does not answer, the querying server will not repeatedly query the same root server; it will move on to another root server (Liu, 30). Not all root name servers act in the same way. Some are authoritative for particular top-level domains; others delegate to the top-level domain servers. Top-Level Domains - TLDsA top-level domain is the next level of hierarchy from the root zone. The Internet Corporation for Assigned Names and Numbers (ICANN), a non-profit corporation, ultimately determines how top-level domains are administered (see <http://www.icann.org> for more information). There are two types of top-level domains, generic and country code, plus a special top-level domain (.arpa) for Internet infrastructure. Generic TLDs (GTLDs) are globally used and classed by function or association. Country code TLDs (ccTLD) are used as individual countries see fit. Generic Top-Level Domains - GTLDsThe GTLDs currently in use include aero, .biz, .com, .coop, .edu, .gov, .info, .int, .mil, .museum, .name, .net, .org and .pro. In the latter half of 2005, more GTLDs were approved, such as .cat, .jobs, .mobi and .travel. More applications for new GTLDs are pending approval. For more information on the purpose and sponsors/operators for the GTLD domains, see:
There is a delegated sponsor/operator for each GTLD. Most GTLDs have a system of registration delegated to a number of companies which act as registrars for the domain. These companies are accredited through ICANN and then approved by the sponsor/operator. The domains restricted to a single registrar are .gov, .edu, .museum and .int. The Department of Defense controls .mil, which is exclusively restricted to the U.S. military. (ICANN) As an educational network, MOREnet would be prohibited from carrying the .biz and .com GTLDs MOREnet customers use the .edu domain extensively. Educause administers this domain. Currently, there is no cost for registration and the registrations to this domain do not expire. Registration is limited to U.S. regionally accredited, degree-granting institutions of higher education. In the past, two-year community colleges were not permitted to hold an .edu name, but this limitation has changed in the last two years. More information about the application process and the criteria for acceptance is available at <http://www.educause.edu/edudomain/>. An institution cannot hold two .edu names, except during times of transition between two names. The transition period can last up to six months. There are no other limitations to institutions holding .edu domains; they can have .cc.mo.us, .org or any other name they are able to carry by other policies. Country Code Top-Level Domains - ccTLDsRegistrations of domain names within two-letter country-code top-level domains (ccTLDs) such as .au, .ca, .jp and .uk are administered by country-code managers. A complete list of ccTLDs is available through IANA at <http://www.iana.org/cctld/cctld-whois.htm>. The .us ccTLD currently is administered by NeuStar, Inc. < http://www.neustar.us/>. All .us registration is currently handled by the registrars listed on the NueStar website. Any entity falling under one of the following conditions should be able to register currently non-restricted areas of .us:
Registration of new .mo.us domains is unclear. At this time, all locality-based name registrations are sent to support.us@neustar.us and will either be handled directly or forwarded to an appropriate delegation manager. The US Domain template for the request is available at <http://www.neustar.us/delegated_managers/US_Domain_Template_v2.0.txt>. MOREnet's Role in the .mo.us DomainMOREnet is authoritative for the following .mo.us zones, as of Jan. 30, 2006: cc.mo.us MOREnet will provide registration in these domains without charge. MOREnet handles requests for these domains whether they are from MOREnet members not. For more information about this MOREnet service, see Domain Name System (DNS). MOREnet does not provide registration services for other domains (.org, .com, .net, .edu, etc.) MOREnet's Process for Domain Name RegistrationDomain name registration information is available on the Domain Name System (DNS) page . A member must register an .org or .net independently through another registrar. If MOREnet carries the zone, MOREnet should be listed as the technical contact. Contact MOREnet for information. All the information for the organization and the organization's name holders must be complete and publicly viewable. This information must include valid e-mail addresses. The information should be cleared by MOREnet's domain name administrator(s) in the Core Network group, before the name server names and IPs are supplied. If the proper conditions are not met, a service request can be denied. For more information about this service, see Domain Name System (DNS).
If a secondary authoritative name server is needed only, argus.more.net should be used. Schools and libraries can request .org addresses from MOREnet. The domains must be approved. Schools and libraries will be billed for the yearly registration cost. Using WHOISWHOIS records contain the registrant, domain, administrative contact, billing contact, technical contact, record creation, expiration and update dates and name servers which resolve the name. WHOIS records must be updated when authoritative name servers change or the domain will not resolve correctly from root. For additional information about the WHOIS protocol, see: A good place to start a WHOIS query: A query also can be started with argus.more.net. One method is to use the WHOIS function of WS Ping Pro and query domain information from argus.more.net. MOREnet registers WHOIS information for new domains as part of the registration process. The .arpa DomainThe .arpa (Address and Routing Parameter Area) domain is administered by IANA. It is designated exclusively for Internet-infrastructure purposes. For more information about the .arpa domain, see RFC 3172, "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain". The special second level domain .in-addr.arpa is exclusively for host address to host name mapping. In addition to the .in-addr.arpa suffix, up to four labels are used, which represent each octet of an IP Address. The labels are submitted in reverse to the octet progression found in the IP Address, starting with the last octet. Example: 150.199.1.10 would be expressed 10.1.199.150.in-addr.arpa. Specifically, this syntax would be used when attempting an inverse or address to name, query (Albitz & Liu, 31-33). Query to PTR records (discussed in Types of DNS Records below) will also supply reverse address to name data.
DNS Terminology and Types of DNS RecordsFamiliarity with record types and syntax is helpful when trying to communicate requests or troubleshoot problems. A single character error can cause a domain or host record to malfunction. DNS data is entered in multiple files. While lookups are case-insensitive, case in the files is preserved. Name to address mapping is sometimes called forward mapping. Important Terms
Types of RecordsNote: The following evaluations show responses given by the tools nslookup and DiG. These tools are covered thoroughly in the next section about tools. SOA Record - Start of Authority RecordThe SOA is the first record in every properly configured zone. The SOA record tells the server to be authoritative for the zone. A SOA record is required in each forward and reverse file for the domain (DNS Glossary). There can be only one SOA record in each zone data file. Retrieving the SOA file by the utility DiG returns the file in a format close to the original file. The syntax for doing an SOA query using DiG from a UNIX command line is: Evaluation ExampleThe output for more.net, broken down:
This confirms the terms of the inquiry
This is the first part of a reply, called the header. The flag bits tell more about the response. "Qr" indicates the message was a response and will always be present. "Aa" indicates the response was authoritative. "Rd" indicates the recursion bit was set in the query and "ra" indicates that recursion is available from the remote name server responding (Albitz & Liu, 400).
This header section simply keeps count of the information returned in the query.
This query section returns what was asked for: an SOA record, type IN = Internet, for more.net
Notice the domain name (in this case more.net.) MUST have a period at the end of it, to account for the root domain or the record will not answer correctly.
The serial number is used by a secondary server to determine if it requires a zone transfer from the primary server. If the secondary server's number is lower, then the secondary server knows that its records are out of date. In this example, the convention used can identify when the last change was made, but other administrators may use different conventions. The first 8 digits denote YYYYMMDD. The other two numbers are the number of changes made by day or as a whole (Albitz & Liu, 89).
Refresh, retry and expire intervals deal directly with the primary-secondary server relationship. The TTL interval deals with the cached records on other servers.
The authority section shows the servers that are authoritative for the domain more.net.
This is additional information about the servers in the authority section. In this case, the resolution of the names of these name servers is indicated by the "A" in the record.
This is the standard wrap-up section, giving confirming information of the information retrieval. Information from other tools can look different. The information below is the same information pulled with a set type=soa retrieval in nslookup:
NS Records - Name Server RecordA name server record is added for each name server authoritative for a zone. The name server records are always entered with a name, rather than an IP (Albitz & Liu, 61). The information from a DiG query on a NS record request will look like the information that is generated in the SOA record, under authority and additional question:
nslookup query generates this data from a set type=ns:
A Record - Address RecordAn address record maps a name to an address. A single name can be mapped to multiple addresses. A DiG on vortex.more.net gives the reply:
A DiG on cnn.com gives the reply:
The different records are usually doled out in a round robin order. An nslookup on cnn.com gives the following reply:
A non-authoritative answer came back because this record currently is cached in our name server. CNAME Record - Canonical Name RecordA CNAME record maps an alias name of a canonical name (which is defined in the Address record). The alias gains all properties of the original A record, including IP addresses and mail routes (DNS Glossary). The record includes two names and never an IP address. Pointing CNAME records to other CNAME records is not advised, because it risks creating a CNAME loop and slows resolutions (Albitz & Liu, 499). A DiG, syntaxed as dig www.more.net CNAME will have the CNAME record only:
A DiG, syntaxed as dig www.more.net will return both the cname record and the associated A record:
nslookup request will show:
Use of multiple CNAME records pointing to different hosts, as in this example:
is a violation and cannot be used. Some name server software revisions (specifically BIND 8 and previous versions) may allow this to be entered and could theoretically be the source of problems with inexperienced administrators for delegated domains (Albitz & Liu, 300). While finding the A record for a CNAME record is straightforward and simple, finding all the CNAME records associating with an A record is not directly obtained. The ways of doing so require permission to use the UNIX tool grep inside the /etc/hosts file or transfer and inspect zone files directly. Even if zone files are inspected, there could be aliases in a different zone (Albitz & Liu, 301-302). MX Record - Mail Exchange RecordAn MX record creates a mail route for a domain name. A domain name can have multiple mail routes, each assigned a priority number. The mail route with the lowest number identifies the server responsible for the domain. Other mail servers listed will be used as backups (DNS Glossary). Numbering can start at 0. This record includes host names, which will be resolved through A records. Note that if a domain only has the MX records assigned to it and an attempt is made to ping that domain, the ping will fail. This is no indicator that there is anything amiss with the mail server. The MX record points to an A record, which should be reachable by ping or probe (if allowed within the network). Note that an MX record must reference an A record and not a CNAME (alias) (Liu, "Can an MX record point to an alias?"). Nearly all mailers will look up A records for a domain name in a mail destination if no MX records exist (Liu, "Can I use an A record instead of an MX record?"). A DiG, syntaxed dig more.net mx, reveals:
nslookup, given a set type=mx modifier and then queried for more.net reveals:
In these examples, nook.more.net and cranny.more.net will be used first and if they both are not available, osage.coreserv, current.coreserv or meramec.coreserv will be used. PTR Record - Pointer Record or Reverse RecordA PTR record associates an IP address with a canonical name. PTR records should point to a name that can be resolved back to the IP address. The name of the pointer record is not the IP address itself, but is the IP address's four IP octets in reverse order followed by IN-ADDR.ARPA. Example: 192.168.0.1 becomes 1.0.168.192.IN-ADDR.ARPA (DNS Glossary). In this manner, the IP in a PTR record is not considered a number or an IP, rather it is a text field. A DiG to dig 10.1.199.150.in-addr.arpa ptr shows:
During an nslookup query, a set type=ptr will be necessary before the query string 10.1.199.150.in-addr.arpa :
Other RecordsOther types of information records, such as HINFO, LOC, RP and TXT, are not notable for troubleshooting purposes. The standards A6 and DNAME (DNS Resource Record) serve the Ipv6 architecture. For a full list of DNS resource records in the IN class, see <http://www.dns.net/dnsrd/rr.html>.
DNS Troubleshooting ToolsnslookupOne tool to query Internet domain name servers is nslookup. It is available from the command line of UNIX based systems (when the proper permissions to run it are implemented) and the command line of Windows machines. In Windows 2000 and Windows XP, the executable application is located in C:\\WINNT\system32. It can be launched from this application file or from the generic command line. nslookup can be run either in non-interactive mode or interactive mode. Extensive information on uses of nslookup can be found in Albitz and Liu, 375-398. Non-interactive mode is used when the name or IP of the host to be looked up is given as the first argument after the initiating nslookup command. The optional second argument specifies the host name or Internet address of a name server. If there is no second argument, the first name server in the configuration of the operating system of the querying computer will be used. For example, typing: The reply is received: A non-interactive nslookup query using IP number: $ nslookup 207.160.133.134 argus.more.net The program will provided the requested information and exit automatically. nslookup's interactive mode can be invoked by typing nslookup and pressing the Enter or Return key. The interactive session will start with a session to the first name server in the computer's configuration. A default server will be displayed, with IP address and prompt. If the first name server in the configuration did not respond, the request will attempt to pass to the secondary server, which will respond in the manner above. In this nslookup session, there will be no more queries to the server which has been timed out, unless the server setting is switched to that server manually during the query process. To interrupt a command at any time, press Ctrl+C. Type exit and press Enter to exit nslookup. Interactive Commands A command list is available inside an nslookup session by typing help and pressing Enter. A full manual listing is available on UNIX-based servers by exiting the nslookup session and typing man nslookup and pressing Enter. Often Used Commands Commands in solid italics are typed as shown; italics are supplied as indicated. hostname - Looks up information for hostname using the current default server. server domain - Changes the default server to domain. Uses the current default server to resolve. If authoritative answer cannot be found, the names of servers that might have the answer are returned.
ls [option] domain [> filename] - Lists the information available for domain, optionally creating or appending to filename. If no option is given, the output contains host names and their Internet addresses. The option argument can be one of the following:
Error Messages If lookup was not successful, one of these common error messages may display: Timed out - The server didn't respond to a request after a certain amount of time and a certain number of retries. DiG - Domain Information GroperDiG is a UNIX shell command, which may installed on a UNIX server. Many administrators (including MOREnet's) use DiG rather than nslookup, because it is more flexible and shows results in a manner closer to the actual syntax of the record itself. It will show serial numbers in records where nslookup will not (which is important in the pick up of new information by secondary/slave servers) and the layout may encourage the discovery of typographical errors in DNS records. It allows use of arguments in varying order (unlike nslookup). DiG shows a complete DNS response message as output, with sections (header, question, answer, authority and additional) clearly indicated. Although technically it has two modes, simple interactive and batch mode, the interactive is not session based like nslookup. The simple query is the most often used mode, which provides the answer and returns to the shell prompt without additional commands. An evaluation of a basic DiG response is available in this document, under Types of DNS Records, SOA Record. Interactive Commands Type the command man dig at a UNIX shell prompt to access a manual. More information on the use of DiG can be found in Albitz & Liu, pages 398-402. Command Syntax The simple syntax: server - Server being queried. May be either a domain name or an IP address. If this optional field is omitted, dig will attempt to use the default name server for your machine. @ does not need to be used when server is in the second position after the command dig. domain - The domain name for which you are requesting information. To use IP in this position, use the switch -x, ex.: dig argus.more.net -x 150.199.101.1 query-type is the type of information (DNS query type) that you are requesting. If omitted, the default is ``a'' (T_A = address). The standard specified types are recognized: a, any, cname, mx, na, soa. Internet ToolsSquish DNS Checker - Will provide an analysis of all possible answers received from the DNS tree from root servers and will provide percentage probability of the answers received. Will not consider local cached information. Very handy for another point of view for a problem. Online, field formatted DiG query - hosted by Men and Mice Pages of DNS tools for domains, IP addresses and host names DNS Reporter and Mail Delivery Report (MX Record Test) Root Server Status WHOIS search from InterNIC
TroubleshootingTroubleshooting DNS-specific problems requires use of techniques that generate definitive errors that point to a problem with DNS records and/or DNS servers. Determining whether the problem is DNS-related is the first step. After that, testing can reveal an abnormality or error, which will provide clues to what is wrong. The process can be broken down into three steps:
Is It a DNS-Related Problem at All?An initial diagnosis of DNS involvement made by a user on a single host computer can easily be misidentified. Errors generated by a browser, which can include "host not found" and other related messages, can mislead a user to think that host resolution is a problem, while the actual problem exists with the connection. It is critical to rule out any connection problems before delving more deeply into DNS-related testing. Listening carefully to the initial classification of the problem is paramount. Ask defining questions to determine why they would conclude they have a DNS-related problem. Determine if the problems are seen on multiple computers or, conversely, if some computers on the LAN/WAN are not experiencing the problem. Begin testing on a command line in the system, if possible, using tools like nslookup, traceroute and ping to verify a computer's network availability and ability to connect to the Internet gateway. Verify the TCP/IP-based settings, especially the name servers in the active configuration. Windows machines will return configuration with the use of the command ipconfig /all or, for older machines, winipcfg at the command line. As the Windows 2000 architecture proliferates, and as the use of firewalls and NAT implementations become the norm rather than the exception, more internal DNS servers are providing service to the inside of the network directly. Watch for the use of private IPs in the configuration and clarify the functionality and activity of local name servers. Remember, an interactive nslookup session, when used with the default name server, will attempt to contact the first name server in the TCP/IP configuration of the computer. If the initial attempt to reach a legitimate name server times out, it could indicate a constant or intermittent problem with getting to a particular name server. This result could point to a connection problem inside the network or the malfunction of an internal name server. The addition of firewalls or other technologies blocking ping can cause more complications. Clarify the passage of ping through the network before relying on the lack of ping results as an identifying characteristic. A "best bet" is to find out exactly what level of connectivity a user currently is experiencing on a machine that is having the problems and identify the name server being used. Duplicate that action on the troubleshooter's computer. Watch for differences. Initial questions that may be helpful:
It is important to remember:
At the end of this phase, you should be reasonably sure that the nature of the problem is either connection or security related (and have properly switched troubleshooting tactics) or should be reasonably convinced that these areas are working and DNS is the actual cause. Determining the Exact Nature of the DNS ProblemTrying to determine the exact nature of the problem is a case of detective work. Try to locate an anomaly or uncover a distinct error. Good record keeping in the process can help avoid doing queries multiple times. The test can be boiled down to two elements:
Try to determine differences, such as testing MOREnet vs. non-MOREnet results, different third party results and inside and outside a firewall. Use a tool like Squish's DNS Checker (http://www.squish.net/dnscheck/) to get an outside, comparative evaluation of a specific domain problem. Note that DNS uses both UDP and TCP protocols on port 53 for traffic. If all DNS resolution has stopped and either a new firewall has been installed or a firewall has been altered, have the customer double-check that the traffic has been allowed. UDP is almost always used for regular query/response traffic. TCP is used mainly for zone transfers, taking to some debugging tools and regular queries if UDP responses get truncated (that is, if all the records won't fit). Troubleshooting ExampleCustomer says that entire network cannot get to www.blogga.com. They must get to this website for student updates. Facts uncovered: They are experiencing no other abnormalities
to any other domain or IP. All their services are working normally.
Testing uncovered:
I can also not connect to www.blogga.com. I am using University servers. Fixing the ProblemMOREnet can fix only what is within its ability to fix. Be clear about what needs to be added or changed. A rare, but possible problem that MOREnet can fix may masquerade as someone else's problem. A clue to this problem may be given by the customer, specifically in the observation that a number of other third party services can successfully resolve the address, but MOREnet servers only are showing no resolution. This problem could be caused by stranded incorrect records to a domain that MOREnet resolved as a secondary. If the domain owner moved the service and other name servers are now resolving the domain and MOREnet has not been informed of the change, MOREnet's name servers may still be expecting zone transfer from a server that no longer holds the records. A Squish evaluation may show this stranded relationship. Confirm your findings with MOREnet's DNS expert in the Network Core group. Adjustments to firewalls and proxies can include opening ports for queries and zone transfers. Host file entries may need to be added or modified when dealing with access issues from inside a NAT network.
Works CitedAlbitz, Paul & Liu, Cricket. DNS and BIND. Sebastopol: O'Reilly & Associates, Inc., 2001. Cherenson, Andrew. "nslookup manual page." Linux 'Man' Pages. 21 July 2003. ".edu Frequently Asked Questions." Educause. 3 June 2003 <http://www.educause.edu/edudomain/faq.asp>. Hotz, Steve. "The dig Manual Page." The Unix Shell Command Manual Pages. 21 July 2003 <http://www.stopspam.org/usenet/mmf/man/dig.html>. "Top-Level Domains (gTLDs)." 1 March 2003. ICANN (The Internet Corporation for Assigned Names and Numbers). (2 June 2003) <http://www.icann.org/tlds/>. Liu, Cricket. "Can an MX record point to an alias?." Men & Mice. 9 May 2002 <http://www.menandmice.com/knowledgehub/dnsqa/30>. Liu, Cricket. "Can I use an A record instead of an MX record?." Men & Mice. 3 June 2002 <http://www.menandmice.com/knowledgehub/dnsqa/37>. Liu, Cricket. "Why are there only 13 root name servers?." Men & Mice. 2 Jan. 2002 <http://www.menandmice.com/knowledgehub/dnsqa/15>. "The Men & Mice's DNS Glossary." Men & Mice. 9 July. 2003 <http://www.menandmice.com/knowledgehub/dnsglossary>. ".US Domain Registry Web Address Registration FAQ." NeuStar, Inc. 4 June 2003 <http://www.neustar.us/faqs/index.html>. "usTLD Undeligated Name Policy (Interim)." NeuStar, Inc. 4 June, 2003 <http://www.nic.us/policies/docs/undelegated_name_policy_interim.pdf>. ResourcesBooksAlbits, Paul and Cricket Liu. DNS & BIND, 4th ed. Cambridge, MA: O'Reilly Press, 2001. Liu, Cricket. DNS & BIND Cookbook. Cambridge, MA: O'Reilly Press, 2002. Websites"DNS Q&A Corner." Men & Mice. "The Men & Mice's DNS Glossary." Men & Mice. Identification of BIND log messages - good for specific errors
generated by name servers. More Explanations on How the DNS System Works
|
|||||||||||||||||
|
Copyright © 2002-2006 MOREnet. All rights reserved. Reviewed September 21,
2006.
Contact strategic-tech@more.net. DMCA and other copyright information. Site Information: Copyright, accessibility, privacy and other information about this site. PageMinder: Receive an e-mail notice when this page updates.
|