DNS Query

[BruceTea]

As there are a few techies on here, I thought I'd see if anyone has any insight on the below issue.

2 MS Domains, a forest root (aa.local), and a child domain (bb.aa.com)

aa.local has 2 DC's with AD Integrated Zones set to replicate with all DC's in that domain. DNS is installed on both. This is an empty root as per MS best practice with nothing other than the 2 DC's in there.

bb.aa.local has 3 DC's, DNS on all, AD Integrated Zones set to replicate with all DC's in that domain. A stub zone has been created to point to aa.local to allow complete resolution.

Originally I had DNS set to AD Integrated in all domains and set to replicate at forest level but this was causing a 15 min logon when rebooting a DC. After attending a Microsoft course, the instructor actually changed the settings to the those above which resolved the logon issue.

Everything seemed to clear down and dcdiag showed as being clear.

Unfortunately now, when I reboot dc1 in bb.aa.local, it takes 15 mins to log on but DNS fails to start with error codes ranging from 4000, 4004 and 4015. As they are AD Integrated, this obviously has a knock on effect with other services starting such as AV, ADUC which all use Active Directory accounts.

If I leave the server for 10 mins, DNS finally starts! Rebooting the other DC's in that domain are fine, as per the root domain. The only thing I've done is removed Symantec AV and installed Kaspersky across the domain.

I'm completely stuck and am looking for ideas!

Thanks

 

[Cookie]

Googled for those error codes for info?

 

[BruceTea]

Yep, but they are more regarding events occuring because the DNS is not running, rather than why DNS is failing to start

 

[BruceTea]

OK, so just tried setting primary DNS to one of the other DC's and removed all other DNS IP's and its come up fine. Was originally pointing at itself so deffo looks like an issue with this particular box rather than the whole DNS infrastructure.

 

[DMS]

Seen a similar thing before when the SRV records were missing from the forward lookup zone. If the server is using itself as the primary DNS server and it doesn't have a copy of them in the zone it may not know where to send LDAP queries or get kerberos tickets.
Try running "netdiag /fix" and "dcdiag /fix" on the server.
Failing that, if you can't figure out what's causing the problem and you don't have issues on any of the other DNS servers (check the event logs), you could start in Directory Services restore mode, do a non-authoritative restore from your most recent working backup of the server, restart again and allow the stuff in AD with higher USN's to replicate back.

 

[BruceTea]

Thanks Darren, I've tried Dcdiag/fix to no avail but not netdiag - I dont have backups at the moment as this is just the start of a new domain so nothing really running on it.

Worst case scenraio may be to transfer FSMO roles and remove the DC then rebuild and rejoin but I really want to avoid this.

 

[DMS]

Just a thought....

Is the server holding the Infrastructure Master role? And if so, is it also a Global Catalog server?
You shouldn't have both roles on the same server unless you only have a single DC because of how replication works. The NTDS.DIT file doesn't always get updated when attributes change IIRC (including DNS stuff) so you can end up with issues all over the place. Probably nothing to do with your issue but might be worth checking.

Rather than uninstalling AD you could just uninstall the DNS service and reinstall it. It should pull the zones from AD?

 

[BruceTea]

To be honest, having the empty root domain has caused nothing but issues so I took the decision (maybe stupidly) to flatten the domains and rebuild - it was only in its infancy with no users yet set up. Just rebuilding now.

Thanks for your help though - that could well have been the issue. I remember seeing that the Infrastructure role holder couldnt be a GC unless all DC's in a single domain were a GC so I set them all as GC's; probably a mistake given the parent/forest root :S

I'm hoping that the single domain will be a lot simpler.

 

[@Spoonie]

Any other events logged apart from the DNS ones?

 

[cava83]

Single domain is the way forward for most scenarios.

Let us Know how you get on,

G.