Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win


DNS resolutions across domains

Posted on 2014-12-09
Medium Priority
Last Modified: 2015-01-28
We have several domains under our belt.

Domain Controller A (Brazil_CLOUD)
Domain Controller B (Canada_CLOUD)
Domain Controller C (CLOUD_RESOURCES)

ClientA, in geographical location "BRAZIL" in subnet 10.10.20.x is joined to Domain A in Brazil_Cloud

We now have a singular print server that sits in 10.10.10.x subnet "CLOUD_RESOURCES" They did this to have a singular print server, instead of managing thousands of printers in many spots.

Client A can ping "print server in cloud" by IP.
Client A cant resolve printserver. UNLESS...I build a static record in Domain A DNS
printserver.canada.local which resolves to, but THE FACT IS THAT PRINTSERVER does not belong to canda.local it belongs to cloud.local

You can ping all over the place by IP, with no issues, from Domain A CLIENT in brazil on 10.10.20.x, but you cant resolve names outside of domain A, which is the problem as the printerserver resides in domain C

There is a trust already between the domains, and its working. If i go \\ to the printerserver it works.

How can I get the IP to resolve to a name properly?
From Client A in Brazil, I want to ping printserver and it resolve printserver.cloud_Resources.local. This way when the guys are installing printers in any domain, they type \\printserver and it will come up easily and simply, they then select the printer that they need and off they go.
Question by:wlacroix
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
  • 2
LVL 18

Accepted Solution

Learnctx earned 1500 total points
ID: 40489984
This is normal. If you want to have DNS across AD domains you will need to setup a zone delegation, stub zone or transfer the DNS zone from cloud_Resources.local to canada.local and brazil.local. Microsoft have an article on zones and zone transfers here: http://technet.microsoft.com/en-us/library/cc781340%28v=ws.10%29.aspx.

Otherwise you can just continue to setup a static record in your other domains.

Some scenarios.

Zone Transfer
DCa.brazil.local adds a new zone cloud_resources.local as a secondary zone pulling records from DCc.cloud_resources.local. You will need to enable zone transfers from DCc.cloud_resources.local and I would recommend for security only allowing a zone transfer to specific DC's in the other domains. Allowing any device to do a zone transfer can put you at risk. Once you do this when you lookup printservername.cloud_resources.local, canada.local will have a copy of the DNS zone information and respond to DNS requests directly without having to forward on to cloud_resources.local.

Zone Delegation
DCa.brazil.local adds a new zone delegation cloud_resources.local. You delegate DCc.cloud_resources.local as the name server for that DNS zone. When you lookup printservername.cloud_resources.local your local DC's will forward the request on to the listed name server(s).

Stub Zone
A stub zone is effectively a cut down zone transfer. It just contains the name server records for a given zone. It will update dynamically as name servers are added and removed from the target DNS zone. Doesn't do a full DNS zone pull but like a zone delegation will forward requests on DCc.cloud_resources.local.

Why did you go with 3 completely separate domains rather than a forest with child domains?


It would have simplified your situation with trusts, DNS and only having admin access for your AD team in the root domain gives you added security.

Author Comment

ID: 40492180
This is actually separate companies that are now sharing resources out of one of the domains in question.
Technically all these companies are now owned by umbrella corp.

All DCs are hosted in a cloud.

Trusts are already in place and have been for quite some time, this was setup as we acquired companies.

At the work station level in domain B, we need to resolve the name printserver  to an actual number that is in domain C

Now we had secondary zones built on all other domains this has not changed. I tested replication and such as well.
Things were working great. I dont know what has changed, all I know is that now workstations in domain B cant ping printserver by name, but can by FQDN printserver.domainC.local

The problem here is this is the second domain that I have had to fix with this same issue resolving to printserver.

Yesterday it was domain A, I tricked domain A by adding an entry (static A record) that reads printserver to 10.10.10.x in domain C
so if you ping printserver its printserver.domainA.local not printserver.domainC.local

I guess, no matter what it takes I need to resolve printserver by short name to make the printers that are connected work properly.

Hope that helps and its not too confusing.
LVL 18

Expert Comment

ID: 40492740
OK so FQDN works, sorry I missed that. If FQDN works but short names do not (and you're not using WINS) then you will need to add the DNS suffix for for the different domain DNS zones. So if you were a Canada domain member your suffix search order would be:

brazil.company.local (if you needed this)

Without specifying the DNS suffixes short name resolution will not work, only FQDN resolution. You can do this through group policy.

Author Comment

ID: 40496411
This is what we thought, and this has to be done at the workstation level does it not?

Nothing we can do at the server level?
May have to get my GPO guy to do some stuff.

The only other way we know how is to trick the domains dns by adding in a static entry for the server in question, which is technically wrong.
LVL 18

Expert Comment

ID: 40497275
Yes it needs to be done at the workstation level. If you want to do it at the DNS level you could also create an alias for the print server in canada.local.

Create new alias/cname: printserver1.canada.company.local -> "printserver1.cloud_resources.company.local." Do include the period on the end, this tells DNS that its the root and avoids additional lookups. This would mean that printserver1.canada.company.local would always point to the IP for printserver1.cloud_resources.company.local.

Featured Post

Ask an Anonymous Question!

Don't feel intimidated by what you don't know. Ask your question anonymously. It's easy! Learn more and upgrade.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Occasionally you run into the website or two that will not resolve properly using your own DNS servers.  Some people simply set up global forwarders for their DNS server.  I don’t recommend doing this because it can cause problems resolving addresse…
Resolving an irritating Remote Desktop connection that stops your saved credentials from being used.
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles to another domain controller. Log onto the new domain controller with a user account t…
This Micro Tutorial hows how you can integrate  Mac OSX to a Windows Active Directory Domain. Apple has made it easy to allow users to bind their macs to a windows domain with relative ease. The following video show how to bind OSX Mavericks to …

618 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question