DNS Tools

Understanding DNS

DNS Stuff: This tool will help you diagnose DNS problems by allowing you to see how the record is resolved by a third-party. Other useful tools include rDNS lookup and a network mask calculator.

Kloth.net:This nslookup lets you check how any nameserver is resolving a domain name. This can be especially useful when you are moving a domain name and users are complaining they can’t see the site. Check the domain name against their ISP’s nameserver to see if it has updated its cache.

GeekTools: The Whois lookup is indispensable and lets you do lookups from your desktop. Check out the list of RFCs. ‘RFC’ stands for Request For Comments and is a collection of documents that underlie most of the standards in use on the Internet today, including DNS standards. If you plan to administer DNS, be sure to read RFC1034 and RFC1035.

The mysterious ” The DNS Server Has Encountered a Packet Addressed to Itself ” error

Several causes have so far been documented for this error:

  • The DNS Server has itself listed in the Forwarder list. Make sure that the IP addresses in the Forwarder list do not point to the DNS server itself.
  • The DNS Server has itself listed in the Notify list. Make sure that the IP addresses in the Notify list do not point to the DNS server itself.
  • A Secondary Zone on the DNS server lists itself as an IP Master. Make sure that IP addresses for the IP Master of any Secondary Zone do not point to itself.
  • A zone on the DNS server delegates to a sub-domain (child domain or sub-zone) that is on the same server but not listed within a single zone file. Delegate sub-domains within a single zone file.
  • The DNS Server is doing recursive lookups to itself. This happens when a DNS server has multiple IP addresses on one machine and more than one IP address is registered with the InterNIC as DNS servers for the domain. By separating the DNS servers to multiple machines (not running multiple InterNIC-registered servers on one single system) the problem was solved.
  • PTR Records that do not have an A record or CNAME record for the hostname listed. Make sure that all names listed in the PTR records of in-addr.arpa zones have an A record or CNAME record in the appropriate zone database.
  • An NS record in a zone file that points to an upline-DNS, which refers the query back to the DNS server where the NS record originated. Make sure that NS records point to DNS servers that host the domain referenced in the NS record.
  • Corrupted or improperly modified CACHE.DNS files. Be sure to use a properly configured CACHE.DNS file. Check to make sure that the server does not list itself as a root server in the CACHE.DNS. Copy the CACHE.DNS file from the Samples directory to the DNS directory.

In all of these cases listed above the DNS server did actually send a query packet to itself, causing the condition that was reported as an error.  All of these were corrected by properly configuring the DNS server.  So far Microsoft has not documented a case where the error has been reported erroneously.

NOTE: Another reported possible cause for this error is if there are Domain Names registered listing this DNS server as authoritative when they are not hosted on the DNS. The DNS receives queries, goes out to the Internet, and ends up querying itself. To troubleshoot this contact the InterNIC and request a list of all domains registered for that server and verify that all are properly hosted.  I HAVE FOUND THIS TO BE THE PRIMARY CAUSE OF THIS ERROR ON MY SERVERS!

Below is a list of the events that can happen if you have not configured your DNS servers to maintain zones that have been registered.

  1. For example, a client attempts to contact <www.mycompany.com> and sends a query to the root servers for help. The root servers determine that the Start of Authority (SOA) for <mycompany.com> is the DNS server<dns.sample.com> at IP address 10.1.1.1.
  2. The client sends its request to 10.1.1.1 for <www.mycompany.com>. Your server (<dns.sample.com>) looks at it’s zone files, determines it is not the SOA for the <mycompany.com> domain because it does not have a zone file for it.
  3. Your server (dns.sample.com) does an iterative query for <mycompany.com> to the root servers.
  4. The root servers respond to your DNS server with the SOA or owner of thedomain <mycompany.com>, which is at 10.1.1.1. This means your DNS is supposed to look at itself for the answer, and it does not have one.
  5. It is at this point that the DNS server logs the 7062 error.