ClientDNS is a utility program designed and intended to give you full access to the DNS packets returned from the requested server. DNS packets are very compact and highly cryptic, and because of that, command line utilities like "NSLookUP" will display incomplete interpreted results. ClientDNS returns all the results on separate tabs.
Internet standards require DNS servers to accept both UDP and TCP requests. TCP is very seldom used however, and some servers do not accept them due to firewall restrictions on port 53. ClientDNS does not support TCP.
Some modern recursive DNS servers use EDNS (Extended Domain Name Service) to support DNSSEC. ClientDNS does not support EDNS.
There are numerous Web pages available that explain the DNS packet structure. What is not very well covered is the use of Compression Pointers, so a brief explanation would seem to be in order. The Header and Question sections are common to the both the outgoing query and the server response (see included image below).
There is a lot of information in the header. First of all, it tells us that this is not an authoritative answer (Authoritative Answer = False). That is because this server does not host this particular domain, and recursion was requested and utilized to find the answer. It also tells us that there were no errors and 1 Question (QDCount=1), 1 Answer (ANCount=1), 2 Nameserver (NSCount=2), and 1 Additional (ARCount=1) records received.
To see how Compression Pointers are used, we will examine the response for an MX record.
The first 12 bytes are for the Header, and the Question occupies the next 16 bytes (variable). Notice that the question has a length byte (0A/10) in front of the Domain Name (yellowhead). This takes us up to where the dot separator would normally exist. There we find the length (03) of the high level domain (com). All questions will end in a NULL character (00). 00 0F is the Question Type (15), and 00 01 is the Question Class (IN). The next Record is the Answer Record, and here we find an unknown character (C0). The top 2 bits of this byte (192) tell us that compression is used, and the next 6 bits and the following byte tell us where to find those compression characters (0C/12). Wait a minute; the question starts at byte 13. That is true, but we are using zero based counters, which corresponds to the Question Name just discussed. The 2 bytes (C0 0C) will return the Record Name, followed by the Record Type (00 0F) and Record Class (00 01). After that comes the suggested TTL in seconds (00 0D 2E C4), the Record Data Length (00 0B), and MX Priority (00 0A). That brings us to the Record Data itself. It starts with a 6 character Name followed by the Compression characters (C0 0C). When combined, it results in "nomail.yellowhead.com".
The last Record is an Additional Record. It starts with a C0 2E. This Compression Pointer points to byte 46, which is the name just recovered above. It is followed by Record Type (00 01), which is an "A" record, and Class (00 01), which is the Internet Class. Following that is the TTL (00 0D 2E C4), the Record Length (00 04), and finally the IP address (60 35 60 32).
Using this technique, you can see how they manage to squeeze 27 root servers into very limited space.
The original version of ClientDNS utilized MS Winsock. Version 2 utilized cSocket2 and supported IPv4 and IPv6 using string data. Version 3 utilizes SimpleSock, which enabled the use of binary information via byte arrays. ClientDNS V3.0 has been tested on Windows Vista and Windows 8.1. IPv6 has not been fully tested because of the lack of a native IPv6 network (tested with Teredo Tunnel).
How to use ClientDNS is demonstrated in the following web page.
http://www.yellowhead.com/DNS_How.htm
It should be noted that you do not have to enter the correct format for PTR requests (ie. 117.178.26.52.in-addr.arpa). You simply enter the IP address (ie. 52.26.178.117), and ClientDNS will reformat it for you. Clicking on any field will display it on the bottom bar, and double clicking will copy it to the clipboard.
J.A> Coutts
Internet standards require DNS servers to accept both UDP and TCP requests. TCP is very seldom used however, and some servers do not accept them due to firewall restrictions on port 53. ClientDNS does not support TCP.
Some modern recursive DNS servers use EDNS (Extended Domain Name Service) to support DNSSEC. ClientDNS does not support EDNS.
There are numerous Web pages available that explain the DNS packet structure. What is not very well covered is the use of Compression Pointers, so a brief explanation would seem to be in order. The Header and Question sections are common to the both the outgoing query and the server response (see included image below).
There is a lot of information in the header. First of all, it tells us that this is not an authoritative answer (Authoritative Answer = False). That is because this server does not host this particular domain, and recursion was requested and utilized to find the answer. It also tells us that there were no errors and 1 Question (QDCount=1), 1 Answer (ANCount=1), 2 Nameserver (NSCount=2), and 1 Additional (ARCount=1) records received.
To see how Compression Pointers are used, we will examine the response for an MX record.
Code:
Answer:
00 02 85 00 00 01 00 01 00 00 00 01 0A 79 65 6C
6C 6F 77 68 65 61 64 03 63 6F 6D 00 00 0F 00 01
C0 0C 00 0F 00 01 00 0D 2E C4 00 0B 00 0A 06 6E
6F 6D 61 69 6C C0 0C C0 2E C0 0C 00 01 00 0D 2E
C4 00 04 60 35 60 32
The last Record is an Additional Record. It starts with a C0 2E. This Compression Pointer points to byte 46, which is the name just recovered above. It is followed by Record Type (00 01), which is an "A" record, and Class (00 01), which is the Internet Class. Following that is the TTL (00 0D 2E C4), the Record Length (00 04), and finally the IP address (60 35 60 32).
Using this technique, you can see how they manage to squeeze 27 root servers into very limited space.
The original version of ClientDNS utilized MS Winsock. Version 2 utilized cSocket2 and supported IPv4 and IPv6 using string data. Version 3 utilizes SimpleSock, which enabled the use of binary information via byte arrays. ClientDNS V3.0 has been tested on Windows Vista and Windows 8.1. IPv6 has not been fully tested because of the lack of a native IPv6 network (tested with Teredo Tunnel).
How to use ClientDNS is demonstrated in the following web page.
http://www.yellowhead.com/DNS_How.htm
It should be noted that you do not have to enter the correct format for PTR requests (ie. 117.178.26.52.in-addr.arpa). You simply enter the IP address (ie. 52.26.178.117), and ClientDNS will reformat it for you. Clicking on any field will display it on the bottom bar, and double clicking will copy it to the clipboard.
J.A> Coutts