Zone x-fer event 6525 "refused" error happens frequently

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

But not always. Yes, the zone transfer permissions are set. It's actually
set "To any server" I thought it was the throttling thing at first until I
read that it was only on the primary DNS. This is actually a secondary zone
re-sharing to other DC/DNS servers. Basically it's an AD forest and this is
the child DC acting as the "representative" of that root DNS zone to the
rest of the DC/DNS's in the child domain. The root admins asked us to do it
this way so that they wouldn't have to maintain the zone transfer IP address
list every time we add a new DC. In my case, I'm shameless I just say "To
any server" just to cut down on these types of problems and to eliminate
another step I have to remember when promoting a DC. So, it's a secondary
of a secondary. In any event, the SOA is just fine on the root, child
"representative" and all the other child DC/DNS servers. It works, they all
get the zone transfers and they're all up to date, but I still get these
6525's all the time. I'm in a 2000 SP4 AD/DNS environment. I haven't
really attempted to fix it because in reality it does work, but I'd like to
silence these 6525's.

Any ideas?
 
In
- said:
But not always. Yes, the zone transfer permissions are set. It's
actually set "To any server" I thought it was the throttling thing
at first until I read that it was only on the primary DNS. This is
actually a secondary zone re-sharing to other DC/DNS servers. Basically
it's an AD forest and this is the child DC acting as the
"representative" of that root DNS zone to the rest of the DC/DNS's in
the child domain. The root admins asked us to do it this way so that
they wouldn't have to maintain the zone transfer IP address list
every time we add a new DC. In my case, I'm shameless I just say "To
any server" just to cut down on these types of problems and to
eliminate another step I have to remember when promoting a DC. So,
it's a secondary of a secondary. In any event, the SOA is just fine
on the root, child "representative" and all the other child DC/DNS
servers. It works, they all get the zone transfers and they're all
up to date, but I still get these 6525's all the time. I'm in a 2000
SP4 AD/DNS environment. I haven't really attempted to fix it because
in reality it does work, but I'd like to silence these 6525's.
Any ideas?
Click to expand...

Do the DCs have multiple un-teamed NICs?
Is UDP 53 open?

--
Regards,
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT,
MVP Microsoft MVP - Directory Services
Microsoft Certified Trainer

For urgent issues, you may want to contact Microsoft PSS directly. Please
check http://support.microsoft.com for regional support phone numbers.

Infinite Diversities in Infinite Combinations
 
Multiple NIC's yes but 2nd NIC is disabled. UDP 53, ok I must confess my
ignorance how can I check if this port's open?
 
In
- said:
Multiple NIC's yes but 2nd NIC is disabled. UDP 53, ok I must
confess my ignorance how can I check if this port's open?
Click to expand...

Is there a firewall between the Primary and the secondary that zone
transfers must go across? If so, check the firewall.

Now if there is no firewall, and you are trying to zone transfer a zone that
is already in the AD database, assuming the zone is AD integrated, then I
can see why you would be getting problems.

If so, what server is the "primary" for this zone? Is it a DC? Does the zone
already exist on a DC/DNS? Your original description is somewhat skewed and
I apologize, but I am having difficulties understanding the infrastructure
and environment.

Can you state specifically what DNS servers you have, are the DCs, are the
DCs part of the same domain, are the zones on the DCs AD integrated and if
so, what replication scope are they set to, and what server is transferring
to what other server and if the zone exists in AD.

Ace
 
Hi Ace,

The zone is not AD-integrated in our root, though in our child domains they
are. So, primary DNS of the Root zone is shared to one IP address per child
domain, which then re-shares its secondary zone of the root to the other
DC/DNS servers in its domain. We have no firewalls internally, only our
main external firewall. It's basically like this:

