Event ID 7062 WHY?

[neuro]

Hey all I need some help to figure out why Im getting this warning in the event viewer. I have about 20 domain names all using host headers, using 1 ip address. Each domain name is set as follows:

Primary DNS server:

IN SOA under general I have the zone file name i.e mydomain.com.dns and dynamic updates as NO

In SOA under Name servers I have primary DNS server and secondary DNS server. Note primary DNS also runs IIS

in SOA under the tab zone transfers I have:

- allow zone transfers to any server and under the notify tab I have Automatically notify the following servers (i.e by secondary dns server)


What am I doing wrong here?

Note my comaputer name is dns.mydomain.com and domain name is mydomain.com

My primary dns server name is also dns.mydomain.com


Below is the error message I recieve











Event Type: Warning
Event Source: DNS
Event Category: None
Event ID: 7062
Date: 10/12/2001
Time: 4:51:12 AM
User: N/A
Computer: DNS
Description:
The DNS server encountered a packet addressed to itself -- IP address xxx.xxx.xx.x.x.

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 servers 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 this DNS server unless subzone is also on this server.

Example of self-delegation:
-> This DNS server dns1.foo.com is the primary for the zone foo.com.
-> The foo.com zone contains a delegation of bar.foo.com to dns1.foo.com,
(bar.foo.com NS dns1.foo.com)
-> BUT the bar.foo.com zone is NOT on this server.

