DNS setup for a FreeIPA and AD trust

Why FreeIPA and AD DNS setup decides whether the trust works

Plan DNS before you touch the trust. A FreeIPA and Active Directory trust depends on two conditions that DNS controls: the IPA domain must use a DNS domain that does not overlap with any domain in the AD forest, and each side must be able to resolve the other side's names and service records. If either condition fails, the trust setup can stall or appear to succeed while Kerberos referrals and cross-realm lookups fail later. For a Linux team that has run FreeIPA on its own and now has to reach an existing AD forest, the DNS layout is usually the first design decision that cannot be fixed cheaply after go-live.

The FreeIPA side combines several components that all depend on names. 389 Directory Server stores users, groups, hosts and policies, MIT Kerberos locates its key distribution centers through DNS SRV records, and the optional ISC BIND DNS service, if you use it, becomes the authoritative source for the IPA zones that clients and AD must query. Clients in each resolv.conf need at least two DNS servers, and the choice of integrated or external DNS changes who owns each record. Decide early which server answers for the IPA domain, which answers for the AD domain, and how forwarding and conditional forwarders move queries between them.

DeployOpen plans, implements and verifies this DNS design on infrastructure you control, including your data center, cloud accounts or air-gapped network. The work covers the domain and realm naming, the forward zones for the AD domain, the SRV records that both sides need, and checks run from the FreeIPA servers, the AD domain controllers and representative Linux clients. Confirm with your AD team who owns the AD DNS zones and whether they will accept conditional forwarders or delegation before the trust project is scheduled, because that approval often sets the timeline.

Which DNS layout fits each FreeIPA and AD arrangement

This table compares three DNS layouts for a FreeIPA and AD trust: integrated IdM DNS with a forward zone to the AD domain, external DNS forwarding to both sides, and a split where clients use IdM DNS only for IPA names. Read each row across the options to see who owns records, what changes when AD DNS changes, what breaks for Linux clients, and who must approve the design before cutover.

Question	Integrated IdM DNS with AD forward zone	External DNS forwarding to both sides	Split: IdM DNS for IPA names only
Who owns records	IPA team owns IPA zones; AD team owns AD zones; the forward zone is a pointer maintained by the IPA team	A separate DNS team owns all zones and forwarding rules	IPA team owns IPA zones; AD team owns AD zones; clients resolve each through a different server
Change effort when AD DNS changes	Forward zone targets may need updating when AD DNS servers move or are renamed	Usually one change point in the forwarders, but that team must know both sides	Low for IPA, but AD name resolution from Linux depends on a separate path that must be re-tested
Failure impact on Linux clients	If AD DNS is unreachable, AD names fail on IPA clients while IPA names keep resolving	If the external resolver fails, both IPA and AD names fail for every client	Clients resolving AD names through the wrong server can fail Kerberos lookups for AD users
Clients need at least two DNS servers	Confirm two IdM DNS servers are listed in each client resolv.conf	Confirm the external resolvers are redundant and listed on clients	Confirm two IdM servers for IPA names and a working path for AD names
Team that must sign off	IPA administrators with the AD DNS and AD operations teams	Network or DNS platform team with both IPA and AD administrators	IPA, AD and network teams, plus the owners of client resolver configuration
Best fit	Organizations where IPA administrators manage DNS and AD DNS is stable and well documented	Organizations with a central DNS platform and strict change control over resolvers	Environments where IdM DNS must stay isolated from AD zones, with a confirmed path for AD names

FreeIPA AD trust DNS setup steps in order

This sequence takes DNS from naming decisions through to verified name resolution in both directions, so the trust can be created without DNS failures. Each step closes with a check you can run before moving on.

