Solved

DNS resolutions across domains

Posted on 2014-12-09
5
75 Views
Last Modified: 2015-01-28
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.
0
Comment
Question by:wlacroix
  • 3
  • 2
5 Comments
 
LVL 17

Accepted Solution

by:
Learnctx earned 500 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?

company.local
brazil.company.local
canada.company.local
cloud_resources.company.local

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.
0
 
LVL 3

Author Comment

by:wlacroix
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.
0
 
LVL 17

Expert Comment

by:Learnctx
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:

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.
0
 
LVL 3

Author Comment

by:wlacroix
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.
0
 
LVL 17

Expert Comment

by:Learnctx
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.
0

Featured Post

3 Use Cases for Connected Systems

Our Dev teams are like yours. They’re continually cranking out code for new features/bugs fixes, testing, deploying, testing some more, responding to production monitoring events and more. It’s complex. So, we thought you’d like to see what’s working for us.

Question has a verified solution.

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

I had a question today where the user wanted to know how to delete an SSL Certificate, so I thought that I would quickly add this How to! Article for your reference. WHY WOULD YOU WANT TO DELETE A CERTIFICATE? 1. If an incorrect certificate was …
I've written instructions for one router type, but this principle may be useful for others of the same brand and even other brands of router. Problem: I had an issue especially with mobile devices that refused to use DNS information supplied via…
This tutorial will walk an individual through the steps necessary to install and configure the Windows Server Backup Utility. Directly connect an external storage device such as a USB drive, or CD\DVD burner: If the device is a USB drive, ensure i…
This tutorial will walk an individual through the steps necessary to join and promote the first Windows Server 2012 domain controller into an Active Directory environment running on Windows Server 2008. Determine the location of the FSMO roles by lo…

930 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

Need Help in Real-Time?

Connect with top rated Experts

14 Experts available now in Live!

Get 1:1 Help Now