DNS resolutions across domains

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.
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.

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.

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
wlacroixAuthor Commented:
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.
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.
wlacroixAuthor Commented:
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.
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.
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

From novice to tech pro — start learning today.