Impact to removing child domain from Active Directory Integrated DNS??
Currently we have a root domain and four child domains (Microsoft Server 2003) and one of our domains is having issues with DNS. The question I have is what are the issues / impacts of removing that child domain from Active Directory Integrated domain wide and not making their zone Active Directory Integrated. They want to create stub zones for the other domains so that they can resolve if needed. I've never heard of a forest that has the root running ADI Forest wide and children running ADI Domain wide and then having one of them remove themselves from ADI. By the way, they were on the phone with Microsoft and this was their recommendation which fixed their DNS issue but once they came back into ADI it started all over again. By the way, the problem we are having on ALL of their DNS servers is EVENT ID: 7062.
So the question is, what is the downside to removing a child domain from ADI for DNS.
So the question is, what is the downside to removing a child domain from ADI for DNS.
The DNS server encountered a packet addressed to itself on IP address 205.110.101.37. The packet is for the DNS name "_ldap._tcp.TAQADDUM._sites.dc._msdcs.tq.mnf-wiraq.usmc.mil.". The packet will be discarded. This condition usually indicates a configuration error.
Check the following areas for possible self-send configuration errors:
1) Forwarders list. (DNS servers should not forward to themselves).
2) Master lists of secondary zones.
3) Notify lists of primary zones.
4) Delegations of subzones. Must not contain NS record for this DNS server unless subzone is also on this server.
5) Root hints.
Example of self-delegation:
-> This DNS server dns1.example.microsoft.com is the primary for the zone example.microsoft.com.
-> The example.microsoft.com zone contains a delegation of bar.example.microsoft.com to dns1.example.microsoft.com,
(bar.example.microsoft.com NS dns1.example.microsoft.com)
-> BUT the bar.example.microsoft.com zone is NOT on this server.
Note, you should make this delegation check (with nslookup or DNS manager) both on this DNS server and on the server(s) you delegated the subzone to. It is possible that the delegation was done correctly, but that the primary DNS for the subzone, has any incorrect NS record pointing back at this server. If this incorrect NS record is cached at this server, then the self-send could result. If found, the subzone DNS server admin should remove the offending NS record.
You can use the DNS server debug logging facility to track down the cause of this problem.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I would also be more inclined to fix the issue that exists because it may be symptomatic of other issues. Can you give us an idea of what types of DNS problems you're having?
Whoops...didn't read the snippet, I'll do that now.
Is the DC multihomed? DNS servers and DCs shouldn't be multihomed. Does the DC have a public IP address? That's not a best practice due to security issues.
ASKER
Zelron,
The DCs are NOT multihomed and all the IPs are not public, the reside behind a firewall that VIPs (NATs).
Chris,
The plan is to keep the root ADI Forest wide, do you have a problem with this? We currently only put resources on the root and no users reside on the root.
Tom
The DCs are NOT multihomed and all the IPs are not public, the reside behind a firewall that VIPs (NATs).
Chris,
The plan is to keep the root ADI Forest wide, do you have a problem with this? We currently only put resources on the root and no users reside on the root.
Tom
No problem, I always preferred that setup. I was just worried that the intent was to exclude the single child domain from that scope which gets a bit complex as you need to enlist a custom partition.
Have you tried comparing the standard primary zone with the ad integrated zone? DNSCMD /ZoneExport should be able to give you a plain old zone file for the AD Integrated zone.
Chris
ASKER
Chris,
My intent was not to exclude this child domain but my concern is it will no longer be part of the ADI and a secondary will need to be created for all domains to include the root. To be honest up until now I have never heard or used that command (learn something new everyday). Is there a method to the madnes in using this command and comparing the two?
Tom
My intent was not to exclude this child domain but my concern is it will no longer be part of the ADI and a secondary will need to be created for all domains to include the root. To be honest up until now I have never heard or used that command (learn something new everyday). Is there a method to the madnes in using this command and comparing the two?
Tom
> will not be part of the ADI
You won't be able to stop it unless you remove the DNS service from each Domain Controller and use a standalone server instead. At least not as long as it's Forest integrated.
If the server maintains access to the root zones you will not need to provide secondary or stub zones for the remaining child domains as they should resolve using the delegations in the root zone.
For the zone export, the most likely cause is a lame delegation, if we can find and remove the delegation the issue should go away. I'm concerned that when switching back to AD Integrated that it's loading the zone from the directory and resurrecting the earlier configuration.
Chris
ASKER
What's the easiet way to find the delegation if it exists?
Normally manually within the zone. Delegations are represented by greyed out folders in the tree. Even with the service records there aren't a huge number.
Alternatively we could use a script to tell us all the NS records within a given zone.
Chris