Confirm the IPA domain and realm do not overlap AD
Before any DNS change, the IdM owner and the AD team list every DNS domain in the AD forest and compare them with the planned IPA DNS domain and Kerberos realm. The IPA domain must not overlap with any AD forest domain, so the IPA domain should be a separate DNS name, such as a subdomain you own that AD does not use. Record the agreed names in a shared document signed off by both teams. The step is done when both lists are written down and neither contains a name the other uses. Check: run a query for the planned domain against the AD DNS servers and confirm it returns no zone.
Agree the NetBIOS name with the AD team
The NetBIOS name is the short name used for the IPA side of the trust, and it must be agreed with the AD team before the trust is configured. Both teams should confirm that the name is not already used by a domain, computer or service in the AD forest. Write the chosen name next to the realm and DNS domain in the naming record so later steps use the same values. The step is done when the AD administrator confirms the name in writing. Check: search AD for the NetBIOS name and confirm no object or NetBIOS registration already claims it.
Add forward zones or forwarders for the AD domain
On the IdM DNS servers, add a forward zone for each AD domain that the trust must reach, or configure forwarders that send those queries to AD DNS servers. The IdM side needs this so that AD user and group lookups, and the trust's SRV lookups, resolve correctly. Keep the forwarding design consistent with the replica and DNS placement chosen for the deployment, and confirm the AD DNS server addresses with the AD team. The step is done when the IdM DNS configuration lists the zone or forwarder for every AD domain. Check: from an IdM server, query a known AD host name and confirm the answer comes from the AD DNS server.
Make AD domain controllers resolve the IPA domain
The AD team configures its DNS servers so that queries for the IPA domain are forwarded to the IdM DNS servers or to a zone that holds the IPA records. Without this, domain controllers cannot find the IPA Kerberos and LDAP services during trust setup. The AD team makes this change in their own environment, and the IdM team supplies the IPA DNS server addresses and the zone name. The step is done when the AD team confirms the change is live on every DNS server that domain controllers use. Check: from a domain controller, query an IPA host name and confirm it returns the IdM server address.
Confirm SRV lookups for the IPA domain
Test the service locator records that IPA clients and the trust depend on, including the Kerberos, LDAP and global catalog style SRV records for the IPA domain. Run the lookups from an IdM server and from a Linux client, because each side uses its own resolver path. A missing or stale record here usually causes enrollment or trust failures that look like authentication errors. The step is done when every expected SRV record returns the right target and port from each side. Check: query the SRV names for the IPA domain from an IdM server and a client, and compare the answers.
Confirm SRV lookups for the AD domain
Repeat the SRV checks in the other direction, querying the AD domain's Kerberos, LDAP and global catalog records from an IdM server and from a Linux client. The AD side should publish the records that the IPA trust controller uses to locate domain controllers. Compare the returned host names with the domain controllers listed in AD Sites and Services, and note any site that answers unexpectedly. The step is done when the AD domain SRV records resolve to live domain controllers from both sides. Check: list the AD SRV answers from each side and match them to the AD domain controller inventory.
Set at least two DNS servers in client resolv.conf
Configure every Linux client that will use the trust to list at least two DNS servers in its resolver configuration, so a single DNS outage does not stop logins or name lookups. This applies to clients enrolled in IPA and to any host that will resolve AD users. Deploy the change through your normal configuration management and remove stale entries from earlier builds. The step is done when the resolver setting on each client lists two or more reachable DNS servers. Check: read the resolver file on sample clients of each class and test a lookup against each listed server.
Test resolution from both sides before the trust
Run one end-to-end check from an IdM server and from an AD domain controller that covers forward lookups, reverse lookups, SRV records and a sample user lookup for each domain. Record the results and the time each check was run, and keep them with the naming record. Fix any failure before the trust is created, because trust errors caused by DNS are harder to diagnose once the trust exists. The step is done when every check passes from both sides and the results are filed. Check: repeat the full test set after any DNS change and confirm the outputs match the recorded baseline.

What the FreeIPA team and the AD team each change in DNS

The FreeIPA team owns the IdM DNS servers, the zones they serve and the resolver settings on enrolled clients. The IPA domain must use a DNS name that does not overlap with any domain in the AD forest, so the first change is confirming that name and keeping it consistent across zones, realm and client configuration.

IdM DNS server settings: Confirm which IPA servers run DNS, and that each client has at least two DNS servers in its resolv.conf, as FreeIPA's deployment recommendations advise.
Zone and forwarder configuration: Create the IPA zone and set forwarders or delegation so that queries for the AD domain reach the AD side. Record which zones are authoritative on IPA and which are forwarded.
Client resolver files: Check that enrolled Linux hosts resolve both the IPA domain and the AD domain through the intended servers, and that no client points only at the AD side.
Records the trust needs: Verify the SRV records that clients and the trust rely on resolve correctly from the IPA side before the trust is created.

Before the trust is created, ask the AD team for written confirmation of the forwarding change and the window in which they will make it.

How SRV records and forward zones let each side find the other

SRV records tell a client where a service lives. Kerberos clients and AD-joined machines look up SRV records under the _kerberos and _ldap labels to find key distribution centers and directory servers for a given domain, and a trust only works when each side can perform those lookups for the other side's domain. In a FreeIPA and AD trust, the IdM servers must resolve the AD domain's service records, and the AD domain controllers must resolve the IdM domain's records. If either direction fails, cross-realm ticket requests fail even when both sides look healthy in isolation. Confirm the exact record names, the ports they advertise and the lookups each side performs against the FreeIPA Trusts documentation and your own environment before you assume any of them.

