FRS and the A-record and CNAME

Add a comment May 29th, 2010


‘DC01test’ has a modified object that should be replicated to its partner ‘DC4test’:

1. ‘DC01test’ queries AD for a configured replication partner (default defined by the KCC service)

2. ‘DC01test’ knows the name (‘DC4test’) of his replication partner, but needs to find the GUID of ‘DC4test’.

3. ‘DC01test’ compare all CNAME record in the “_msdcs zone” and finds the GUID that match the name ‘DC4test’

4. Next step ‘DC01test’ needs to find is the IP of ‘DC4test’ so it can connect to ‘DC4test’.

5. ‘DC01test’ sends a recursive DNS query to its primary configured DNS server asking for a CNAME (the alias of the GUID).

Query: guid._msdcs.spurs.local
DNS server respond with: ‘DC4test.spurs.local’

6. ‘DC01test’ ask his DNS for the A-record for ‘DC4test.spurs.local’
DNS server returns the IP:

7. ‘DC01test’ connects to ‘DC4test’ and flags that “I have a change you need to get from me”.

8. Since FRS is based on PULL (not push), ‘DC4test’ will pull the changes on the object from ‘DC01test’.

If the A-record or the CNAME is missing or not correct, this process will fail. As a result, the replication will fail.
A handy tool that will test that all records are registered on all authoritative DNS servers is “dnslint”. It will create a HTM-report and highlight errors/warnings.

ie. dnslint /ad /s /v

If a CNAME is missing:

DNSLint usage:
Troubleshooting with DNSLint:

  1. No comments yet.Be the first ?
  1. No trackbacks yet.
Comments feed

× nine = 27