root.org (zone is non-AD integrated, and shared to
children)
\|/
DC1.child.root.org (DC/DNS in this child domain hosts its own
AD-integrated zone as well as the zone of its parent
\|/
root.org --> DC2.child.root.org,
--> DC3.child.root.org
--> DC4.child.root.org

DC1.son.root.org (DC/DNS in this child domain hosts its own AD-integrated
zone as well as the zone of its parent
\|/
root.org --> DC2.son.root.org,
--> DC3.son.root.org
--> DC4.son.root.org

Hope that makes sense, never did ASCII art. for DC2-4, it ends up being a
secondary of a secondary. DC1 is the "rep" for that root zone, for all the
other DC/DNS's in the respective domains.
 
In
- said:
Hi Ace,

The zone is not AD-integrated in our root, though in our child
domains they are. So, primary DNS of the Root zone is shared to one
IP address per child domain, which then re-shares its secondary zone
of the root to the other DC/DNS servers in its domain. We have no
firewalls internally, only our main external firewall. It's
basically like this:
root.org (zone is non-AD integrated, and shared to
children)
\|/
DC1.child.root.org (DC/DNS in this child domain hosts its own
AD-integrated zone as well as the zone of its parent
\|/
root.org --> DC2.child.root.org,
--> DC3.child.root.org
--> DC4.child.root.org

DC1.son.root.org (DC/DNS in this child domain hosts its own
AD-integrated zone as well as the zone of its parent
\|/
root.org --> DC2.son.root.org,
--> DC3.son.root.org
--> DC4.son.root.org

Hope that makes sense, never did ASCII art. for DC2-4, it ends up
being a secondary of a secondary. DC1 is the "rep" for that root
zone, for all the other DC/DNS's in the respective domains.
Click to expand...

Much clearer! Thanks. Your ASCII art looks fine. :-)

Ok, let;s see, a master sends to a secondary, which is a master for another.
This is the only times it happens? Not sure what is going on, for I never
did it this way, but it may point to a timing issue when the master
secondary is receiving from it;s master while it;s secondary is trying to
pull data? Usually I would make replicate the root zone Forest wide (unless
we're delegating child domains' zones) along with it's delegated
_msdcs.domain.com zone (which is forest wide by default). Is that zone under
the root zone or separate?

Now you got me curious, what was the intention behind this design?

Thanks,
Ace
 
It was done that way because the root admins got sick of us child domain
admins asking to have the IP of our new DC/DNS's added to their zone
transfer list. In fact is is a better way because this way the child
administrators can pretty much handle their own shops without the need to
involve the root admins.
 
In
- said:
It was done that way because the root admins got sick of us child
domain admins asking to have the IP of our new DC/DNS's added to
their zone transfer list. In fact is is a better way because this
way the child administrators can pretty much handle their own shops
without the need to involve the root admins.
Click to expand...

In that case, a parent-child delegation would be the better 'best practice'
for such a scenario. THis is a very common design in multiple
administrative-delegated child domains scenarios such as yours. Are you
familiar with this design? It still allows AD Integrated zones for increased
security for zone data, eliminate the need for legacy zone transfer designs
(eliminating zone transfer issues as you are experiencing) as well as allow
the child zones have FULL control of their own zone.

Basically in the root zone, Rt-click choose delegation, and give it the name
of the child domain and the child domain DC/DNS servers. In the child domain
DNS servers, forward back to the child In the parent, forward out to the
ISP. This allows any queries for the root zone to be forwarded up as well as
Internet queries which the root DC/DNS servers will forward outbound. The
parent root zone replication scope would be set to DomainDnsZones (the
middle button) as well as the child zone on the child DC/DNS server(s). The
_msdcs.domain.com zone would still be set to ForestDnsZones rep scope (the
top button). By the way, the _msdcs zone is already delegated from the Root
zone to the root zone DC/DNS servers by default.

Of course all DNS servers must be DCs for AD Integrated zones.

Clean, secure and it works.

Some info on it:

Delegating zones
http://technet2.microsoft.com/windo...9031-480b-a41d-e350d00882011033.mspx?mfr=true

How To Create a Child Domain in Active Directory and Delegate the DNS
Namespace to the Child Domain
http://support.microsoft.com/kb/255248



I hope this is helpful.

Ace
 
Thanks Ace,

I am going to read the zone delegation articles you provided. We'll see if
it's in there somewhere. Thanks again for you assistance.
 
In
- said:
Thanks Ace,

I am going to read the zone delegation articles you provided. We'll
see if it's in there somewhere. Thanks again for you assistance.
Click to expand...

Sounds good. If you need assistance with design questions, please feel free.
I'm sure others may have more to provide, but I mentioned the basic
fundamentals of the design.

I am curious about which direction you will go with your design.

Ace
 
Back
Top