Prevent/Block DNS Replication

FNDAdmin
FNDAdmin used Ask the Experts™
on
Hello,

    One of our peer domains has turned off DNS replication on one of their servers. This is fine for them but one of my domain controllers has selected their server as a replication partner. My domain controller is spewing out KCC and DNS Replication errors. (1925/1926/2042)

    I have tried repeatedly to remove the non-replicating domain controller from my DNS list but it keeps re-appearing. Please help
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
I am asssuming that this is an Active Directory integrated zone, since you are getting KCC errors.
You can prevent the replication of this DNS zone beyond the Domain level by changing the Scope opion on the General tab of the Zone Properties dialog box.

Options are:

All DNS servers in the Active Directory forest
All DNS servers in the Active Directory domain (Default for 2003 Server)
All Domain Controllers in the Active Directory forest
All domain controllers in a specified Application Directory Partition

If your DC is trying to replicate DNS zone data to another peer domain in a forest, my guess is that your scope is set to the first one. Changing the scope to the second and default option should prevent this behavior.

Further reading:
http://technet.microsoft.com/en-us/library/cc779655(WS.10).aspx

Hope this helps.

Good luck

Bjorn



Author

Commented:
Would option two "All DNS servers in the Active Directory domain (Default for 2003 Server)" prevent my DC from replicating with ALL other Peer Domains?

...and Yes we are an Active Directory integrated zone..
The scope setting is for the AD integrated DNS zone applies to the Zone you configure it for and would prevent that DNS-zone from being replicated beyond the scope you configure. That would, for that zone only, mean that any other DNS servers in Peer Domains on the forest would not get the zone data either.

If this is not your AD DNS zone, then I would rather use a Standard Primary Zone and configure DNS replication via standard secondary zones, which would let you control much more precisely which DNS servers got the zone and which didn't.

I am a bit curious as to your setup. Could you elaborate on how the AD structure is configured?
Do you have a mixture of primary / secondary zones and AD integrated zones or is everything AD integrated?

And why and how have admins for the peer domain blocked replication of the DNS zone data?

Bjorn
Exploring SQL Server 2016: Fundamentals

Learn the fundamentals of Microsoft SQL Server, a relational database management system that stores and retrieves data when requested by other software applications.

Author

Commented:
Hi Bjorn,

Unfortunately, DNS is not my strong point, or even something I truly understand fully. I just have not dedicated the time to understand it properly. I had someone else from our main computing services set it up for us. The way our AD structure is setup is that there is an 'empty root', and all domains throughout the campus are peer domains. This way no department has control over anyone else, per say.

The server with which I am having problems replicating with is one of our main computing services domain controllers. They specifically have replication turned off on this server because they do not want it being updated by anyone else's DNS Servers.

 I just want to prevent my DNS server from replicating, or failing to replicate, which this one particular server.
Ok - I'll just explain briefly the workings of DNS so that you understand what you are doing.

DNS is in principle very simple. You have a server that translates user friendly (more or less) names into IP addresses so that humans, and machines, do not have to know the actual IP address of the machine they are connecting to. Since IP addresses do not have a hierarchical structure, and DNS has, the technology makes larger networks possible to navigate without memorizing millions of IPs.

Now, the DNS servers themselves are pretty simple in operation. Each DNS server has a number of Zone files, which in the original DNS implementation is nothing more than a txt file (called standard zones in Windows Server) which the DNS server then uses to answer queries. If a DNS server has a zone file for a certain domain, it assumes that it is authoritative for this zone and will not query any other DNS server for IP addresses for a host in that zone.

A server who do not have the zone itself, will attempt to do a lookup for the relevant entry in the zone file of another DNS server who is authoritative for the zone (which just means it has a zone file for the dns namespace) and when it receives a reply it will forward the reply to the client who sent the query and also cache it for future reference. I will just briefly sketch how a query goes for the host www.fubar.org.

DNS servers queries the DNS root servers for the authorative DNS servers for the .org namespace, and receives a NS record in reply with IPS for servers that host that zone. Then it queries the org namespace serers for the NS records of fubar.org to find the DNS servers that hosts this zone. It again receives a NS record witht the ip addresses of the fubar.org dns servers. It finally queries the fubar.org DNS servers for the host record (A) of the host www. fubar.org and receives the ip address of the host in reply.

For a Windows domain to function properly the Domain controllers, and also a few other servers and workstations, need to be able to dynamically update their own records so that authentication requests and replication can be directed to the right server. This is called Dynamic updates.

If you keep in mind that the DNS zone file for e.g. youraddomain.local is just a txt file, and consists of numerous lines representing the various host records for computers in the domain, it becomes apparent that since one cannot set security permissions on individual lines in a txt file, this is not very secure. For Dynamic update to function with standard primary dns zones, all computers which would do dynamic updates (all computers in the domain by default) would need to have write access to the file, meaning that any computer in the domain could change any record (any line) in the zone file.

For this reason, MS introduced the AD integrated DNS zone. Since AD is a jet database it was then possible to restrict access to just the actual entry for a specific host to update its own records.
The zone is in such a zone not a txt file, but kept in the AD database.

So what about your scenario?

First - you do not need to replicate the zone to all DNS servers in the forest for AD to function. However all DNS servers in the forest should be able to look up a record in another peer domain through DNS.
You could safely restrict DNS replication to dns servers within the domain, provided dns servers can find domain controllers in peer domains for authentication purposes and replication of AD critical information.

You can achieve this without replication of DNS zones as long as you make sure that DNS servers can correctly resolve dns names in the forest. A DNS server does not need to be authoritative for a zone to answer clients, as long as it can contact another DNS server who is.

With internal DNS namespaces (e.g yourdomain.local) you need to ensure that the DNS server knows where to direct the request, as a standard dns query will fail since .local is not a valid top level domain.

You can ensure that DNS servers in a peer domain knows which DNS server to query by using the "Forward" dns queries function in MS dns. You can direct the DNS server to forward DNS queries at a per DNS namespace basis in 2003 server. For instance if peerdomain1.yourrootdomain.local is your dns zone where 192.168.20.10 is the DNS server that has the zone (usually its domain controller) all other peer domains set their DNS server to forward queries for the peerdomain1.yourrootdomain.local. to  192.168.20.10. This ensures that computers in all peer domains can correctly resolve names for this zone.

So - to sum up - replication is not necessary for DNS to work, and for the forest to function, as long as all peer domain DNS clients can correctly do DNS lookups for computers in another peer domain. The DNS server do not need to host the zone to do this, it just need to know where to forward queries from its clients.

You can thus safely restrict the zone from being replicated beyond your own peer domain, and the admins in the other peer domain set their DNS servers to forward queries for yourpeerdomain.rootdomain.local to your DNS server.

Hope this was helpful.

Bjorn

Author

Commented:
WOW! Thank you for taking the time to write up all that. I appreciate what you have provided me and understand DNS a lot more now. I will work on resolving my problem when I come back from holiday. Thank you again Bjorn. Merry Christmas!

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial