asked on

DNS resolutions across domains

We have several domains under our belt.

Domain Controller A 10.10.10.92 (Brazil_CLOUD)
Domain Controller B 10.10.10.127 (Canada_CLOUD)
Domain Controller C 10.10.10.54 (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 10.10.10.127, 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 \\10.10.10.54 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.

ASKER CERTIFIED SOLUTION

Aard Vark

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

wlacroix

ASKER

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.

Aard Vark

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:

canada.company.local
cloud_resources.company.local
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.

wlacroix

ASKER

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.

Aard Vark

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.