Case:

‘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: 10.1.88.50

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 10.1.88.150 /v

If a CNAME is missing:

Ref:
DNSLint usage: http://support.microsoft.com/kb/321045
Troubleshooting with DNSLint: http://support.microsoft.com/kb/321046