DCDiag Test - DNS Root hints list has invalid root hint server

[Sean]

Alright, very simple setup here.

One domain with two DCs
DC1's primary DNS svr is DC2, secondary is DC1
DC2's primary DNS svr is DC1, secondary is DC2
One AD Integrated Forward Lookup Zone
One AD Integrated Reverse Lookup Zone (yes, only one subnet at the
moment)
Forwarders setup going to ISP (not necessary, but slightly better
performance)

So, I go to run dcdiag /test:dns and everything passes except "Forw"
I get an error message for each forwarder, and each root-hint. It's
the same on each one...

DNS server: 128.63.2.53 (h.root-servers.net.) 1 test failure on this
DNS server
This is not a valid DNS server.
PTR record query for the 1.0.0.127.in-addr.arpa. failed on the DNS
server 128.63.2.53

Now, why in the world would dcdiag expect to find localhost
(127.0.0.1) on a public DNS server? Maybe I'm reading that wrong, but
it doesn't make sense to me. Everything appears to be working fine,
both internal and external name resolution...it just bothers me that I
have all those errors. Any help would be appreciated!

[tokyo7]

I was wondering if you ever found a resolution to this. I have a very similar problem.

I have 4 DNS servers, AD Integrated on one I get a clean DCdiag /test:DNS result, yet on three of them I don't. I get errors like this:

IP address: 10.80.1.222
DNS servers:
Warning: 10.80.1.222 (<name unavailable>) [Invalid]
Warning: 10.81.1.222 (<name unavailable>) [Invalid]
Error: all DNS servers are invalid
The A record for this DC was found

and

TEST: Records registration (RReg)
Error: Record registrations cannot be found for all the network adapters

and
DNS server: 192.112.36.4 (g.root-servers.net.)
1 test failure on this DNS server
This is not a valid DNS server. PTR record query for the 1.0.0.12
7.in-addr.arpa. failed on the DNS server 192.112.36.4
[Error details: 9002 (Type: Win32 - Description: DNS server failure.)]

However DNS seems to be working just fine.

Scenario:

I have 4 AD integrated DNS Servers all configured the same, No forwarders configured, root hints are good ( I verified them). Both monitoring tests show Pass. Secure only Dynamic Updates. Scavenging set to 4 days.

I have reverse lookup zones for 127.x.x.x and 10.x.x.x and 172.17.x.x.x.

I have the latest dcdiag from the support tools. On 3 of the 4 DNS servers dcdiag gets errors such as this
------------------------------------------------------------------

Domain Controller Diagnosis

Performing initial setup:
* Verifying that the local machine ads02, is a DC.
* Connecting to directory service on server ads02.
* Collecting site info.
* Identifying all servers.
* Identifying all NC cross-refs.
* Found 9 DC(s). Testing 9 of them.
Done gathering initial info.

OR
This Test:

TEST: Records registration (RReg)
Error: Record registrations cannot be found for all the network adapters


is failing and perhaps causing failures with the other tests???

In any case the only other errors I receive in the event logs are:

DNS Server Event ID 3000 <--maybe once a day
File Replication Service Event ID 13508 but it is followed by 13509 and replication seems to work fine.

Thanks..any help with this would be GREATLY appreciated.

[Ace Fekay [Microsoft Certified Trainer]]

You've replied to a thread/post that is older than 90 days that originated in the Microsoft Public Newsgroups. Microsoft newservers delete posts older than 90 days, therefore we cannot see what you replied to.

If you can help us to better help you, we will need additional information, such as:

Unedited ipconfig /all from your DCs
Unedited ipconfig /all from a sample client
Any event log errors from the DCs and clients.

Do you have a reverse zone for 10.81.1.222? If so, does 10.81.1.222 have a PTR entry?

On the DCs with the invalid Roots, I suggest to delete the roots hints, and reload them from 4.2.2.2.

Asfor the 13508, which Source name is it? Click on the comments link in the following:

And for 13509:

These events say there is a replication problem.

[tokyo7]

Event ID 13508 and 13509 I have not seen since yesterday. In any case they are a separate issue and I believe I resolved this by adding a missing glue record for the DC in question.

In any case back to the DNS issue at hand......

10.81.1.222 has a PTR entry, as all my DNS servers do. 10.81.1.222 is the server that tests good with dcdiag /e /test:dns

The others servers test with errors as shown in my earlier post.

I deleted and reloaded the root servers as suggested on one of the DNS servers (10.9.1.2) and dcdiag /e /test:dns still comes up with the same errors.

I still think these invalid root server errors are false positives because of the nslookup tests I showed in my earlier post.

So then does anybody have an idea as to what is causing this, from dcdiag /e /test:dns:

Adapter [00000007] Intel(R) PRO/1000 EB Network Connection with I/O
Acceleration:
MAC address is 00:04:23:DE:5F:76
IP address is static
IP address: 10.80.1.222
DNS servers:
Warning: 10.80.1.222 (<name unavailable>)
[Invalid]
Warning: 10.81.1.222 (<name unavailable>)
[Invalid]

OR

THIS TEST:

TEST: Records registration (RReg)
Error: Record registrations cannot be found for all the
network adapters