A forward zone and a forwarder solve different problems, and the difference matters for the trust. A forwarder is a server that IdM asks when it does not know an answer, and it returns whatever that server says. A forward zone tells IdM that queries for a specific domain, such as the AD domain, should go to named AD DNS servers for that zone. For the trust, the forward zone is the usual choice on the IdM side because it sends lookups for the AD domain straight to the domain controllers that publish the SRV records. Pick the design with your AD team, since the AD side needs the mirror-image configuration: a forward zone or conditional forwarder for the IdM domain pointing at the IdM DNS servers.

Before you test the trust, run lookups from both sides using the same resolvers your clients and services will use, not a workstation's public resolver. Query the SRV names for the other domain from an IdM server, from an enrolled Linux client and from a domain controller, and compare the answers to the DNS servers listed in each client's resolver configuration. Stale forward zones, a missing reverse entry or a resolver that caches an old answer will show up here as a trust failure later. Record the results and the change window so the AD team can repeat the same checks if a domain controller or IdM server is replaced.

Realm, domain and NetBIOS naming rules to settle before the trust

Names are the hardest part of a FreeIPA and AD trust to change later. The DNS domain, Kerberos realm and NetBIOS name each shape how clients find servers and how the two sides authenticate each other, so settle them with the AD team before any DNS records or trust objects are created.

IPA DNS domain must not overlap AD

The IPA DNS domain must be a DNS domain that does not overlap with any domain in the AD forest. Choose a separate parent domain for the IPA side, so that a name such as ipa.example.com is never a child of an AD domain already in use. Overlap makes SRV lookups for the same name return records from two directories, and clients may then contact the wrong Kerberos servers. Ask the AD team for the full list of forest domains, including child and tree domains, before choosing.

Realm name follows the DNS domain

The Kerberos realm is conventionally the DNS domain in uppercase, and FreeIPA uses it for principals such as user@REALM. Decide the realm during installation because it is written into keytabs, client configuration and every service principal. The realm must not collide with the AD realm, since two realms with the same name cannot trust each other. Confirm with the AD team which realm name their Kerberos tickets use today.

NetBIOS name unique in the forest

The IPA side gets a NetBIOS name that is used by Windows tools and by the trust process to identify the domain. It must be unique across the AD forest and must not match any existing NetBIOS domain name, computer name or workgroup name the AD team uses. Keep it short and avoid characters that Windows naming rules reject. Confirm the chosen name with the AD team and check it against the forest before the trust is created.

Renaming later affects clients and trusts

Changing the DNS domain, realm or NetBIOS name after deployment is disruptive. Clients enrolled with the old names need re-enrollment, service principals and keytabs must be regenerated, and an existing trust may need to be rebuilt. Document the naming decision in writing, record who signed it off on each side, and plan any rename as a change window with a tested rollback. Ask the AD team how they would handle a trust rebuild before committing.

Checks to run from both sides before creating the trust

Run the same set of name resolution checks from four vantage points before you create the trust: a FreeIPA server, an IPA client enrolled in that domain, an Active Directory domain controller, and a Windows host joined to the AD domain. The point is to prove that each side can resolve its own domain and the other side's domain using the records the trust depends on. For each vantage point, check that the IPA domain and the AD domain resolve to the right zone, that the SRV lookups for the domain controllers, Kerberos and LDAP services return the expected hosts, and that every DNS server listed in the configuration can be reached over the port it serves. Use the same query names on every host so the results can be compared directly.

Record the output from each host in a table that lists the query, the answer, the server that answered and the time of the check. Compare the four columns side by side before anyone runs ipa trust-add. Differences matter more than individual failures: if an IPA client resolves a name that the FreeIPA server does not, the client is probably pointing at a resolver that bypasses the zone you intended. Treat the comparison as the acceptance record for the DNS change, and keep it with the change ticket so the AD team can review the same evidence. Ask your AD team to confirm which domain controllers they expect to appear in the SRV answers, since they own those records.

When a check fails on one side, the cause is usually a missing or wrong zone, a missing forwarder or a conditional forward that points at the wrong server, and it is usually on that side. For example, if the AD domain resolves on the AD domain controller but not on the FreeIPA server, look first at the forward zone or forwarder configured in IdM rather than at the trust itself. Fix the side that failed, rerun the full set of checks from all four hosts, and do not proceed while any check still differs. Confirm the exact forwarding and zone options your FreeIPA version supports with the current FreeIPA documentation and with your AD team before making changes.

Limits to confirm in your environment before you start