Note, you should make this delegation check (with nslookup or 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.
Data:
0000: 50 25 00 00 P%..

 

[butchrecon]

Here this might help. It is LONG so bear with it. It is an article from my MSDN Library. Read carefully and let me know if you have questions.

Solving Other Common DNS Problems
This section lists several common DNS problems and explains how to solve them.

Event ID 7062 appears in the event log.
If you see event ID 7062 in the event log, the DNS server has sent a packet to itself. This is usually caused by a configuration error. Check the following:

Make sure that there is no lame delegation for this server. A lame delegation occurs when one server delegates a zone to a server that is not authoritative for the zone.
Check the forwarders list to make sure that it does not list itself as a forwarder.
If this server includes secondary zones, make sure that it does not list itself as a master server for those zones.
If this server includes primary zones, make sure that it does not list itself in the notify list.
Zone transfers to secondary servers that are running BIND are slow.
By default, the Windows 2000 DNS server always uses a fast method of zone transfer. This method uses compression and includes multiple resource records in each message, substantially increasing the speed of zone transfers. Most DNS servers support fast zone transfer. However, BIND 4.9.4 and earlier does not support fast zone transfer. This is unlikely to be a problem, because when the Windows 2000 DNS Server service is installed, fast zone transfer is disabled by default. However, if you are using BIND 4.9.4 or earlier, and you have enabled fast zone transfer, you need to disable fast zone transfer.

To disable fast zone transfer

In the DNS console, right-click the DNS server, and then click Properties.
Click the Advanced tab.
In the Server options list, select the Bind secondaries check box, and then click OK.
You see the error message "Default servers are not available."
When you start Nslookup, you might see the following error message:

*** Can't find server name for address <address>: Non-existent domain

*** Default servers are not available

Default Server: Unknown

Address: 127.0.0.1

If you see this message, your DNS server is still able to answer queries and host Active Directory. The resolver cannot locate the PTR resource record for the name server that it is configured to use. The properties for your network connection must specify the IP address of at least one name server, and when you start Nslookup, the resolver uses that IP address to look up the name of the server. If the resolver cannot find the name of the server, it displays that error message. However, you can still use Nslookup to query the server.

To solve this problem, check the following:

Make sure that a reverse lookup zone that is authoritative for the PTR resource record exists. For more information about adding a reverse lookup zone, see &quot;Adding a Reverse Lookup Zone&quot; earlier in this chapter.
Make sure that the reverse lookup zone includes a PTR resource record for the name server.
Make sure that the name server you are using for your lookup can query the server that contains the PTR resource record and the reverse lookup zone either iteratively or recursively.
User entered incorrect data in zone.
For information about how to add or update records by using the DNS console, see Windows 2000 Server Help. For more information about using resource records in zones, search for the keywords &quot;managing&quot; and &quot;resource records&quot; in Windows 2000 Server Help.

Active Directory-integrated zones contain inconsistent data.
For Active Directory–integrated zones, it is also possible that the affected records for the query have been updated in Active Directory but not replicated to all DNS servers that are loading the zone. By default, all DNS servers that load zones from Active Directory poll Active Directory at a set interval — typically, every 15 minutes — and update the zone for any incremental changes to the zone. In most cases, a DNS update takes no more than 20 minutes to replicate to all DNS servers that are used in an Active Directory domain environment that uses default replication settings and reliable high-speed links.

User cannot resolve name that exists on a correctly configured DNS server.
First, confirm that the name was not entered in error by the user. Confirm the exact set of characters entered by the user when the original DNS query was made. Also, if the name used in the initial query was unqualified and was not the FQDN, try the FQDN instead in the client application and repeat the query. Be sure to include the period at the end of the name to indicate the name entered is an exact FQDN.

If the FQDN query succeeds and returns correct data in the response, the most likely cause of the problem is a misconfigured domain suffix search list that is used in the client resolver settings.

Name resolution to Internet is slow, intermittent, or fails.
If queries destined for the Internet are slow or intermittent, or you cannot resolve names on the Internet, but local Intranet name resolution operates successfully, the cache file on your Windows 2000–based server might be corrupt, missing, or out of date. You can either replace the cache file with an original version of the cache file or manually enter the correct root hints into the cache file from the DNS console. If the DNS server is configured to load data on startup from Active Directory and the registry, you must use the DNS console to enter the root hints.

To enter root hints in the DNS console

In the DNS console, double-click the server to expand it.
Right-click the server, and then click Properties.
Click the Root Hints tab.
Enter your root hints, and then click OK.
To replace your cache file

Stop the DNS service by typing the following at the command prompt:
net stop dns

Type the following:
cd %Systemroot%\System32\DNS

Rename your cache file by typing the following:
ren cache.dns cache.old

Copy the original version of the cache file, which might be found in one of two places, by typing either of the following:
copy backup\cache.dns

– Or –

copy samples\cache.dns

Start the DNS service by typing the following:
net start dns

If name resolution to the Internet still fails, repeat the procedure, copying the cache file from your Windows 2000 source media.

To copy the cache file from your Windows 2000 source media

At the command prompt, type the following:
expand <drive>:\i386\cache.dn_ %Systemroot%\system32\dns\cache.dns

where drive is the drive that contains your Windows 2000 source media.

Resolver does not take advantage of round robin feature.
Windows 2000 includes subnet prioritization, a new feature, which reduces network traffic across subnets. However, it prevents the resolver from using the round robin feature as defined in RFC 1794. By using the round robin feature, the server rotates the order of A resource record data returned in a query answer in which multiple resource records of the same type exist for a queried DNS domain name. However, if the resolver is configured for subnet prioritization, the resolver reorders the list to favor IP addresses from networks to which they are directly connected.

If you would prefer to use the round robin feature rather than the subnet prioritization feature, you can do so by changing the value of a registry entry. For more information about configuring the subnet prioritization feature, see &quot;Configuring Subnet Prioritization&quot; earlier in this chapter.

WINS Lookup record causes zone transfer to a third-party DNS server to fail.
If a zone transfer from a Windows 2000 server to a third-party DNS server fails, check whether the zone includes any WINS or WINS-R records. If it does, you can prevent these records from being propagated to a secondary DNS server.

To prevent propagation of WINS lookup records to a secondary DNS server

In the DNS console, double-click your DNS server, right-click the zone name that contains the WINS record, and then click Properties.
In the Properties dialog box for the zone, click the WINS tab and select the check box Do not replicate this record.
To prevent propagation of WINS-R records to a secondary DNS server

In the DNS console, double-click your DNS server, right-click the reverse lookup zone that contains the WINS-R record, and then click Properties.
In the properties page for the zone, click the WINS-R tab and select the check box Do not replicate this record.
WINS lookup record causes a problem with authoritative data.
If you have a problem with incorrect authoritative data in a zone for which WINS lookup integration is enabled, the erroneous data might be caused by WINS returning incorrect data. You can tell whether WINS is the source of the incorrect data by checking the TTL of the data in an Nslookup query. Normally, the DNS service answers with names stored in authoritative zone data by using the set zone or resource record TTL value. It generally answers only with decreased TTLs when providing answers based on non-authoritative, cached data obtained from other DNS servers during recursive lookups.

However, WINS lookups are an exception. The DNS server represents data from a WINS server as authoritative but stores the data in the server cache only, rather than in zones, and decreases the TTL of the data.

To determine whether data comes from a WINS server

At the command prompt, type the following:
nslookup -d2

server <server>

where <server> is a server that is authoritative for the name that you want to test.

This starts nslookup in user-interactive, debug mode and makes sure that you are querying the correct server. If you query a server that is not authoritative for the name that you test, you are not able to tell whether the data comes from a WINS server.

To test for a WINS forward lookup, type the following:
set querytype=a

– Or –

To test for a WINS reverse lookup, type the following:

set querytype=ptr

Enter the forward or reverse DNS domain name that you want to test.
In the response, note whether the server answered authoritatively or non-authoritatively, and note the TTL value.
If the server does not answer authoritatively, the source of the data is not a WINS server. However, if the server answered authoritatively, repeat a second query for the name.
In the response, note whether the TTL value decreased. If it did, the source of the data is a WINS server.
If you have determined that the data comes from a WINS server, check the WINS server for problems. For more information about checking the WINS server for problems, see &quot;Windows Internet Name Service&quot; in this book.

A zone reappears after you delete it.
In some cases, when you delete a secondary copy of the zone, it might reappear. If you delete a secondary copy of the zone when an Active Directory-integrated copy of the zone exists in Active Directory, and the DNS server from which you delete the secondary copy is configured to load data on startup from Active Directory and the registry, the zone reappears.

If you want to delete a secondary copy of a zone that exists in Active Directory, configure the DNS server to load data on startup from the registry, and then delete the zone from the DNS server that is hosting the secondary copy of the zone. Alternatively, you can completely delete the zone from Active Directory when you are logged into a domain controller that has a copy of the zone.

You see error messages stating that PTR records could not be registered
When the DNS server that is authoritative for the reverse lookup zone cannot or is configured not to perform dynamic updates, the system records errors in the event log stating that PTR records could not be registered. You can eliminate the event log errors by disabling dynamic update registration of PTR records on the DNS client. To disable dynamic update registration, add the DisableReverseAddressRegistrations entry, with a value of 1 and a data type of REG_DWORD, to the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
\Tcpip\Parameters\Interfaces\<name of the interface>

where name of the interface is the GUID of a network adapter. James Collins
Field Service Engineer
A+, MCP

email: butchrecon@skyenet.net

Please let us (Tek-tips members) know if the solutions we provide are helpful to you. Not only do they help you but they may help others.