Build a great reporting interface using Splunk, one of the leaders in the Security Information and Event Management (SIEM) field, linking the collected Windows events to www.eventid.net. The EventId.Net for Splunk Add-on assumes that Splunk is collecting information from Windows servers and workstation via the Splunk Universal Forwarder.
DNS Server encountered a packet addresses to itself -- IP address <ip address>. The DNS server should never be sending a packet to itself. This situation usually indicates a configuration error.
Check the following areas for possible self-send configuration errors:
1) Forwarders list (DNS server should not forward to themselves).
2) Master lists of secondary zones.
3) Notify lists of primary zones.
4) Delegations of subzones.
Must not contain NS record for DNS server
Example: -> This DNS server dns1.microsoft.com is the primary for the zone microsoft.com. -> You have delegated the zone bar.microsoft.com to bardns.bar.microsoft.com and are NOT running the bar.microsoft.com zone on this DNS (dns1.microsoft.com). Note, you should make this check (with nslookup of DNS manager) both on this DNS server and on the server(s) you delegated the subzone to. It is possible that the delegation was done correctly, but that the primary DNS for the subzone, has any incorrect NS record pointing back at this server. If this incorrect NS record is cached at this server, then the self-send could result. If found, the subzone DNS server admin should remove the offending NS record.
|English: This information is only available to subscribers. An example of English, please!|
|Concepts to understand:|
What is the role of a DNS server?
I ran into this same event. To fix the problem open the DNS console. Under forwarders, click the Notify tab on the bottom. If your DNS is listed in your name servers, the Notify function by default will send to all that are listed. Change that setting to only your other secondary DNS server. Your primary DNS server does not need to notify itself of zone changes. When left in its default mode, the primary sends zone change requests to itself causing this event. You can also see proof of that in the full debug log for DNS; you will see the UDP send command.
ME235689 and MSW2KDB shows you how to troubleshoot 7062 errors logged in DNS event log.
From a newsgroup post: "Since the installation of NT SP4, many of us started getting DNS Error 7062. So what is causing 7062? Last weekend I got some free time and decided to look further. At the pocket level and found a very interesting thing. I saw repeated name resolution request for one of my registered domains. Time of occurrence of 7062 was matching the time when DNS was asked to resolve that particular name. What was interesting is that I never created DNS zone for that domain! I myself requested to resolve my “xyz.com” and got 7062 again. I simply created new zone for that domain and other "reserved" domain names and 7062 never occurred since then. I believe that most of the users affected by 7062 (and still unable to resolve it) simply reserved domain names for the future use and never added them to the DNS server. As long as your DNS is an authoritative for any particular domain, you will be continuously asked to resolve it by Internic. Internic is periodically checking if your name servers are lame by requesting SOA for your every registered domain name. That explains why this error comes and goes (and explains why someone is asking to resolve the name of your secret domain nobody knows about)".
From a newsgroup post: "In addition, a cause for this error is the lack of PTR records in the arpa files. After we added a couple of reserved domains you our DNS records and fixed our arpa files, we have never seen this error".
We had this error in our root DC. Creating the _msdcs.<rootdomain> zone as per article ME817470 fixed the problem.
I got this error when I changed the root hints so that Server A pointed to itself and Server B pointed to server A. I corrected it by having Server A to point to Server B and Server B to point to Server A in the root hint.
As per Microsoft: "This error is caused by a configuration error or is the result of a delegation of a domain (or subdomain) to a server for which there is no zone file (lame delegation)." However it appears that that's not the case all the time. Sometimes, the error is caused by the cache.dns file pointed to iteself as well as the root hints.
Some users reported this problem fixed by adding a reverse lookup subnet in their DNS.
According to a newsgroup post: "After many hours of research and scouring of newsgroups I finally have fixed my DNS packets being sent to itself. I have two Win2000 domain controllers that are receiving packets sent to themselves. Of course the event viewer says check lame delegation, etc. None of those solutions fixed the problem in my case. Neither did any new group suggestions. But they helped point me in the right direction. My servers have addresses of 192.168.1.2 and 192.168.1.3. After reading some of the suggested white papers in the knowledgebase it became apparent to me to check my CACHE.DNS file and ROOT HINTS for problems. My root hints were pointing to my internal servers as well as the cache.dns files. That was the problem on both servers. My interpretation is as follows: At the time my Active Directory and DNS were installed on my servers I didn't have them connected to the Internet. Therefore my DNS servers got configured as the root authority for all zones. That's why I had a "." zone in my DNS and couldn't turn on forwarding. As far as it was concerned I didn't have anywhere to forward since I was the root authority. Now after I had installed the AD and DNS I later hooked the servers up to the Internet, deleted the "." zone and configured forwarders. Everything worked great as far as the clients being forwarded to the Internet DNS servers for resolution. However, since the install was done without Internet connectivity the root hints (the place that DNS looks for zones outside its authority) had been pointed to the local machine as well as the cache.dns file. Looking in the cache.dns file there is a section at the top that explains what the root hints should be if you either are, or aren't connected to the Internet. I speculate that packets addressed to other zones were being referenced to the root hints list, which my server was a part of. Therefore it sent itself a packet. I was able to fix this by doing a search for any cache.* files on the server. It found my cache.dns file and the original sample file. The original sample file contains the Internet root hints. I simply renamed the cache.dns file and copied the sample file to cache.dns. Then on the DNS server I went into server properties (or maybe zone properties) and there was a root hints tab. I deleted my two servers out of there and manually entered the Internet root hints from the cache.dns sample file. Rebooted and haven't seen the errors since! Whew! I suspect that you might be able to change one or the other, the cache.dns or the root hints in DNS. Not sure how that works; if one is referenced before the other or not. I wanted to delete any reference to my own servers in there so I made the changes in both places. Hope that helps. It sure did the trick for me."
For information on how to restore root servers see ME229840, link below.
|Private comment: Subscribers only. See example of private comment|
|Links: ME218814, ME229840, ME235689, ME243849, ME817470, MSW2KDB|
|Search: Google - Bing - Microsoft - Yahoo - EventID.Net Queue (1) - More links...|
|Custom search for *****: Google - Bing - Microsoft - Yahoo|
Send comments or solutions
- Notify me when updated