Before you start

Work on a copy or a controlled test when the change can affect production. Keep timestamps, screenshots and the previous configuration so the result can be compared.

Step by step

List the certificate authorities actually used for the domain.
Add suitable CAA issue and, when needed, issuewild records.
Publish on the zone apex first and check inheritance on subdomains.
Query CAA records through multiple resolvers and verify the TTL.
Run a renewal test before making the policy more restrictive.

Validation

Repeat the original test after the change and confirm that the expected service works without creating a new regression. Document the final state.

Technical deep dive

PKI: CAA issuance and LDAPS usage are different controls

Technical checkpoints

CAA specifies which CAs may issue for a domain; it does not replace client-side TLS validation.
For LDAPS, the DC certificate must cover the FQDN in use and include an appropriate Server Authentication EKU.
LDAPS typically uses TCP/636; port reachability does not prove the presented certificate is correct.

LDAPS

Read the certificate actually presented by the domain controller and verify SAN, EKU, dates and chain.

openssl s_client -connect dc01.example.local:636 -servername dc01.example.local -showcerts

Topic-specific pitfalls

Publishing overly restrictive CAA before identifying all issuing CAs can block future renewal.
Having multiple eligible certificates on a DC can cause Schannel to select an unexpected one.

How to validate

The presented LDAPS certificate is the expected one and clients trust it.
Published CAA records explicitly authorize the CAs actually used by the domain.