I did a packet capture on a DNS server 10.9.1.2 and behold it really did go out and ask the root servers

1218 3.331939 10.9.1.2 192.203.230.10 DNS Standard query PTR 1.0.0.127.in-addr.arpa
1238 3.404205 192.203.230.10 10.9.1.2 DNS Standard query response, No such name

So my assertion that these were false positives was perhaps wrong. I just don't get why a fresh reload of the root hints did not fix it. Or why a manual nslookup from command line works, or why I have another DNS server that the dcdiag test will show a PASS for everything.

Also I even put in the host file a lookup for the IPs of itself and the other DNS servers just in case and it still failed in this manner:

TEST: Records registration (RReg)
Error: Record registrations cannot be found for all the network adapters

DNS server: 192.112.36.4 (g.root-servers.net.)
1 test failure on this DNS server
This is not a valid DNS server. PTR record query for the 1.0.0.12
7.in-addr.arpa. failed on the DNS server 192.112.36.4
[Error details: 9002 (Type: Win32 - Description: DNS server failure.)]

C:\Program Files\Support Tools>nslookup
Default Server: ads04.bancfirst.com
Address: 10.81.1.222

> d2
Server: ads04.bancfirst.com
Address: 10.81.1.222

*** ads04.bancfirst.com can't find d2: Non-existent domain
> 192.203.230.10
Server: ads04.bancfirst.com
Address: 10.81.1.222

Name: e.root-servers.net
Address: 192.203.230.10

> d2
Server: ads02.bancfirst.com
Address: 10.80.1.222

*** ads02.bancfirst.com can't find d2: Non-existent domain
> 192.203.230.10
Server: ads02.bancfirst.com
Address: 10.80.1.222

Name: e.root-servers.net
Address: 192.203.230.10
>

The other two DNS serves give like returns from nslookup

Note I have 4 DNS servers:
ads04 - where dcdiag /e /test:dns runs with NO errors
ads02 - where dcdiag /e /test:dns runs with errors
ads055 - where dcdiag /e /test:dns runs with errors
ads09 - where dcdiag /e /test:dns runs with errors

I am pretty sure these errors were caused by a DC not having a glue (A record). After I found that error with dnslint I added the glue record and I have not seen those errors since. I have tested replication by forcing it and all seems to be well now.

I know those records are created automatically - but I think we had an over eager admin delete a record or two at one time.

I do not administer our AD. I work in security and was asked to review AD because they were having certain issues. They were resolved but I came across this DNS discrepancy and was curious to discover why there was inconsistent tests between ads04 and the rest of the DNS servers.

I feel like a moron. I asked an admin if he installed the latest tools but did not verify that they were all the same version. Here is what I got when I verified versions:

dcdiag versions:
ads02 -- 5.2.3790.1830
ads04 -- 5.2.3790.3959
ads009 -- 5.2.3790.1830
ads055 -- 5.2.3790.1830

I reinstalled Support tools - made sure of the latest dcdiag and NOW ALL tests when I run dcdiag /e /v /test:dns run without error on all DNS servers!!!

So this is the problem and explains why my manual tests succeeded while the tool failed.

As for your other concerns. My understanding is that they do not want to use forwarders because they do not trust other ISP related or owned DNS servers to be secured sufficiently against DNS poisoning.

[Ace Fekay [Microsoft Certified Trainer]]

Run the following please, and post the results.

nslookup d2
(post results)

then while in batch mode, enter 192.203.230.10, and post that result too, please.

I know you said you do not use Forwarders. In many cases, using Forwarders are suggested and some would say using them is 'best practice.' I'm not sure of your company's reasons to not use them, and I respect whatever reason it is, but if I may suggest, configure a forwarder and re-run your tests. Most of these root hint errors, and possibly all, do not occur with Forwarders, for obvious reasons.

I know you want to get it right, but I am suggesting to use Forwarders to get these errors out of the way, because they may be tainting other possible errors going on. I know you said that the 13508 and 13509 errors are now gone, but my curiosity is getting the best of me because these errors do not just pop up and disappear for no reason. I would like to know, and I'm sure you are curious as the administrator of your AD infrastructure, that if you eliminate these Root hint errors, I would like to know if there are any other errors going on concerning replication, which is a more serious issue.

And I am very surprised there was no glue record for one of your DC DNS servers, which is more of an idication that there is a replication issue that initially caused this, because these records, as well as everything else, automatically get registered without manual intervention.

Also, I know you said you have the latests dcdiag and netdiags versions. Curious, when you ran the tests, did you run them from one machine, or on each DC? Can you compare the versions on each DC to see if there are any discrepancies?

Here is the link for the latest. Try installing the tools on one DC and compare the versions:
Download and install the Windows Server 2003 Service Pack 2 32-bit Support Tools
http://www.microsoft.com/downloads/d...ng=en#filelist

Also, in your edge firewalls, assuming you have more than one, do you have EDNS0 enabled?

[bjohnsonta]

Thanks the the version info. That was my problem with DCDIAG not running properly. I downloaded the Windows 2003 Support Tools SP2 and now it runs clean.