without creating conditional forwarding is there a way to resolve names of only specific coomputers in the other forest. I don't want users in the forest that have internet access to resolve names of all servers in forest B. I need this only for a few servers.
[...]I need this only for a few servers.Need a few servers from Forest A to see all the servers in Forest B?
I think you have missed my point, which was that you can add DNS servers that are only accessed by the SCCM server(s), if this DNS server just hosts stub zones, the overhead is minimal, and you could have it installed on the SCCM server(s)
but sccm is member of a domain and its primary dns server is pointing to a domain controller that had the dns server role. even if I install dns on the sccm server and create a stub zone, the sccm still goes to the domain controller for name resoultion
Stub Zone
Organizations own their own AD zones. When business partners need to resolve data at a partner’s organization, there are a few options to support this requirement. Years ago, prior to Stub or Conditional Forwarders, there weren’t many options to handle this other than to use Secondary Zones and keep copies of each others zones via zone transfers. While the solution worked well in regards to name resolution, it was not the best security-wise, due to trust level between partners, because zone data is fully exposed at the partner. This became a security concern because the partner is able to see all of their business partner’s records. When the zone was transferred to partners, who knows what they were doing with the information. If the information was made public, attackers would have a field day with all of the IPs for the networked devices.
When stub zones were made available, it became a solution to overcome this security issue. What is also beneficial about Stubs, is you can AD integrate them instead of manually creating a Stub on each indivdual DC. THis way the zone will be available domain or forest-wide, depending on replication scope.
However, some may say due to the fact that the SOA records are included in the zone file, it may be a concern that the SOA and NS data is exposed. In such high security concerns, the better solution would be to use a Conditional forwarder.
===
Conditional Forwarder
This option is heavily used, and many look at them as the best regarding security concerns with zone data exposure, because no data is exposed. This option has worked very well in many environments.
With Conditional Forwarders, no information is being transerred and shared. The only thing you would need to know is one or more of your business partner’s DNS server IPs to configure it, and they don’t have to be the SOA, rather any DNS server that hosts the zone or that has a reference to the zone.
However, it does require open communication and let each other know when their DNS server IPs may change, because you must manually set them.
Windows 2003 introduced Conditional Forwarders, but it did not have the option to make it AD Integrated. If you have 10 DNS servers, you must create the Conditional Forwarder on each server manually. The AD integrated option was added to Windows 2008 or newer DNS servers, so you don’t have to manually create them on each DNS server. THis way the Conditional Forwarder will be available domain or forest-wide.
You absolutely can use conditional forwarders to resolve from A to B, and in this scenario it would be recommended.
but they don't want me to create a conditional forwarder from domain A to domain B.
they do not want to open port 53 in this direction from domain A to domain B