The DNS is the system which, in its primary function, converts Internet domain names that you type into URL bars, such as www.netscionline.com, into numeric addresses such as 220.127.116.11 or even an IPv6 address. In a sense, the DNS system is the phone book of the Internet.
The DNS system is made up a series of levels, the highest of which includes a hierarchy of “authoritative name servers”, each level containing different pieces of information. At the top of that food chain are the root servers. Next in line are the DNS zone servers (.com, .net, .se, etc.). After that come the resolvers (of which there can be multiple levels). These can exist at service providers and major organizations. Then at the bottom of the system are the actual servers themselves - they can be web servers, mail exchange servers, etc.
The method is to read the URL from right to left, so for a URL like www.netscionline.com, the process is to begin with .com, then move to the left to ‘netscionline’, then www.
A quick example: To translate www.netnetscionline.com, a resolver – the name server a user queries directly, usually configured in the user’s system as the primary and secondary DNS Servers – first has to figure out where .com is, then netscionline.com, and finally www.netscionline.com (as mentioned, essentially working from right to left). The authoritative name servers that the resolvers use to find top level domains (like .com) are the root name servers.
The resolver is usually a DNS server that is close to you as a user. It does not contain a complete copy of the root server database, instead it keeps a cache of commonly or recently used lookups. If your desired web URL is not in the local resolver, it knows where to find the next level, and so on until perhaps a query is actually passed to the nearest root server itself, though this rarely occurs.
The answer is history, protocols and mathematics. When the DNS system was designed, the size limit of DNS responses using the User Datagram Protocol (UDP) was set to 512 bytes (look at Section 2.3.4 of RFC 1035). Starting with a packet size requirement of 576 bytes, if you work backwards, you have a 20 byte IPv4 header followed by an 8-byte UDP header, then the UDP payload could be up to 548 octets long (576-20-8=548). If you also allow for up to 40 bytes of IP options, then in order to ensure UDP packet acceptance under all circumstances the maximal UDP payload size should be 508 octets. The DNS use of a maximum payload of 512 bytes is not completely inconsistent with the math, but it is off by 4 bytes.
This 512-byte size limit of DNS packets still holds today, in that a query is supposed to be answered by a response with a DNS payload no greater than 512 octets long. If the actual response would be greater than 512 octets, then the DNS server is supposed to truncate the response to fit within 512 octets, and mark this partial response as truncated.
Now let’s say you are getting the root server information to begin your database (called a DNS priming query), you will receive a DNS response packet no longer that 512 bytes of payload. Therefore only 13 IPv4 addresses and server names will fit!
What about IPv6, you may be thinking. The answer there is that you will get a partial set of answers with no indication of what is missing. For example you might get a fist packet of 508 bytes that contains IPv6 addresses for A through J, with the remainder IPv4 addresses arriving in a second packet. Some root servers will answer differently. If you wanted everything, you need a 1097 byte payload (see RFC 6891).
Where are these servers?
First, there are not just 13. That used to be the case, but thanks to Anycast technology, we now have hundreds of servers sharing the 13 addresses. You can view these servers at root-servers.org:
On that same web page (at the bottom), you can select any one of the 13 organizations and view the details of their servers:
(Note 2: another DNS tool is called 'nslookup', which also runs on the MAC but has been deprecated on Linux, look towards the end of this article for information on nslookup)
We see the 13 root servers being shown.
Let’s dissect the output from the dig command. The format of a dig response has five sections:
The HEADER contains summary and status information, which we look at in more detail later.
The next four sections contain information in standard Resource Record (RR) format as they may appear in a zone file.
The QUESTION SECTION reflects the question or query received by the responding server. In the above case, the dig command was interpreted to be “get me the NS RRs for the root”.
The ANSWER SECTION may be empty if our question was not answered or may contain one or more RRs, which are the answer to our query. In the example above, it contains the NS RRs for the root servers (a.root-servers.net to m.root-servers.net). Note especially the infamous dot on the left hand side of each result line in this section, which is the short form for the root.
The AUTHORITY SECTION normally contains one or more NS RRs for servers that are authoritative for the domain in question. In the above case, it is not present simply because the ANSWER SECTION already contains this information.
The ADDITIONAL SECTION contains any information the responding server thinks may be useful and has available. In this example, and in most cases, it contains the A (Address) RRs of the authoritative name servers that our local name server has used.
The really interesting stuff is in the HEADER. The first thing to check is the status. In this case, NOERR means the command was successful (see the Dig Header Values sidebar for a complete list). The flags in this case are qr, indicating we received a query response that seems pretty reasonable; rd, indicating our dig message requested recursive services; and ra, signifying that this server supports recursive service (again, see the Dig Header Values sidebar for a complete list of possible flags). The HEADER also contains the id, which uniquely identifies this request/response pair and finally summarizes how many RRs we have in each section.
Here is a list of value references (keep in mind that Wireshark will annotate all of these items):
id: the 16-bit message ID supplied by the requester (the questioner) and reflected back unchanged by the responder (answerer). Identifies the transaction. Range 0 to 65535.
Flags may be one or more of the following values:
AA (Authoritative Answer): set if the response was received from a zone master or slave.
TC: (TrunCation): length greater than permitted, set on all truncated messages except the last one.
RD (Recursion Desired): set in a query and copied into the response if recursion is supported.
RA (Recursion Available): valid in a response and, if set, denotes recursive query support is available.
AD (Authenticated Data), DNSSEC only: indicates that the data was reliably authenticated.
CD (Checking Disabled), DNSSEC only: disables checking at the receiving server.
Status field response code:
0 = NOERR: no error.
1 = FORMERR: format error—the server was unable to interpret the query.
2 = SERVFAIL: name server problem or lack of information. Often also returned with the same meaning as REFUSED.
3= NXDOMAIN Name does not exist: meaningful only from an authoritative name server.
4 = NOTIMPL: not implemented.
5 = REFUSED: typically for policy reasons, for example, a zone transfer request.
The last few lines of the dig response yield useful performance information. The SERVER line particularly confirms the address and name of the server from which the results were obtained.
Let’s continue the journey by trying one of the root servers:
Note in the header the ra flag is not set, meaning recursion is not available—normal in the root and TLD servers. Further, the aa flag is not set, which means this is not an authoritative response. At first, this may seem strange; this is, after all, a root server. The root is the parent of .com (the next name in the hierarchy), but a parent's NS RR's (the point of delegation) are never authoritative; only the child can give an authoritative response for its NS RR's. This has important implications as we will see later. In summary, we have no answer (ANSWER 0) and no error (status NOERR), but there are AUTHORITY (13) entries. This identifies the response as a referral. The root cannot supply the answer but has helpfully referred us to the next level in the hierarchy—in this case, the .com gTLD servers, whose names are given in the AUTHORITY SECTION and some IP addresses in the ADDITIONAL SECTION, including an IPv6 address, which is common.
I am following the b. Server branch of the DNS system, so let’s keep going.