Repeated 7062 Errors in DNS Event logs

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

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.

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.

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

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.

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?

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

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

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.

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

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?

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?