Repeated 7062 Errors in DNS Event logs

Getting repeated 7062 errors indicating that the DNS server encountered a packet addressed to itself indicating a possible configuration error.  All of the research that I have read on this talks of the root hints listing the DNS server IP address listed in here which is not the case.  I have run the DNSLINT command and between the other 6 servers in the forest root they all indicate the same responses showing two servers one in the forest root that cannot be contacted.  This server object is a tombstoned DC object that is scheduled to be removed within the next week.  Not sure if this could cause this "warning" or not, need some additional guidance.  
LombwarAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Chris DentPowerShell DeveloperCommented:

Hey there,

Sorry about just linking, but it does a better job of describing the cause and steps to troubleshoot than I. Have you been through this at all?

http://support.microsoft.com/kb/235689

You may find it beneficial to log the packets received by your server to fully capture the query being executed.

Chris
0
LombwarAuthor Commented:
Thanks for the link, went through the document and did not see any hits to our problem.  Have looked through the DNS.log for this server and do not see any 7062 errors listed, in fact the log looks pretty clean regarding any errors listed in it.  

Checked the registry for the server and there was no Zones tab under the DNS area in the registry.  One of these tough issues as nothing failing just this warning message that pops up every 2 minutes.  One of the things lead us here is we lost primary DNS server for child domain, other sites looking to this as a secondary lookup server and during the 1 hr outage certain names listed at the forest root could not be resolved by applications or clients.
0
LombwarAuthor Commented:
To note, our authoritative server that is in our forest root is running Windows 2000 where the servers from the child domain are running Windows 2003 native mode.  not sure if this is an issue or not.
0
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

Chris DentPowerShell DeveloperCommented:

If you log the packets you should be able to capture the query that's being executed (and the source). It would be better to do that as a first step because it's pretty straight-forward :)

Chris
0
LombwarAuthor Commented:
Did grab the log files but looking through it do not see any errors generated indicating where the problem stems from.  Broke down called Microsoft and their statement was to upgrade DNS.exe on the Win 2000 box.
0
LombwarAuthor Commented:
Running the dcdiag /test:dns utility on our domain controllers and get warning "Dynamic update is enabled on the zone but not secure", looking zone under forward lookup and see that setting is for both non secure and secure.  Researching different information to clarify the drawbacks to setting it to secure versus leaving the way it is now?
0
Chris DentPowerShell DeveloperCommented:

Non-secure will allow non-domain clients, clients that cannot provide a key, to add entries into the DNS Server. If the DNS server isn't public that's not so much of a concern, but it does give clients rather more power than would normally be appropriate.

It shouldn't effect DHCPs ability to register records, DHCP is capable of performing secure updates. From the log information we looked at yesterday it was submitted a TSIG key, making it's attempts secure.

Chris
0
Chris DentPowerShell DeveloperCommented:

Ignore this bit:

It shouldn't effect DHCPs ability to register records, DHCP is capable of performing secure updates. From the log information we looked at yesterday it was submitted a TSIG key, making it's attempts secure.

Relates to another question, got mixed up ;)

The first paragraph still applies though.

Chris
0
LombwarAuthor Commented:
Just interested then if the clients should have this power?  We set the servers to register their information into DNS but not necessarly workstations.  The key sounds like would have to setup on each server as part of a build process in order to maintain the table integrity?  This is not a public system, yet behind the firewall for the child domain.  The forest root DNS is for our Unix based systems and such, very few objects reside in this domain.
0
Chris DentPowerShell DeveloperCommented:

Personally I always favour Secure Updates, you might not notice the difference but it's less of a hole.

For the key itself, if it weren't built-in functionality you'd be right and it would require configuration.

As it is, Windows DNS on a DC has that built in. The client generates a valid key by virtue of it's computer account, taking a step back, the computer is using Kerberos to maintain it's authenticated session with the domain. That key is submitted to the DNS server, checked again then either permitted to update or denied.

Because we're using predictable clients, they perform predictable actions. A client will only add A and PTR Records into DNS, it'll never operate outside the boundaries of that unless you start hacking into the system.

Basically quite complex functionality made simple (and semi-transparent) because the client is pre-programmed to do so (Windows 200x, XP, Vista).

Chris
0
LombwarAuthor Commented:
Chris, thanks for the details regarding this.

With your experience, is this something that we should change in the off hours to switch all of the domain controllers to secure?  If so where would you start, the DC holding the SOA for the domain?
0
LombwarAuthor Commented:
Chris, thanks for the details regarding this.

With your experience, is this something that we should change in the off hours to switch all of the domain controllers to secure?  If so where would you start, the DC holding the SOA for the domain?
0
Chris DentPowerShell DeveloperCommented:

Sorry, lost track.

All DCs will claim to be SOA. It's a harmless operation though (as it won't de-register existing records), clients won't notice any downtime at all if you were to switch the zone to Secure Updates only.

Moderately sure the Dynamic Updates option for the zone travels with the zone. And as that replicates through AD it'll show Secure Only on all DCs after a short time.

Chris
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Active Directory

From novice to tech pro — start learning today.