DNS and SOA

The answer depends on how your zones are configured.  The SOA record should point to a server that holds a writable copy of the zone.  So if your zones are AD-integrated, the SOA record on each DC/DNS server will point to itself, because the zone is writable on every DC.  If the zones are not AD-integrated, only one copy of the zone is writable (the primary copy), and the SOA record on each DNS server will point to the server holding that copy.

Single forest.  Got it.  Single domain?  The "DC1/DC2" duplication across sites is a little confusing.  All 4 DCs have different names, right?  Also, you know there's no "master" DC, right?

If I'm missing something, help me out...

Otherwise...

Are your DNS zones AD-integrated (we're talking about the forest/domain zones, right)?  Each DC should be it's own SOA.  The domain zone should be configured as shown on each server (assuming you have only 2003 or newer DCs).


If the zone is missing from one DC, ensure all the rest are showing the correct config.  If you're still having problems, post back w/more info.

Hope that helps!

Ok so a little more clarification on my part. Yes we are AD integrated, Replication is All domain controllers in the AD Domain. Yes I understand that there is not a master DC but that is what we call the forrest DC in the UK. Its single forrest, multiple domains, we manage Domain "Test" which has two sites, A and B. This domain we manage, its DNS is totally gone from the forrest and any other domain within the forrest which has caused problems for our email, and users that log into Terminal servers outside of our domain, because they can not validate their user accounts becasue the other domains can't find our DC's.

Site A
DC1
DC2

Site B
DC3
DC4

We have tried to get our IT dept in the UK to delete our zone and re-add it but they won't do that. We have already demoted and re-promoted DC1. Our SOA in Site A was all pointing to DC1 and in Site B was all pointing to DC3. Should they all be pointing to DC1 or is there something else we are missing?

Since the zones are AD-integrated, the SOA records on each DC should be pointing to themselves.  If the zone is totally missing from all of your DNS servers, however, you're going to have no choice but to recreate the zone or restore it from a backup.

OK, so you have one domain with this problem, and the domain's DNS zone is missing.  From all servers.  Period.  Am I getting warmer?

Here is info on performing a restore of the DNS partition to AD.

http://blogs.technet.com/b/networking/archive/2007/05/10/oops-our-ad-integrated-dns-zone-s-are-missing-in-windows-2003.aspx

That should fix your problem.

Oh, and yes - each DC should point to itself.  Your problem is deeper than that.  If the zone isn't visible on any server, then it's gone.  Restore from backup.  That should also fix the SOA pointer problems.

But I'm confused... how do you have an SOA in a missing zone?  Have you manually recreated and *empty* zone?  Missing should mean "missing" - as in "there's no zone here in the DNS management console."  In that case, what SOA are you referring to?

Yes, there are upwards of 20 domains in the forest. Our domain is the one that cannot be resolved from any other domain. Red-Hot. We have asked the IT dept that handles the master DC to delete and recreate the zone but they keep telling us to do other things. So our solution looks like that is what they will have to do, so that our zone replicates down to all of the other domains DNS servers?

On our DNS servers the zone is still there so we see everything like it should. We have the ability to log into one of the other domains and when we look at that DNS servers zones and browse to ours, its not populated. The folder is there, but when I look in the folder all I see is the NS's, the list of 350 computers and 30 servers are no where to be found.

We haven't done anything on our end to our DNS zone, other than the demotion and promotion of DC1.  

The zone is there but its basically empty, or not having the correct DNS entries for our zone, I guess would be the best answer.

Ah... so the zone is not *lost*.  And your DNS servers = your DCs?  

Sounds like AD replication issues.  It also sounds like you can only troubleshoot your own domain - not the forest, right?

There might still be a restore that needs to happen, but it would be on their end.

Have you re-validated your FSMO roles since doing the DC1 demo/promo?

Any errors in the logs re: DS sync?

DNS servers in other domains shouldn't contain your zone at all, as those servers aren't authoritative for your zone.  The exception to this rule would be a stub zone, which is a partial zone that serves only to indicate the true authoritative servers for a particular zone.  It sounds like that's what those other DNS servers are actually doing, although if the zones on those servers only contain NS records, they're missing a couple of things (an SOA record and glue records for the NS records).

More information on stub zones is here:
http://technet.microsoft.com/en-us/library/cc779197%28WS.10%29.aspx

I personally prefer conditional forwarders, but stub zones will do essentially the same thing.

Sure I am up for anything, NSLOOKUP of something in our domain, or to another domain?

From a computer (DC or otherwise) that is not using your DCs as DNS servers (computer domain membership is not relevant), do NSLOOKUP -type=ns brokendomain.com

If that works, do NSLOOKUP dc1.brokendomain.com (against each of the four DCs in brokendomain).

If that works, do NSLOOKUP somehost.brokendomain.com

Where are we now?

When I do the NSLOOKUP -type=ns from one of the other domain we have access to, to our domain it resolves all the NS's in our forest.

NSLOOKUP -type=ns DomainA(SiteA and SiteB).forest.net from Domain B.

Now you want me to do NSLOOKUP NSLOOKUP -type=ns DC1.DomainA(SiteA and SiteB).forest.net from Domain B, correct?

"BrokenDomain" = you.  You wanna be DomainA?  Fine by me.  From here on in, let's call you DomainA.  Let's just call the forest Forest.  

So... let's look at the servers.

dc1.DomainA.Forest.net (located at SiteA)
dc2.DomainA.Forest.net (located at SiteA)
dc3.DomainA.Forest.net (located at SiteB)
dc4.DomainA.Forest.net (located at SiteB)

The domain you test from doesn't matter.  It's the DNS servers that matter.  So, I'll assume that when you say "from one of the other domain[s]" you really mean "from a computer not using DomainA's DC/DNS servers for name resolution."  Presumably any computer not at SiteA or SiteB.  If that's *not* what you mean, then we need to back up a step.

Let's look at what we've already discovered...

NSLOOKUP -type=ns DomainA.Forest.net

...returns "all the NS's in our forest."  All of them, including those in DomainA.Forest.net?  Or just the rest of the Forest.net domain servers?

I think we've already got a problem here.  If DomainA.Forest.net isn't set (on DC1-4) to replicate to "all DNS servers in the Forest," then those servers should not be advertising themselves as name servers.

But sure, do this next...

NSLOOKUP dc1.DomainA.Forest.net
NSLOOKUP dc2.DomainA.Forest.net
NSLOOKUP dc3.DomainA.Forest.net
NSLOOKUP dc4.DomainA.Forest.net

Based on what you've said thus far, I expect that will work.

Finally, do this...

NSLOOUP somehost.DomainA.Forest.net

It'll probably break on the last one. Because non-domain name servers in the forest think they're authoritative for the domain.

Is there any reason you can't set DomainA.Forest.net to replicate to all DNS servers in the forest and be done with it?  I think that will solve your problem, but I don't have a clear understanding of your administrative boundary.

Yes I mean from another computer not using DomainA's DC/DNS.

Attached is the output from the original NSLOOKUP Command.

We have our DNS set to replicate to All domain controllers in the AD Domain, which is different from all DNS servers, becasue a DC is not always DNS, correct? We have the authority to change our DNS and anything administratively on our Domain, but not on any other domain. So if we change the replication from "All DC's on the domain" to "All DNS servers on the domain", you think that may solve our problem?
NSLOOKUP.txt

Next Step: nslookup -type=ns dc4.domainA.forest.net

Server:  dc1.domainB.forest.net
Address:  192.168.xx.10

domainA.forest.net
        primary name server = dc4.domainA.forest.net
        responsible mail addr = hostmaster.domainA.forest.net
        serial  = 37422
        refresh = 900 (15 mins)
        retry   = 600 (10 mins)
        expire  = 86400 (1 day)
        default TTL = 3600 (1 hour)

I get this for each of the four DC's on my network, when the command is ran.

Wow...that's a lot of NS records.  This doesn't seem like the most efficient way to do it, but if you truly want every DNS server in the entire forest to host that zone, you should indeed configure the zone's replication scope to be "All DNS servers in the forest."  The alternative would be to delete the NS records corresponding to servers which aren't actually authoritative for the zone.

Your second query (of Sxxbackup.Sxx.forest.net) - is that "Sxxbackup.DomainA.forest.net"?  Please don't use the -type=ns for the host lookup.  Just use -type=A or (even better) don't specify type.  We're trying to see if the current configuration can resolve hosts - if it can, then DNS is working (maybe those are stub zones out there in the forest).  If DNS is working, then you're troubleshooting a non-problem.

What you really have is a login problem, right?

So... if you're sure that the zones you see on non-DomainA DNS servers are *not* stub zones created by the forest admins to hold glue records, and you're sure that those zones *should* contain all the information in your DomainA zone, then read on about changing the zone replication...

Do you have any Windows 2000 DCs in the domain?  You are correct that a DC is not always a DNS, but this setting is to support legacy Win2000 DCs.

If you're Win2k DC-free, then I'd change it to "all DNS in the forest"  - forest, not domain.  This would appear to be what the *other* servers in the forest think is going on (or they wouldn't have DNS zones for your domain at all, or maybe stub zones if they were setup explicetly to handle this task).  Setting replication to all DNS servers in the forest will update the DNS Partition for your domain in AD, which should in turn replicate to all the DNS servers in the forest.  That in turn will replace their empty/malformed domains with the *real* domain.

Oh, and for goodness sake make sure you've backed up *all* of your AD domain and name partitions first!

"Sxxbackup.DomainA.forest.net" is another domains server. And the second part of the text file is part of the output from the NSLOOKUP -type=ns domaina.forest.net command.

The problem is exchange servers outside our domain and forest can't see our exchange server, and yes loging in because there is no DC to validate credentials, becasue it can not be found.

Yes we are Win2000 free.

We tried to make the change to "all DNS in the forest" but we get this error, attached.  

That happened after we were told to demote our DC1 and repromote the server back to a DC.

Sorry we are just getting back to this now. The issue was resolved at the forest level, by removing our zone and having it replicated back to the main DNS server at the forest level. thanks for all of your help.

I awarded both of you half points for all yoru help and guidance, and both having the same solutions. Thank you.