The DNS plan for a FreeIPA and AD trust depends on facts that sit outside the IdM servers: the FreeIPA version, who owns AD DNS, and what the network allows. Confirm each item below with the people who run those systems, because a wrong assumption here usually surfaces as a failed trust setup or a resolution problem that only appears later.

FreeIPA version and DNS mode

Confirm which FreeIPA release each IdM server runs and whether DNS is integrated into IdM or provided by an external server. Integrated DNS, external DNS and forwarding each change where SRV records live and who edits them. Check whether DNS over TLS between clients and IdM DNS is already in use on the servers, since that setting affects how clients resolve names during the trust. Release notes for each version should be read against the exact build installed.

Ownership of AD DNS

Find out whether the AD DNS zones are managed by the Windows team, by a separate network team, or by a vendor appliance that only that vendor can change. Records for the IPA domain, forward zones pointing at AD, and SRV record changes all need a change owner on the AD side. Agree the approval path and change window before design work begins, because a trust cannot be validated until the AD team has made its half of the DNS changes.

DNS over TLS scope

Decide whether DNS over TLS between clients and IdM DNS servers is in scope for this project. It changes which ports must be open, how resolver configuration is written on each client, and which teams need to test name resolution. If it is out of scope now, record that decision so a later change does not break the trust path. Confirm the client distributions that will be enrolled, since their resolver tooling differs.

Split-horizon and existing internal zones

Check whether any internal zone already uses the name chosen for the IPA domain, or whether clients see different answers from internal and external resolvers for the same names. The FreeIPA trust documentation requires that the IPA domain does not overlap any domain in the AD forest. Search existing resolvers, DHCP search suffixes and host files for conflicting names before the realm is fixed.

Windows Server versions in the AD forest

Confirm the Windows Server version of every domain controller and the forest and domain functional levels. Trust support depends on these versions, and the RHEL releases needed for newer Windows Server versions depend on the same inventory. Ask for a current list of domain controllers per site, because the DNS records for the trust must be reachable from each site that the IdM servers will contact.

Firewall rules for DNS and Kerberos

Verify that firewalls allow DNS queries and responses between both sides, and Kerberos traffic from IdM clients and IdM servers to AD domain controllers and back. Trust setup and later authentication both depend on these paths, and many failures blamed on DNS are blocked ports. Ask the network team to confirm the rules in both directions for each site, and test them with the same hostnames the trust will use, not only IP addresses.

Security and operations for DNS shared by FreeIPA and AD

Decide who can change zones and forwarders on each side before the trust goes live. On the FreeIPA side, DNS records and forwarders are changed through IdM administrative roles, so review which accounts hold those roles and whether any are shared. On the AD side, the zones, conditional forwarders and delegations are controlled by DNS administrators in the forest. Write down one owner for each zone and each forwarder, and agree how a change is requested, approved and recorded across the two teams. The trust itself does not hand DNS control from one side to the other, so a change on either side can silently break name resolution on the other.

A misconfigured forwarder is one of the most likely failures in this design. If a forward zone for the AD domain points at the wrong server, or a forwarder for the IPA domain is left pointing at a public resolver, queries for internal names can leak outside the organization or fail in ways that look like Kerberos or LDAP faults. Keep the forwarder list short, record the reason for each entry, and test resolution from a client in each domain after every change. Log changes in both systems, and have someone other than the author review them. Confirm with your AD team whether they audit DNS changes in their own tooling and whether those logs can be exported to the same place as your IdM audit records.

Once the trust is live, monitor DNS health as a service dependency, not as a one-time check. Track failed SRV lookups for the Kerberos, LDAP and global catalog records, query latency from representative clients, and forwarder availability. Confirm that every client's resolv.conf lists at least two DNS servers, as FreeIPA's deployment recommendations advise. FreeIPA 4.13.0 added DNS over TLS between clients and IdM DNS servers, which can protect query traffic from interception on the network. Confirm whether your client estate, including the SSSD and resolver versions on each distribution, supports this before planning to enable it.

What teams ask about cost, effort and ownership of FreeIPA and AD DNS work

How long does DNS planning for a FreeIPA and AD trust take?

No fixed duration applies to every environment, so ask for a timeline built from your own inventory rather than a generic number. Planning time is driven by how many AD forests and domains are involved, whether the IPA domain name must be chosen or changed, how many DNS servers and clients resolve names today, and how many change approvals sit between the teams. Environments with one AD domain, a clean naming plan and a documented resolver setup usually plan faster than estates with overlapping suffixes, split-horizon DNS or several resolver generations. Ask any firm to show which of these factors it has assessed and which it has left open until your data arrives.

Does the AD team need to spend time on the DNS work?

