[00:06] Trust relationships can help us authenticate users, computers, applications among domains, which don't share the same forest.
All Active Directory trusts between domains within a forest are transitive, two-way trusts.
So, in this demo, I will simulate 2 domains, which don't trust each other by default, can work together (authenticate, identify, share, etc.).
[00:15] First, we need to configuring DNS services for communicating between those 2 domains in this example.
[00:20] Make sure you reviewed my videos about DNS service before you start.
Also, ensure that your functional level is high enough as mentioned in previous episodes of "Manage Multiple Domains and Forests".
We have up to 3 methods when configure DNS servers for 2 domains to get a successful communication:
– Create a secondary zone with a copy of records about each opposite domain.
– Use stub zone to store DNS server info of another domain only for "help clients identify where to do further queries."
– Use conditional forwarders to forward DNS queries to the DNS server which contains expected records.
While using a secondary zone can cause stresses in our network performance when the transfer of records about an entire zone, or delay in the network infrastructure can cause resolution results may not be updated in time.
However, it helps do queries faster since these records reside right in the local domain instead of looking for another domain each time clients do look up.
Conditional Forwarding does not participate in zone transfers, while stub zones do.
Furthermore, with conditional forwarding, when a query is sent to a DNS server, that server will perform recursions and returns the answer to the query.
With stub zones, a referral is given to the requester (client), instead.
With conditional forwarding, if Name Servers' IP addresses of the domain that you are forwarding to, was changed, you (network X) won't know unless you are monitoring that or got a contact from their DNS admins (manually, network Y).
With stub zones, the SOA and NS records are updated through the zone change quests (automatically).
[00:55] More info about choosing the right DNS configuration to success in trust communications (included maintain trust relationships) here:
[01:12] We will choose the Stub zone method in the SnoOpy.org side, firstly!
[01:38] We are in SnoOpy.org side (network X).
This stub zone stores SOA, NS records about SnoOpy.net zone/domain name.
[01:50] Enter the current IP address of the DNS server who own master zone of SnoOpy.net domain (network Y).
[02:31] In SnoOpy.net side (network Y), we will use the Conditional Forwarder method.
The SOA record.
The NS record.
[02:53] Temporarily, this validation process fails because this domain hasn't had any info about SnoOpy.org (network X) until now.
And glue A records.
[03:10] However, everything will be fine since this domain (network Y) now has a Conditional Forwarder for SnoOpy.org domain (network X).
[03:47] Now, create a host record in SnoOpy.org side (X) then switch to SnoOpy.net side (Y) and verify the Conditional Forwarder feature is working fine.
[03:57] Act this server as a client by configure to query itself since this is a DNS server in SnoOpy.net side (Y) and has a Conditional Forwarder about SnoOpy.org side (X).
[04:29] Okay, Conditional Forwarder works fine!
We can query DNS records that belong to SnoOpy.org (X).
[04:46] Now let's create a host record in SnoOpy.net side then test how of Stub zone in SnoOpy.org works.
[05:20] A stub zone is working fine, now 2 domains have an essential thing for further communications (Trust).