Link to home
Start Free TrialLog in
Avatar of Joe G
Joe GFlag for United States of America

asked on

DNS stub zones Windows server 2008 and 2003, constant event id 6522 but nothing loads

I am going through a email hosting setup.  I've been having problems with them and currently we are in the classic "its you" debate.  They require us to allow them access to our AD/DNS so they can create a Stub Zone.  Since we are back and forth I've started to duplicate their steps in hope I can find where the issue is.  There are a few questions and maybe they are all related.  At least I hope.  

I've setup my home router to allow all DNS traffic 53 (udp/tcp) to my home environment (dubbed home.local domain which is a 2008 Server R2).  I created a stub zone in the work environment (dubbed work.local domain which is a 2003 Server) and I am able see my home.local and all NS records via the DNS mmc in the work environment.  However I cannot ping the FQDN of my home.local AD/DNS server from work.local.   I can see the DNS records of a stub zone in the DNS mmc but no ping resolve to the FQDN of the home.local AD/DNS in my work.local domain.  Any ideas?  

Now on the other side of the testing the reason I'm going through all this, I tried the reverse and I was able to create a stub zone of my work.local in my home.local AD/DNS BUT I never get the stub zone to load the records of the work.local AD/DNS domain even in the mmc.  Event logs keep saying 6522 "new zone work.local found" "transferring zones" but it's been saying that for hours now and the event 6522 keeps being recorded and piling up.  Any ideas?

steps I've tried to resolve this;
I've went through adsi edit already to remove any CNF.
I've allowed zone transfers on both side; single and any
Avatar of footech
footech
Flag of United States of America image

In the stub zone home.local what are the records like?  Do they point to public IPs?
I suggest you test with nslookup to verify that the records are resolving correctly.  Then you can use ping, but keep in mind that ICMP traffic has to be allowed as well.

Just troubleshoot one side to avoid confusion.

Zone transfers are not required for stub zones, only for secondary.  But as I said, let's just focus on the other side.

I can't imagine a hosting scenario where they need access to your internal DNS.  Maybe you should just describe the root problem that you're trying to solve.
Avatar of Joe G

ASKER

Ok. lets keep the focus on one side.  A stub zone will not load work.local on my home AD/DNS home.local.  

In the stub zone of my work.local in my home.local AD/DNS I have nothing but an Error saying "Zone Not Loaded by DNS Server"  I was getting event 6522 all day yesterday with nothing to show for it on my DNS mmc now I'm seeing a event 6523 "Zone work.local failed zone refresh check" from late last night till early morning.  

NSlookup fails when I try to query NS records in my home.local domain of the stub zone work.local
I've done this;

nslookup
set type=ns
work.local

then I get error outs.  cannot find.  

The root problem I'm having is our hosting site requires access to our NS records via stub zone(for what I'm not sure) and cannot continue with out it.
It'll be easier to focus on the other side (your work domain where you have a home.local stub), as this appears to already be set up.
In the stub zone home.local what are the records like?  Do they point to public IPs?

Your hosting site should be able to clearly explain why they need access.  It is unusual for a third-party company to need access to internal records, or maybe I am misunderstanding their request.  Do they want you to create a stub zone on your DNS that points at their name servers, or do they want to create a stub zone on their own DNS which pulls from your name servers?
Avatar of Joe G

ASKER

from the stub zone home.local in the work domain I see NS records that point to my internal IP's of my home domain.  No public.  

I will ask my hosting site why they need access.  They want to create a stub zone on their own DNS which pulls from my work.local name servers.
Make sense.  I assume that when you were creating the stub zone that you had to put in the public IP of your home network as the master server.
Can you try an nslookup command for a record which should be in the home.local DNS?  This should work.
But unless you have something like a direct VPN tunnel between the networks with appropriate routing, you won't be able to ping those private addresses from your work network.
Avatar of Joe G

ASKER

Yes I used one available public IP that I NAT'd to my home AD/DNS server but I'm not able to successfully test nslookup in my work.local to a record in the home.local even though the stubzone appeared to load correctly.  Not sure why.  

nslookup
set type=ns
home.local
You might try setting debug mode in nslookup (set debug), and also using a trailing dot for queries of a FQDN (complete name).
Other that, I would do a network capture and look at DNS traffic. That's about all I can suggest.
Avatar of Joe G

ASKER

Footech - don't give up on me yet :)

I made some headway which now created another question.  During the test I opened ports 53, 389 and 3268 both TCP/UDP from the home.local firewall to the internal AD/DNS and I was having these issues.  When I opened ALL ports to my home AD/DNS and reloaded my stub zone I am now able to query the home.local stub zone from my work domain.   NSLOOKUP worked.  Other than 53 is there any other ports I should consider to allow for stub zone to work across the internet?
ASKER CERTIFIED SOLUTION
Avatar of footech
footech
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
One more thing, you might try the following (from the work network).
nslookup
set vc
          <-- this will force nslookup to use TCP
server x.x.x.x   <--use the public IP of your home
whatever.home.local.
See if the query is successful (should be with your latest success).  Then if you set the home firewall back to just allow TCP and UDP 53, perform the steps again and observe the results.
Avatar of Joe G

ASKER

Thank you for the time.  It must be the settings in the work.local firewall/router.  I am able to successfully connect via stub dns from my work.local to my home.local (home.local firewall is a basic Cisco RV small business model) but not through the 2911 cisco series at the business hub site.  I'm going to get a second opinion on my firewall/router settings.