Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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

The foo.org zone file contains the following (hostnames changed for security):

foo.org.        NS      ns1.foo.org.
foo.org.        NS      ns2.foo.org.
foo.org.        NS      ns3.foo.org.
foo.org.        SOA     [2010033275], ns.foo.org, admin.foo.org
ns.foo.org.     A       192.168.0.1
ns1.foo.org.    A       192.168.1.1
ns2.foo.org.    A       192.168.1.2
ns3.foo.org.    A       192.168.1.3

The bar.org. zone is as follows:

bar.org.        NS      ns1.foo.org.
bar.org.        NS      ns2.foo.org.
bar.org.        NS      ns3.foo.org.
bar.org.        SOA     [2010011842], ns.foo.org, admin.foo.org

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

What doesn't make sense to me, is why a request for "ns1.foo.org 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 foo.org 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

2 Answers 2

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 http://technet.microsoft.com/en-us/library/cc780434(v=ws.10).aspx.

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

 
discard

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.