Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have two stub zones in my DNS database (both AD-Integrated). Let's call them and All DNS servers on my side are Server 2003 R2.

The zone file contains the following (hostnames changed for security):        NS        NS        NS        SOA     [2010033275],,     A    A    A    A

The zone is as follows:        NS        NS        NS        SOA     [2010011842],,

The main issue we're running into is that requests for A records in the zone often return SERVFAIL. Looking into it a bit more, I found that a request for " A" returned NXDOMAIN. I believe this is causing the failure to query for lookups in the zone.

What doesn't make sense to me, is why a request for " A" would result in an NXDOMAIN response when I can see that the record exists the in the zone database.

share|improve this question
Does a query for the zone's NS records return the A records as extra data though? The stub server probably went looking for an authoritative answer to the A query.. is it having a hard time getting those queries answered - maybe one of the three authoritative servers is misbehaving? – Shane Madden Feb 8 '12 at 16:31
What's the nameserver(s) of the client that's failing? – Reece45 Feb 8 '12 at 17:59
The clients I'm troubleshooting are using the nameserver of our PDC emulator. Also, I can see that the PDC emulator is receiving a bad response from upstream DNS servers. It's also querying our ISPs nameserver somehow; who knows how that's happening. It looks like I have a lot to look into. – bshacklett Feb 8 '12 at 18:32
Update, it's not our ISPs nameserver that it's querying. It's the external nameserver for the domain. Somehow the DC is deciding to perform a full recursive lookup rather than using the name servers listed in the zone file. – bshacklett Feb 8 '12 at 23:56

Try to capture network traffic, or look at your firewall logs from the time you performed a lookup. If the query goes to a public root server, the .local tld would probably result in an "NXDOMAIN" result.

Provide logs or screencasts/output of manual lookups (like with nslookup or dig), if you need more help

share|improve this answer
I'm sorry, I was using .local as just sort of a placeholder. I guess there's no reason to do so. The actual tld is .org. – bshacklett Feb 8 '12 at 16:38
Then that is clearly not the issue :-) As said, please provide more details for more detailed answers – Mathias R. Jessen Feb 8 '12 at 16:39
up vote 0 down vote accepted

From what I can tell, we should not be using stub zones in our current situation, and I plan to switch to using conditional forwarders.

Microsoft has an article regarding the usage of stub zones and conditional forwarders at

In this article, it states "In situations where you want DNS clients in separate networks to resolve each others' names without having to query DNS servers on the Internet, such as in the case of a company merger..."

The article goes on to say "Stub zones are used when you want a DNS server hosting a parent zone to remain aware of the authoritative DNS servers for one of its child zones."

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.