Solved

DNS resolutions across domains

Posted on 2014-12-09
5
74 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 16

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 16

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 16

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

Don't lose your head updating email signatures!

Do your end users still have the wrong email signature? Do email signature updates bore you or fill you with a sense of dread? You can make this a whole lot easier on yourself by trusting an Exclaimer email signature management solution. Over 50 million users do...so should you!

Join & Write a Comment

Scenario:  You do full backups to a internal hard drive in either product (SBS or Server 2008).  All goes well for a very long time.  One day, backups begin to fail with a message that the disk is full.  Your disk contains many, many more backups th…
You might have come across a situation when you have Exchange 2013 server in two different sites (Production and DR). After adding the Database copy in ECP console it displays Database copy status unknown for the DR exchange server. Issue is strange…
This tutorial will give a an overview on how to deploy remote agents in Backup Exec 2012 to new servers. Click on the Backup Exec button in the upper left corner. From here, are global settings for the application such as connecting to a remote Back…
This tutorial will show how to configure a single USB drive with a separate folder for each day of the week. This will allow each of the backups to be kept separate preventing the previous day’s backup from being overwritten. The USB drive must be s…

758 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

19 Experts available now in Live!

Get 1:1 Help Now