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
Joe GIT personalAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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.
Joe GIT personalAuthor Commented:
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;

set type=ns

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?
10 Tips to Protect Your Business from Ransomware

Did you know that ransomware is the most widespread, destructive malware in the world today? It accounts for 39% of all security breaches, with ransomware gangsters projected to make $11.5B in profits from online extortion by 2019.

Joe GIT personalAuthor Commented:
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.
Joe GIT personalAuthor Commented:
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.  

set type=ns
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.
Joe GIT personalAuthor Commented:
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?
You should only need UDP and TCP port 53.  Typically DNS queries are made using UDP 53, and can fall back to TCP 53 if unsuccessful.  Zone tranfers are made with TCP 53, and so are the queries to populate a stub zone.  Failure to populate a stub zone I think would most likely be due to blocking TCP 53.

Perhaps it's a matter of your home firewall/router not behaving as it should.  I know I've encountered that before (not matching this scenario though).

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
One more thing, you might try the following (from the work network).
set vc
          <-- this will force nslookup to use TCP
server x.x.x.x   <--use the public IP of your home
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.
Joe GIT personalAuthor Commented:
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.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2003

From novice to tech pro — start learning today.