| T O P I C R E V I E W |
| teksrus |
Posted - 08/01/2006 : 2:20:25 PM
We have an empty root domain. The domain contains two Domain Controllers. All Domain Controllers use active directory integrated DNS and are a GC.
If we have to reboot a root domain controller to install patches etc, it takes hours or sometimes days for the domain controller to begin replication again.
The error messages seem to indicate that the DC can not perform DNS registration or lookup. The DNS server service is running but the but the server does not respond. Usually the DC will recover eventually and return to normal operation but the latency is unacceptable.
This does not occur with DCs in other domains, it only happens with the root DCs.
DCDIAG and NLTEST both indicate DNS failure.
Any idea of what could be causing this?
Thanks. |
| 30 L A T E S T R E P L I E S (Newest First) |
| teksrus |
Posted - 08/15/2006 : 07:50:00 AM
Ok. It makes sense to me now. Thanks to everyone for clearing this up for me. I truely appreciate the assistance!
|
| wkasdo |
Posted - 08/15/2006 : 06:49:45 AM
> Depends. Different people do it different ways.
Indeed...
> Personally, I will always *try* and point at one or two other DCs in the same site and then self as a last resort.
While I would do the reverse: point to self only after the initial replication has completed. This way you minimize DNS traffic and have no dependencies on other DC's. I don't really see the point of point of having a DC point to a secondary DNS at all. If the DNS service on that DC is down, the whole server including AD is likely to be in big trouble (with the exception of the startup issue, granted).
YMMV. |
| ptwilliams |
Posted - 08/15/2006 : 05:47:31 AM
> I apologize for my confusion.
Don't! It's our fault for hijacking your thread 
> or should there be an alternate also.
Depends. Different people do it different ways. One argument is if you point to self, and there's issues then there's likely issues with the DC therefore a redundant alternate is pointless.
Personally, I will always *try* and point at one or two other DCs in the same site and then self as a last resort.
|
| ptwilliams |
Posted - 08/15/2006 : 05:45:14 AM
> What do you think?
Good point. The problem as I see it is that we still have the chicken and egg error message re. not being able to read zone data because it can't find the AD because it can't read zone data. Only now it will take even longer as DNS isn't allowed to read AD until it replicates but it can't replicate without DNS (unless the other SP1 interesting find mentioned last week indeed works and pulls something from WINS/ broadcast).
So, I think what I'm saying here is that I would point to each other and then self as that will allow speedier boot times and less errors in the event log that can safely be ignored.
I think the latter point is an interesting one if you have monitoring software and people. People get lazy and start ignoring DNS errors because you get the error on boot. Before you know it there's an issue with DNS that no one flagged and the customer have experienced some downtime on a given site or sites.
|
| clarinathan |
Posted - 08/15/2006 : 01:51:09 AM
quote:
I need to initially point the DC to an alternate DNS (which was done when the domain was built) and then once everything has replicated, I should point it back to itself only??? or should there be an alternate also.
That would be what I would do; point to another DC, DCPROMO wait for DNS zone to replicate, point to self and then to another box (either in same site if there is one or in hub site) as secondary.
This topic got me thinking I wonder whether we should have a best practises section on the forums? |
| teksrus |
Posted - 08/14/2006 : 8:53:13 PM
Ok. Just to be sure I am clear on this.
I need to initially point the DC to an alternate DNS (which was done when the domain was built) and then once everything has replicated, I should point it back to itself only??? or should there be an alternate also.
I apologize for my confusion. |
| wkasdo |
Posted - 08/14/2006 : 4:31:49 PM
(apologies to teksrus for going OT here) Hmm. Not sure that this changes best practice. What this means is that initially you need the primary DNS client to somewhere else. But you need to do that anyway, or how else will you get the DNS data you need for the dcpromo? The only difference is that you need to wait a bit longer before changing it to self. Once the DNS zone is there, it won't go away.
What do you think?
|
| ptwilliams |
Posted - 08/14/2006 : 4:08:56 PM
Ha! I knew you'd ask...
Nothing that really explains this on the MSFT site other than:
-- http://support.microsoft.com/?id=836534
Which doesn't say much at all. Nothing (that I've found yet) in "the book of SP1" either!
The only info. is from one of the MSFT DS guys on ActiveDir.org:
-- activedir@mail.activedir.org/msg41105.html" target="_blank">http://www.mail-archive.com/activedir@mail.activedir.org/msg41105.html
There's a better reply than that on there, but I can't find it with Google and don't have access to the mails as they're on my laptop which I left in work...
|
| wkasdo |
Posted - 08/14/2006 : 2:37:33 PM
> There were some subtle changes to DNS in SP1 that make pointing to self less recommended
Interesting! Link? |
| teksrus |
Posted - 08/14/2006 : 2:18:57 PM
The design is basic, one empty root domain, two dcs, each in seperate site, AD intergrated DNS for single zone.
I was troubleshooting this based on this kb article.
http://support.microsoft.com/kb/291382
It says:
" In Windows Server 2003, the recommended DNS configuration is to configure the DNS client settings on all DNS servers to use themselves as their own primary DNS server, and to use a different domain controller in the same domain as their alternative DNS server, preferably another domain controller in the same site. This process also works around the DNS "Island" problem in Windows 2000. You must always configure the DNS client settings on each domain controller's network interface to use the alternative DNS server addresses in addition to the primary DNS server address."
When following the above recommendations, the problem is resolved. However, I am hesistant to add an alternate DNS server without knowing the residual side effects that it will cause.
|
| ptwilliams |
Posted - 08/14/2006 : 11:54:35 AM
> It was my understanding that a domain controller should only point to itself for AD integrated DNS.
I wouldn't say should only. Depending on the design, you can either only point to self (single DC at a branch office) but should have a backup (although in the cited example if you have an issue, you'll likely not use the backup), or you can point to another then self. I usually have the DCs point to an adjacent (within the site) and then self. You might want to point to two adjacent servers and then self.
There were some subtle changes to DNS in SP1 that make pointing to self less recommended. Now, DNS can't read any records from AD until it has replicated. This is an addon to the initial sync stuff that happens for the FSMOs. There should be some info. on this in the KB.
|
| wkasdo |
Posted - 08/14/2006 : 11:41:41 AM
> It was my understanding that a domain controller should only point to itself for AD integrated DNS.
You're right, it should. This points to a problem with the DNS service. Is it listening on all relevant NIC's? Is it starting properly? Relevant event logs?
It _is_ possible for AD to start earlier than DNS. This gives you one spurious eventlog message about not being able to load the zone data, but AD should recover immediately. Is that perhaps what you are seeing? |
| teksrus |
Posted - 08/14/2006 : 10:01:39 AM
If I add the IP addresses of the other root domain controllers as alternate DNS server entries in the IP properties of the server experiencing the issue. The problems go away. Is this an acceptable solution? It was my understanding that a domain controller should only point to itself for AD integrated DNS.
Thanks! |
| clarinathan |
Posted - 08/10/2006 : 3:10:48 PM
OK thanks Willem that is good to know.
Cheers
Nathan |
| joe_elway |
Posted - 08/10/2006 : 11:07:18 AM
quote:
Originally posted by wkasdo
> What is the recommended scavenging setup for AD Integrated DDNS on DCs?
The default interval is fine, usually. Watch out for long DHCP lease times, if you use DHCP to update DNS. Also, don't go much shorter then the default aging and scavenging periods. I think it was Aidan who had some interesting trouble with that.
Yeap. PSS were stumped. I think I wrecked the head of the poor guy. He probabaly had to be talked down from a balcony after dealing with me on that one. I had it down to 3 days, I think. Dang, that was a long time ago.
I'm pretty happy with default settings for DHCP leases and scavenging since then. It works and if it aint broke .... |
| Mark Minasi |
Posted - 08/10/2006 : 10:13:54 AM
quote:
Originally posted by ptwilliams
All in all, a rather interesting improvement. Just in time for the R2 re-write huh Mark?
Argh. Wish I'd known that. Too late, though; that puppy's almost at the printers. Great info, though, thanks Paul and Willem! |
| wkasdo |
Posted - 08/10/2006 : 09:57:19 AM
> What is the recommended scavenging setup for AD Integrated DDNS on DCs?
The default interval is fine, usually. Watch out for long DHCP lease times, if you use DHCP to update DNS. Also, don't go much shorter then the default aging and scavenging periods. I think it was Aidan who had some interesting trouble with that. |
| clarinathan |
Posted - 08/10/2006 : 08:20:57 AM
Hi Paul, not too confused!
Anyhow, something I have been meaning to ask for ages;
What is the recommended scavenging setup for AD Integrated DDNS on DCs?
Cheers
Nathan |
| ptwilliams |
Posted - 08/09/2006 : 08:59:32 AM
Note. The real island issue -that when the A record in DNS is wrong (old)- isn't resolved by my earlier post. My example of something that exhibits the same behaviour of the island issue in the even earlier post would be fixed if configured with WINS however...
Hope I've not confused anyone (other than myself)
|
| ptwilliams |
Posted - 08/09/2006 : 08:45:35 AM
OK. After an offline discussion with Willem, it would appear that as of SP1, it is now even more difficult to get the island issue. MSFT have changed the way a DC locates its upstream replica so that instead of failing to replicate if the DSA GUID (the DCs CNAME record in _msdcs.forest-root.com) can't be resolved, it now tries first the A record of the DC and then the NetBIOS name.
AD is also kind enough to log different events telling you which method it is using and offer suggestions.
This is documented here:
-- http://technet2.microsoft.com/WindowsServer/en/library/43e6f617-fb49-4bb4-8561-53310219f9971033.mspx?mfr=true
All in all, a rather interesting improvement. Just in time for the R2 re-write huh Mark?
|
| ptwilliams |
Posted - 08/08/2006 : 10:22:37 AM
I can envisage it being quite possible. For example, consider the following as a starting point:
Single domain controller at a remote branch with a 64K ISDN line.
Daft DNS Scavenging routine implemented on this box (and others).
Limited replication windows, e.g. Monday 1000 - 1400 and Thursday 1000 - 1400.
DNS Server points to self for DNS and main hub as a backup.
Now. With a really silly scavenging routine, due to a lack of understanding of DHCP, the necessary records could be pruned from the zone before replication occurs with the newer timestamps. This causes the island issue, as the only valid SRV records in _msdcs.domain-name.com are the local ones...
|
| Mark Minasi |
Posted - 08/08/2006 : 08:27:18 AM
Newsletter #31.
I should mention that Willem believes that Island DNS is still quite possible with 2003. I haven't seen it but that doesn't mean anything. |
| royal |
Posted - 08/07/2006 : 07:52:06 AM
Mark, do you know of an article that explains Island DNS well and tells why exactly a Windows 2000 DC causes Island DNS and why a Windows 2003 DC prevents Island DNS from happening?
Thanks! |
| teksrus |
Posted - 08/03/2006 : 08:58:52 AM
The domain controllers were at SP1 when the domain was created.
Thanks for the great suggestions regarding DNS. I will give them a try.
|
| Mark Minasi |
Posted - 08/03/2006 : 07:25:20 AM
Might work, interesting suggestion. Thanks!
Another thought... why not go to standard primary/secondary for a while and see if that sorts it out? If you're not spread across a lot of terrible WAN links and don't expose your domain zones to the Internet then I can't see the problem. |
| Imad |
Posted - 08/03/2006 : 01:37:41 AM
Did this behavior start after applying SP1?
You can try the following:
1. Stop the Netlogon service.
2. Rename the Netlogon.dns file to Netlogon.old, and then rename the Netlogon.dnb file to Netlogon.old2.
Note Netlogon.dns and Netlogon.dnb are located in the Windows\System32\Config folder.
3. Start the Netlogon service or restart your computer.
If the problem still persists and since DNS is AD integrated, remove DNS service from first DC and reinstall it again. At a later time repeat the process on second DC. All DNS entries are preserved since it's AD integrated.
Good Luck |
| teksrus |
Posted - 08/02/2006 : 11:26:38 AM
They are all running Windows Server 2003 SP1. The errors in the logs are:
Userenv 1053
NTDS KCC 1865,1311,1566
DNS 4001,4013
NTFRS 13508
Netlogon 5781
LSASrv 40960
Thanks |
| Mark Minasi |
Posted - 08/02/2006 : 10:39:46 AM
I didn't see whether or not it was 2000; 2000 DCs that point to themselves for DNS on AD-integrated root domains can suffer from "Island DNS." |
| netmarcos |
Posted - 08/01/2006 : 4:47:45 PM
Are there any errors in the event log that correspond to this problem? And is it possible that the DNS service is not starting up fully before the domain is loaded? Have you tried assigning a secondary DNS server to one or more of the affected DCs as a test? |
| teksrus |
Posted - 08/01/2006 : 2:48:26 PM
Each DC points only to itself.
|