Yes, in most cases the AD team is needed for specific steps even when an outside partner does the design and build. The AD side owns forward zones, conditional forwarders, domain controller DNS settings, and the records that show the AD domain and its controllers. Expect them to review the zone and forwarder changes, confirm that the AD domain name and NetBIOS name will not clash with the IPA domain, and validate queries from their side after each change. Ask for a written list of AD tasks, owners and review points before the work starts, so their time is planned and not discovered mid-project.

Who must approve DNS zone and forwarder changes?

Approval normally sits with the owner of each DNS platform, the change board that governs production DNS, and the AD administrators for any change that touches the AD domain. Your change control process decides the rest. Some organizations require a security review when a DNS server receives a new forwarder, and a network team review when resolver addresses change on clients or firewalls. Agree the approval path in writing during scoping, list each change type with its approver, and confirm how emergency rollbacks are authorized. Unclear approvals are one of the most common reasons DNS work stalls after the design is finished.

Can our internal team set up FreeIPA and AD DNS alone?

A team that already runs FreeIPA, Active Directory and enterprise DNS can often do the work in house, provided it has people who understand each platform's DNS behavior and time to test. The skills gap usually sits in the trust-specific details: SRV record discovery, the separation of the IPA primary domain from AD domains, realm and NetBIOS naming rules, and checks run from both sides. Consider whether the same two or three people will be available through testing, cutover and the first weeks of operation, because DNS faults often surface late. An outside partner can review the design, build it alongside your staff or hand over a documented runbook, and the right mix depends on your staffing.

What does a fixed-scope quote for DNS work include?

A fixed-scope quote should list the work in writing before anything starts, so the scope, deliverables and timeline are agreed in advance. Ask that it name the AD domains and forests in scope, the number of FreeIPA DNS servers and client groups, the zones and forwarders to be created or changed, the checks you will receive from each side, the handover format and the change requests the work requires. Also ask what is excluded, such as trust setup itself, client re-enrollment or changes to AD domain controllers. Cost usually rises with the number of AD domains, DNS servers and clients, and with the number of change cycles needed, so request a quote that shows these counts as its basis.

What does a retainer cover after DNS go-live?

A retainer covers ongoing work agreed in advance, such as health checks on DNS resolution, review of changes to zones and forwarders, patching and upgrade planning for FreeIPA servers, and help when a resolver or trust check fails. It is a recurring cost, so compare it with the expected volume of change and incidents in your environment. Ask whether the retainer includes testing after AD domain controller changes, how requests are prioritized, and what documentation is updated after each change. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and the exact coverage is set in the written agreement.

Which DNS cost drivers should we ask about first?

Start with the count of AD domains, the count of FreeIPA DNS servers and the count of clients whose resolver settings change. Each adds design, configuration and test effort, and a larger count also adds coordination with more owners. The fourth driver is change control: a single approval window is cheap compared with several, and an environment where each forwarder needs a separate ticket takes longer. Ask for the effort to be split into design, build, testing and handover, and ask which items recur after go-live. These are the parts of the quote that let you compare an internal plan with an outside one on equal terms.

How DeployOpen scopes and delivers FreeIPA and AD DNS work

DeployOpen treats DNS for a FreeIPA and AD trust as a planning task before it is a configuration task. We agree the naming, zones and resolver paths in writing, build them inside your own infrastructure, and document how both sides verify the result. Engagements are fixed-scope, so the boundaries are known before work starts.

How we scope

Written scope listing the IPA domain, realm, NetBIOS name and AD domain names to be reviewed
Inventory of existing AD DNS zones, forwarders and delegation that the IPA design must fit
Agreed list of SRV record checks, conditional forwarders and client resolv.conf changes
Named owners on the Linux and Windows sides for each change and each sign-off

How we build

Configure separate primary DNS domains for FreeIPA and AD, confirmed non-overlapping before any install
Create forward zones for the AD domain on IPA DNS servers and matching forwarders in AD
Validate SRV records for the IPA and trust services from every IPA server and sample client
Test name resolution and Kerberos lookups from both the Linux and Windows networks before trust setup

How we hand over

Documented zone inventory, forwarder list and record checks with the commands used to verify them
Runbook covering resolver settings on IPA clients and the order of changes on each side
Rollback steps for each DNS change, written so the AD team can run them without FreeIPA access
Walkthrough with your Linux, identity and Windows administrators, with open items recorded in writing

How we support

Ongoing support and upgrades are available as a retainer after handover
Re-verification of SRV records and forwarders after AD domain controller or IPA server changes
Support for DNS-related changes during FreeIPA upgrades, scoped in writing before each change
Quotes are based on the written scope, and your team should ask what recurring checks a retainer includes