Domain controller GUID CNAME records missing from DNS
- Hi Guys,
Following on from this thread http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/95fd1379-1260-45ed-9bae-5b0c625d0a59
I am trying to just tackle things one step at a time now - we are changing the SIDs on any machines that we get problems on and on any new machines we build so we will see if that stops machines dropping off the domain. However, I still think we have some other problems with our DNS servers and Domain Controllers. One such problem is that a couple of the DCs (we have about 20 in our domain) do not have a CNAME record in DNS for their GUID based name, and as such we are getting errors in the event logs on other DCs stating that they failed to replicate to them using the GUID based name.
So my question is, how do I go about creating these GUID CNAME records in DNS? Can I just manually add them or is there a more 'proper' way of doing it? (ipconfig /registerdns perhaps?)
Thanks
Chris
All Replies
- Chris,
these records are registered automatically by Netlogon - so one common way of recreating them is restarting the service. Before you do so, make sure that the primary DNS server entry points to an AD-integrated DNS server.
This is the recommended way of handling missing/incorrect AD DNS records - but if you are running into problems with this, you might consider creating the CNAME/SRV records manually - at least until your replication/DNS registration issues are resolved...
hth
Marcin Ah ok, thanks for the reply. I'll try restarting the Netlogon service tomorrow and see if that kicks things into shape :)
Let you know how it goes..
Cheers
Chris- Hi
netdiag /fix will also do the trick, additionally post here the results for:
repadmin /replsum * /bysrc /bydest /sort:delta
I hope that the information above helps you. This posting is provided "AS-IS" with no warranties or guarantees and confers no rights. - Hmm well I just went to check DNS again today before I did the service restart and the GUID names are there now... which is odd. The servers have not been rebooted or anything, so I dont know why this would suddenly have happened. However, there are still warnings in the event logs on loads of the DCs about not being able to resolve their replication partner's name by the GUID based name (it says replication was still successful as it used the normal DNS host name).
Its odd though because if I connect to one of the DCs that has this warning in it's event logs and do a ping to the GUID based named that the warning was referring to, it works fine and resolves it to the correct IP.. - Can you post the outcome of
dcdiag /test:dns /DnsRecordRegistration /v
from both replication partners?
hth
Marcin - I just ran that and it said that it could not resolve the CNAME records... so I looked in DNS again and they have vanished now! I checked the DNS database on 3 different DCs yesterday and none of them showed these CNAME records - then today I checked those same 3 servers and they all showed the CNAME records being there, then just now when I checked all of those servers again they are not there again. I am confused... Do you still want me to post the results of that command?
Create them manually. Identify the GUID of the DCs in question by following steps in Using LDP.EXE from the Windows 2000 Resource Kit section of http://support.microsoft.com/kb/224544/EN-US/
Once the CNAME records are in place, initiate replication between the respective DCs and verify that it completes successfully. At that point, you might want to re-run the dcdiag /test:dns /DnsRecordRegistration /v , delete manually created CNAME records, and re-register them by restarting Netlogon service on each DC...
hth
Marcin- OK I'll give that a go thanks - if I run repadmin /showrepl then it gives me the DC's GUID name so can I just use that rather than using LDP.EXE ?
One other thing that dcdiag reported was that there was a missing SRV record in dc._msdcs.ourdomain.local
Chris - They should be identical - but verify whether this is the case...
Ensure that all AD-specific CNAME/SRV/A records exist...
hth
Marcin I guess its bad then that dcdiag reports the following:
Matching A record found at DNS server 192.168.10.253:
dc01.mydomain.group.localMatching CNAME record found at DNS server 192.168.10.253:
dcc435da-7839-4b03-9b40-41c6efc67682._msdcs.group.localError: Missing DC SRV record at DNS server 192.168.10.253 :
_ldap._tcp.dc._msdcs.ses.group.local
[Error details: 9003 (Type: Win32 - Description: DNS name does not exist.)]
Warning: Missing GC SRV record at DNS server 192.168.10.253 :
_ldap._tcp.gc._msdcs.group.local
Error: Missing PDC SRV record at DNS server 192.168.10.253 :
_ldap._tcp.pdc._msdcs.ses.group.local
[Error details: 9003 (Type: Win32 - Description: DNS name does not exist.)]
Matching A record found at DNS server 192.168.10.254:
dc01.mydomain.group.localError: Missing CNAME record at DNS server 192.168.10.254 :
dcc435da-7839-4b03-9b40-41c6efc67682._msdcs.group.local
[Error details: 9003 (Type: Win32 - Description: DNS name does not exist.)]
Error: Missing DC SRV record at DNS server 192.168.10.254 :
_ldap._tcp.dc._msdcs.ses.group.local
[Error details: 9003 (Type: Win32 - Description: DNS name does not exist.)]
Warning: Missing GC SRV record at DNS server 192.168.10.254 :
_ldap._tcp.gc._msdcs.group.local
Error: Missing PDC SRV record at DNS server 192.168.10.254 :
_ldap._tcp.pdc._msdcs.ses.group.local
[Error details: 9003 (Type: Win32 - Description: DNS name does not exist.)]
Error: Record registrations cannot be found for all the network adapters
Summary of test results for DNS servers used by the above domain controllers:DNS server: 192.168.10.253 (<name unavailable>)
All tests passed on this DNS server
This is a valid DNS server
Name resolution is funtional. _ldap._tcp SRV record for the forest root domain is registered
DNS server: 192.168.10.254 (<name unavailable>)
All tests passed on this DNS server
This is a valid DNS server
Name resolution is funtional. _ldap._tcp SRV record for the forest root domain is registered
Summary of DNS test results:
Auth Basc Forw Del Dyn RReg Ext
________________________________________________________________
Domain: mydomain.group.local
dc01 PASS PASS n/a n/a n/a FAIL n/a
......................... group.local failed test DNSYes - this does not look healthy.
Start by identifying all missing records and DCs they correspond to. You can create them manually and verify whether this resolves the replication issues - which potentially might help with identifying the root cause of DNS problems...
To simplify troubleshooting, my suggestion would be to point all DCs to a single forest root-based DNS server (assuming that either it hosts all AD-related zones - or that you have properly configured delegation) and ensure that all AD records get registered at that point...
hth
Marcin- You may have a LOT of BAD things in your forest, not JUST DNS, so even if you manually fix your DNS you may end up with nothing. For instance due name resolution problems which brings replication problems, you may have "Dead" DCs in your Forest, and you may need to perform metada clena up and reintroduce them again in the domains.
The troubleshooting process is not complicated:
- First you need to collect the available information in the logs, you have for sure errors that give you clues about what's going wrong there.
- Determine the how long those DCs don't replicate with other DCs, if that time exceeds the TombStoneLitime of your forest you may need to perform metadacleanup and re-introduce them again in the domain.
- Before introduce those DCs in the domain, you need to determine the original cause of that break and fix it before proceed. DNS records for DCs don't just desapear from DNS, there's always a simple explanation, Connectivity problems, FW locks are generally the most common ones.
- DCDIAG, netdiag and eventviwer are excellent tools that may point you in the right direction.
I hope that the information above helps you. This posting is provided "AS-IS" with no warranties or guarantees and confers no rights. - I ran netdiag /test:dns on our two 'main' DCs/DNS servers - I say 'main' because they are the FSMO role holders and are also what all of our other DCs have their primary DNS servers set to look at. Anyway, netdiag from one of them reported a PASS but from the other one reported FATAL ERROR as can be seen below:
[WARNING] The DNS entries for this DC are not registered correctly on DNS server '192.168.10.254'. Please wait for 30 minutes for DNS server replication.
[WARNING] The DNS entries for this DC are not registered correctly on DNS server '192.168.10.253'. Please wait for 30 minutes for DNS server replication.
[FATAL] No DNS servers have the DNS records for this DC registered.
So I then ran netdiag /test:dns /fix and after a few minutes ran netdiag /test:dns again and this time it reported a PASS for both servers. However, if I run netdiag /test:dns /V on each DC then it reports quite a lot of records as being different when comparing records on the DC I am running it on against records on its primary DNS server.
I am also still getting the NTDS warnings in event viewer about not being able to resolve other DCs via their GUID based names. However, all of the GUID names that it mentions DO have entries in DNS and when I ping those names from the server that has that warning in the event viewer it resolves it without a problem... - OK after netdiag fixed those missing DNS entries earlier, they have now disappeared again and so netdiag now reports the servers as failing the DNS tests again...
This seems to be a recurring theme, DNS records randomly appearing and disappearing - is there any way I can find out what it is that is removing the DNS records?
Thanks
Chris OK after netdiag fixed those missing DNS entries earlier, they have now disappeared again and so netdiag now reports the servers as failing the DNS tests again...
This seems to be a recurring theme, DNS records randomly appearing and disappearing - is there any way I can find out what it is that is removing the DNS records?
Thanks
Chris
2 Things comes to my head at this moment:
1- Someone is removing them manually. You may need to enable audit on the servers and perform a regular check who is doing that.
2- You've scavenge setup in more than one DNS server and you may have a problem with "des-sync" of the removal of those same records. To check and solve this, configure scavenge only in one DNS server, and that server will be the one to remove the stale DNS records.
I hope that the information above helps you. This posting is provided "AS-IS" with no warranties or guarantees and confers no rights.Thanks for the reply - I'm confident that no one is manually removing them, so I will check the scavenging configuration tomorrow when I am back at work. You dont think it could be due to replication problems then? (i.e. one server replicating 'over the top' of a newer version of the DNS database held on another server)
Thanks for the reply - I'm confident that no one is manually removing them, so I will check the scavenging configuration tomorrow when I am back at work. You dont think it could be due to replication problems then? (i.e. one server replicating 'over the top' of a newer version of the DNS database held on another server)
In some scenarios, yes, but I already saw others different issues with the same result.
Replications problems and lack of sync between those servers could cause this, IMO te best way to test this is to setup only one DNS server to perform that job, but you must be patient and make sure that after that change ALL DCs are correctly sync with each other, only after that you should collect information about what's happening on those servers. Turn on loggin, turn on auditing, if something is wrong those logs may be useful as last resource analysis.
I hope that the information above helps you. This posting is provided "AS-IS" with no warranties or guarantees and confers no rights.- When you say setup one DNS server to perform that job - which job are you referring to?
I'm just going through each server now checking to see if scavenging is enabled (so far only 1 has it enabled when I look in the Server's properties but they all show it as being enabled if I look at our domain zone properties).
I also just checked and some more DNS records that were created yesterday have now disappeared :( these were just A records for a couple of file servers which were created by running ipconfig /registerdns on the file servers themselves. - I've finished checking all of the servers now and 4 out of our 22 DC/DNS servers have got scavenging enabled - so I could disable this on 3 of them and leave just one doing the scavenging. However, I dont understand why scavenging would be removing the type of records that are disappearing, I mean I thought it was just supposed to remove records that were dynamically created by DHCP or that specifically had the 'scavenging' flag set on them. Like I said, the records that have disappeared today were for a file server which has a static IP, so surely those records shouldnt be scavenged no matter what, right?
I also just found that when I look at the Name Servers tab for our domain zone in DNS it has got all of the servers I expected in but also has one old server in there - I've taken this out now but I assume that couldnt have caused any problems as the server has been offline for months?
Also, you asked me earlier to post the results of repadmin /replsum - here it is:
Beginning data collection for replication summary, this may take awhile: .................................................. ...... Source DC largest delta fails/total %% error SES-HANSON (unknown) 1 / 12 8 (8606) Can't retrieve message string 8606 (0x219e), error 1815. SCL-MI2 03d.01h:28m:35s 5 / 67 7 (1908) Can't retrieve message string 1908 (0x774), error 1815. SCL-STNEOTS 02d.05h:28m:27s 5 / 12 41 (1908) Can't retrieve message string 1908 (0x774), error 1815. SCL-DC01 01d.00h:28m:29s 5 / 188 2 (1908) Can't retrieve message string 1908 (0x774), error 1815. SES-DC01 02h:08m:51s 3 / 132 2 (8606) Can't retrieve message string 8606 (0x219e), error 1815. SES-GRACECHURCH 01h:58m:32s 0 / 7 0 SES-HACKNEY 01h:58m:31s 0 / 7 0 SES-BROOMFIELD 01h:58m:30s 0 / 7 0 SES-HESLINGTON 01h:58m:29s 0 / 7 0 SES-NEWBURY 01h:58m:28s 0 / 7 0 SES-MIDLANDS2 01h:01m:19s 0 / 14 0 SES-ROCKCLIFFE 58m:32s 0 / 22 0 SES-SHEFFIELD 58m:32s 0 / 7 0 SES-NEWCASTLE 58m:32s 0 / 7 0 SES-DC02 58m:32s 0 / 94 0 SCL-LO2 58m:06s 0 / 15 0 SES-DC03 58m:05s 0 / 14 0 SES-DC04 57m:59s 0 / 33 0 SES-ASTRA 28m:50s 0 / 27 0 SCL-RICHMOND 28m:48s 0 / 141 0 SES-GMW 28m:46s 0 / 107 0 SES-DC05 28m:44s 0 / 37 0 SCL-SPENNYMOOR 28m:26s 0 / 7 0 SCL-DERBY 28m:23s 0 / 14 0 SCL-BERNERS 28m:22s 0 / 7 0 SCL-CITYLOFT 28m:21s 0 / 7 0 SCL-ROCKHALL 28m:20s 0 / 7 0 SCL-MIDDLEBSF 28m:19s 0 / 7 0 SCL-LEEDSICS 28m:19s 0 / 7 0 SCL-MAIDENHEAD 28m:18s 0 / 7 0 SCL-PIRBRIGHT 28m:18s 0 / 7 0 SCL-COVENTRY 28m:16s 0 / 7 0 SES-RAILHOUSE 27m:33s 0 / 32 0 ROOT-DC02 13m:03s 0 / 24 0 SCL-DC02 13m:00s 0 / 35 0 SCL-YORKUNI 12m:54s 0 / 10 0 ROOT-DC01 12m:54s 0 / 33 0 SES-WESTMIDS2 11m:29s 0 / 12 0 SES-SHELL 10m:49s 0 / 10 0 SES-MANSFIELD 10m:41s 0 / 36 0 ROOT-DC03 10m:40s 0 / 26 0 SCL-ECFPHASE3 10m:28s 0 / 17 0 SCL-SHEP2 05m:54s 0 / 33 0 SCL-NO 04m:11s 0 / 14 0 SCL-NW 04m:02s 0 / 19 0 SCL-NE2 04m:01s 0 / 14 0 SES-WOOLWICH 02m:47s 1 / 27 3 (8606) Can't retrieve message string 8606 (0x219e), error 1815. SCL-LONCANCER 01m:23s 0 / 7 0 SCL-CHESHUNT 01m:16s 0 / 5 0 SCL-TYNEMOUTH :54s 0 / 5 0 SCL-WHARTFORD :50s 0 / 7 0 SES-NORTHWEST2 :47s 0 / 12 0 SCL-BISHOPAUCK :45s 0 / 5 0 Destination DC largest delta fails/total %% error SES-GMW (unknown) 3 / 57 5 (8606) Can't retrieve message string 8606 (0x219e), error 1815. SES-DC05 (unknown) 1 / 29 3 (8606) Can't retrieve message string 8606 (0x219e), error 1815. SES-ASTRA (unknown) 1 / 29 3 (8606) Can't retrieve message string 8606 (0x219e), error 1815. SES-MANSFIELD 03d.01h:29m:03s 15 / 97 15 (1908) Can't retrieve message string 1908 (0x774), error 1815. SES-HESLINGTON 02h:10m:17s 0 / 12 0 SES-ROCKCLIFFE 02h:07m:40s 0 / 28 0 SES-NEWBURY 02h:03m:04s 0 / 12 0 SES-SHELL 58m:59s 0 / 29 0 SCL-SHEP2 58m:06s 0 / 19 0 SES-WESTMIDS2 57m:10s 0 / 19 0 SCL-MIDDLEBSF 30m:08s 0 / 29 0 SCL-WHARTFORD 29m:51s 0 / 21 0 SCL-COVENTRY 29m:20s 0 / 29 0 SCL-RICHMOND 28m:48s 0 / 136 0 SCL-BERNERS 28m:22s 0 / 24 0 SCL-ECFPHASE3 14m:57s 0 / 17 0 SCL-CHESHUNT 12m:41s 0 / 5 0 SCL-TYNEMOUTH 12m:32s 0 / 5 0 SES-MIDLANDS2 11m:38s 0 / 26 0 SES-SHEFFIELD 11m:34s 0 / 12 0 SES-DC02 11m:02s 0 / 15 0 SES-DC03 10m:53s 0 / 18 0 SES-DC01 10m:41s 0 / 18 0 ROOT-DC03 10m:38s 0 / 11 0 ROOT-DC01 10m:28s 0 / 20 0 SCL-DERBY 10m:10s 0 / 29 0 SES-GRACECHURCH 10m:00s 0 / 12 0 ROOT-DC02 09m:47s 0 / 16 0 SCL-CITYLOFT 09m:46s 0 / 19 0 SES-HACKNEY 08m:39s 0 / 19 0 SES-NEWCASTLE 07m:34s 0 / 12 0 SCL-PIRBRIGHT 06m:59s 0 / 24 0 SCL-NE2 06m:45s 0 / 26 0 SCL-NO 05m:53s 0 / 30 0 SES-RAILHOUSE 05m:38s 0 / 22 0 SCL-LONCANCER 05m:13s 0 / 28 0 SCL-LEEDSICS 04m:58s 0 / 34 0 SES-HANSON 04m:19s 0 / 17 0 SCL-DC01 04m:14s 0 / 67 0 SES-WOOLWICH 03m:35s 0 / 29 0 SCL-SPENNYMOOR 03m:20s 0 / 24 0 SCL-ROCKHALL 03m:16s 0 / 19 0 SCL-YORKUNI 03m:14s 0 / 10 0 SCL-LO2 02m:17s 0 / 28 0 SCL-BISHOPAUCK 02m:15s 0 / 5 0 SCL-MI2 02m:09s 0 / 62 0 SES-NORTHWEST2 01m:42s 0 / 17 0 SES-DC04 01m:20s 0 / 36 0 SCL-MAIDENHEAD 01m:14s 0 / 29 0 SES-BROOMFIELD :49s 0 / 12 0 SCL-DC02 :33s 0 / 16 0 SCL-NW :24s 0 / 34 0 SCL-STNEOTS :19s 0 / 31 0
This is getting really annoying :( records are just appearing and disappearing all the time. I ran dcidag /test:dns on one of the 'main' DCs that holds the FSMO roles about 20 mins ago and it reported everything as being fine. Ran it again just now and it reports that the CNAME record is missing, and that the GC SRV record is missing! This is after I turned off scavenging on all servers apart from this one 'main' DC and manually created the SRV records for _ldap and _kerberos for every single DC (created them in _tcp.dc._mcdcs.ourdomain.group.local).
Chris,
my suggestion would be to designate a DNS server in your environment that will be serving as the primary and switch (temporarily) to non-AD integrated zones (with others serving as secondaries). Once you resolve your replication issues, switch back....hth
Marcin- Thanks, but doesnt it look like it is DNS that could quite likely be the cause of the replication problems? If not, then what else could it be?
Cheers
Chris Thanks, but doesnt it look like it is DNS that could quite likely be the cause of the replication problems? If not, then what else could it be?
Cheers
Chris
Hi Chris,
Did you gave time enough to test that? Did you sync all DCs and then configure the setting only in one DC/DNS?
I hope that the information above helps you. This posting is provided "AS-IS" with no warranties or guarantees and confers no rights.- Configure which setting?
- Set scavenging only to one server.
- Hi Guys,
Sorry, I've been on holiday for the last week and just got back to work. I set scavenging just to one server before I went away and when I came back today I found that some DNS records have gone missing again :(
Do you think it would be worth while enabling the DNS auditing policy? Perhaps this would log a reason for why it is removing a record? Hi Guys,
Sorry, I've been on holiday for the last week and just got back to work. I set scavenging just to one server before I went away and when I came back today I found that some DNS records have gone missing again :(
Do you think it would be worth while enabling the DNS auditing policy? Perhaps this would log a reason for why it is removing a record?
Hum.. that's really wierd. Yes, check auditing.
I don't know if you already done this, but if you manually delete the dns records for that DC and run IPconfig /registerdns, are the DNS records created?
I hope that the information above helps you. This posting is provided "AS-IS" with no warranties or guarantees and confers no rights.- On some DCs that recreates the DNS records but on others it does not. On the ones that it DOES create them for, they often dissappear again within a day.. :(
