Integrated or external DNS for FreeIPA: which one fits your environment
Run FreeIPA's own DNS when the identity team can own the zone that clients and services depend on, and rely on external DNS only when the corporate DNS team will maintain every record FreeIPA needs. Integrated DNS means the optional ISC BIND server runs on IdM servers and FreeIPA writes its own records: the SRV records that Kerberos, LDAP and client discovery use, the ipa-ca record that points clients to the certificate authority, and host records that enrolled machines can update through dynamic updates. Teams usually need it when they want enrollment and service discovery to work without manual DNS tickets. The choice is hard to reverse, because moving a live zone from integrated to external ownership means repointing clients, rebuilding records and retesting Kerberos and LDAP lookups. Confirm the exact record set and update behavior for your FreeIPA version before you commit.
The trade-off is mostly about who edits what and how names are split. An external team must keep the same records current: the SRV records, the ipa-ca record, forward and reverse entries for every IdM server and enrolled host, and the forwarding or delegation that sends clients to the right zone. Each IdM server address change, new replica or renamed host becomes a manual change request in their queue. Integrated DNS also has a documented split DNS limitation, so a design that depends on the same domain answering differently inside and outside the network needs a separate decision. Certificates add a constraint as well. If you request IP address SANs for services, those addresses must stay stable and match what clients resolve, so confirm how your version handles them before you rely on either model.
Before choosing, list who will own each record type and whether the corporate team will accept dynamic updates or only a delegated subdomain such as an ipa subdomain. Ask them how they handle zone changes, change windows and secondary servers, since those answers set the ongoing effort of external records. Then test the choice in a lab that matches your target FreeIPA version: enroll one client, and check SRV lookups, ipa-ca resolution and reverse lookups from each site. Deployment guidance expects at least one replica per datacenter running DNS if you use it, and at least two DNS servers in each client's resolv.conf, so count those servers in your design. Read the FreeIPA deployment recommendations alongside your version's documentation before you sign off.
Integrated DNS compared with external DNS
This table compares three ways to place DNS for a FreeIPA deployment: FreeIPA serving the whole zone, FreeIPA serving a delegated subdomain, and a fully external DNS service. Read each row as a question you must answer before installation, and treat the owner row as the deciding factor for most teams.
| Factor | Integrated DNS (FreeIPA serves the zone) | Delegated subdomain (FreeIPA serves ipa.example.com) | Fully external DNS (FreeIPA runs no DNS) |
|---|---|---|---|
| Automatic SRV and ipa-ca records | Created and maintained by FreeIPA in its own zone | Created and maintained by FreeIPA inside the delegated subdomain only | Not created; your DNS team must publish every SRV record and the ipa-ca record by hand |
| Client dynamic updates | FreeIPA accepts updates from enrolled hosts | FreeIPA accepts updates for records in the delegated subdomain | Not available; host records change through your external DNS process |
| Split DNS handling | Requires care; the IPA domain should not be served differently to internal and external clients | Keeps the IPA domain separate from the corporate zone, which limits split DNS problems | Split DNS is handled entirely by your external DNS platform |
| IP address SANs for certificates | Usually requires the FreeIPA-managed name records to match the addresses issued to services | Same constraint for hosts inside the subdomain | Your team must keep the names and addresses in sync with certificate requests |
| Parent zone changes | None needed beyond pointing clients at FreeIPA servers | NS records in the corporate parent zone, repeated when FreeIPA DNS servers are added | None if your external zone already holds all records |
| Operational owner | Identity team owns DNS; coordinate with network team on forwarders | Identity team owns the subdomain; corporate DNS team owns the delegation | DNS team owns all records, change control and reverse zones |
| Typical fit | New or isolated identity domain with no existing DNS platform the team wants to keep | Organizations that must keep corporate DNS authoritative for the parent domain | Strict DNS governance or an existing platform that cannot accept dynamic updates |
| What the team must provide | Forwarders, reverse zone plan, DNSSEC decision and monitoring of FreeIPA DNS servers | Delegation records, tested resolution from every client network and a repeat step for each new server | A record and PTR publishing process, SRV and ipa-ca records, and a runbook for every host change |
Split DNS limits and IP address SANs in FreeIPA
Splitting one DNS zone into an internal view and an external view is the design choice that most often causes trouble with FreeIPA. The internal zone carries records that IdM creates and updates on its own, and an external copy of that zone does not receive those changes automatically. The cards below show where the conflict appears and what to confirm for your FreeIPA version.
Split DNS defined
Split DNS serves the same zone name with one set of answers inside the network and another set outside. FreeIPA treats its own zone as the single source of truth, so an outside copy that differs from the internal copy is a second source the installation does not manage. If a host needs a public name, decide early whether the outside answer comes from a separate zone name, a record in an external zone, or an address translated at the firewall. Record that choice before installation so the design is not settled by whoever edits the zone first.
Automatic service discovery records
IdM publishes service discovery records such as SRV entries for Kerberos and LDAP, along with an ipa-ca host record that clients use to find the certificate authority. Enrolled hosts depend on these names resolving from their own network. If an external team copies only part of the zone, or edits these records by hand, clients on the outside may find no KDC and no CA. Compare the record list from a fresh install in your version against the external zone before handing zone maintenance to another team.
Client dynamic updates
Enrolled clients can register their own address records with IdM through dynamic updates, so the internal zone changes as machines join, move or change addresses. An external copy receives those changes only if something replicates them, such as a zone transfer you configure. Otherwise the two views drift apart, and a host that resolves correctly inside may fail outside. Confirm which update path your clients use and whether any transfer to external servers is enabled for the zone.
IP address SANs in certificates
A certificate can list an IP address as a IP address SAN, which lets clients that connect by address verify the certificate. Issuance depends on the DNS and host records in FreeIPA, so the address must match the host object and name the service uses. When a service has one name internally and another externally, an IP SAN added for one view may not match the address the other view's clients connect to. Test each certificate with the exact name and address clients will use, and confirm the issuance behavior for your version.
Why DNS views are discouraged
DNS views return different answers based on the source address of the query. The FreeIPA project discourages them for a zone that IdM manages, because automatic records and client updates land in one view while the other view must be kept in step by hand. Every record change then has two places to fail. Before you choose views, ask which records really must differ, and whether a separate external zone name would avoid the overlap. Confirm the current guidance for your version.
Checks before go-live
Resolve every service name from both sides using the same resolver path each group of clients uses. Confirm that SRV lookups return the same targets in both views, that the CA host name reaches a live address, and that a test certificate request with an IP SAN succeeds. Record the results with the FreeIPA version and zone settings, so a later upgrade or external DNS change can be checked against the same list.
Setting up the chosen DNS model
This sequence turns the DNS decision into a working setup, from naming and zone ownership through installation, client resolver configuration, delegation or forwarding, and verification of the records clients depend on. Each step ends with a check so the team knows the layer is sound before the next one is built.
Confirm the domain and realm plan
Before anything is installed, the architecture owner records the primary DNS domain for FreeIPA, the Kerberos realm (normally the uppercase form of that domain), and confirm that the IPA domain does not overlap any Active Directory forest domain if a trust is planned. Write the names into the design record and check them against the corporate DNS inventory. Done means a signed-off naming sheet exists, and nobody on the team proposes renaming it later.
Assign ownership for every zone
List each zone the platform will touch: the FreeIPA domain, any reverse zones for the server and client networks, and any parent or corporate zones that will point at FreeIPA. For each zone, name the team that edits it and the team that answers for it during incidents. Ask the corporate DNS team to confirm in writing whether they will accept NS delegation or forwarding changes and who approves them. Done means every zone has one named owner and an agreed change path.
Choose integrated or external DNS at install
Run the install with the DNS option that matches the decision record. With integrated DNS, FreeIPA serves the IPA zone and creates the SRV and ipa-ca records itself, and client dynamic updates are enabled for the zone. With external DNS, the install skips DNS management, and the external team must publish the same records by hand. Confirm the chosen option against the current FreeIPA deployment documentation for your release before running the command. Done means the install log shows the chosen DNS mode and the first server answers LDAP and Kerberos queries.
Configure resolv.conf on every client
Set each enrolled Linux client to query at least two DNS servers in its resolver configuration, using the
resolv.conffile or the resolver manager your distribution uses. Where integrated DNS is in use, include the FreeIPA DNS servers. Where external DNS is in use, point clients at the servers that actually hold the records. Confirm that the search domain matches the IPA domain. Done meansgetent hostsanddigon a sample of clients return answers from both configured servers, with no fallback to a public resolver for internal names.Delegate or forward from the corporate DNS
Make the corporate DNS resolve the FreeIPA domain. For a dedicated subdomain, add NS records in the parent zone that point at the FreeIPA name servers, repeating the delegation whenever a new DNS server joins. For a shared namespace, configure conditional forwarding from the corporate servers to the FreeIPA servers instead. The corporate DNS team performs the change using their own process. Done means a query for the IPA domain sent to a corporate server returns the correct authoritative answer, and a query from outside the internal network does not expose internal names.
Verify SRV records from clients
From a freshly configured client, query the Kerberos, LDAP and Kerberos password SRV records for the IPA domain, along with the records for the domain's LDAP and KDC services. Compare each answer with the names in the design record. Use the same query from a second client on a different subnet to confirm that the records are visible across the network. Done means every expected SRV record resolves to the right servers from both clients, and the results are saved in the change record.
Verify the ipa-ca and host records
Resolve the
ipa-cahost record for the IPA domain from clients and from the corporate DNS path. Then confirm a forward lookup and a reverse lookup for one enrolled host and for one FreeIPA server. If integrated DNS is in use, add a test host and confirm that its A record appears after enrollment, with the client's dynamic update accepted. If external DNS is in use, confirm that the external team's records match what enrollment expects. Done means each record resolves correctly and any mismatch is logged with an owner and a fix date.Record the operating model and handover
Write down which records FreeIPA manages, which records the external team must maintain by hand, the change path for delegation and forwarders, and the checks to repeat after each server is added, removed or renamed. Schedule the verification commands from the previous steps as a recurring health check. Ask the implementation partner, or your own team, to confirm the list against the release you run. Done means the handover document names an owner for each record class and the checks run on a schedule.
What an external DNS team must maintain instead
When FreeIPA does not serve DNS, the external DNS team owns every record that clients and IPA servers depend on to find each other. The duties below are the ones most likely to break enrollment, replication-dependent services and Kerberos lookups if they drift out of sync with the FreeIPA topology.
SRV and ipa-ca records
FreeIPA normally publishes the SRV records that clients use to locate the LDAP, Kerberos and certificate services, plus the ipa-ca host record. With external DNS, the team must create and keep these records current in the zone, including for every new or retired IPA server. Confirm the full record set against the install documentation for your release before cutover, and treat any change to server names as a DNS change, not only an IPA change.
NS delegation for each DNS server
If FreeIPA serves a delegated subdomain, the parent zone needs NS records pointing at every FreeIPA DNS server. Each new replica that runs DNS requires a matching delegation update, and a missed update leaves resolvers querying servers that no longer answer. Ask the team who owns the parent zone and how a replica addition triggers a delegation change request.
Forwarders and forward zones
Clients and IPA servers resolve names outside the IPA domain through upstream resolvers, so the external team must keep those resolvers reachable from every IPA DNS location. Forwarding to Active Directory or corporate DNS adds a dependency on zones the IPA team does not control. Document which upstream servers answer for which domains, and test resolution from each site after any change.
Reverse zones and PTR records
Enrollment and Kerberos depend on forward and reverse resolution agreeing for each host, so the external team must maintain reverse zones for every subnet that hosts IPA servers or clients. Each address needs one PTR record that matches its A or AAAA record. Ask who creates PTR records when a host is provisioned, since DHCP or IPAM automation often handles this and drift is common.
Host record updates
Host records for servers and enrolled clients change when machines are rebuilt, renumbered or moved between sites. Without integrated DNS, nothing in FreeIPA updates the zone automatically, so the external team must receive and apply those changes. Stale A records can point Kerberos and LDAP clients at addresses that no longer belong to the intended host, so ask for a defined handoff from provisioning to DNS.
Change control for DNS
Because DNS sits underneath authentication, a bad record change can lock users out or break replication lookups across sites. Change control should cover SRV, delegation, forwarder and PTR edits, with a named owner, a review step that includes the IPA team, and a rollback plan. Confirm how emergency changes are approved and how the IPA team learns of them before a Kerberos incident starts.
Questions teams ask before choosing FreeIPA DNS
Does integrated DNS in FreeIPA cost extra?
No separate license fee applies to the DNS service itself, because FreeIPA is licensed under GPL-3.0-or-later and has no paid edition of its own, according to the project's COPYING file. Your costs come from the servers, the time to plan and build the design, and the staff who run it afterward. Integrated DNS also needs at least two DNS servers in each client's resolver configuration and at least one replica per datacenter running DNS if you use it, so the hardware and operations load is real even without a license charge. Ask any partner to separate one-time design and build work from recurring support and upgrade work in the quote.
How much extra effort does external DNS add to a FreeIPA install?
External DNS adds ongoing work rather than a large one-time task, because your DNS team must maintain every record FreeIPA would otherwise publish itself. Integrated DNS creates SRV records for Kerberos, LDAP and the Kerberos password service, and an ipa-ca record, and clients update their own address records dynamically. With an external server, those records must be created by hand or by automation, kept in sync when servers are added or renamed, and checked after every topology change. The effort depends mainly on how many servers and sites you run and how often they change.
What does the external DNS team need to maintain?
The external team owns every record that clients and FreeIPA servers depend on for discovery and certificates. In practice this includes forward and reverse records for each server and client, the SRV records FreeIPA expects, the ipa-ca record, and IP address records for any service that needs a certificate with an IP address subject alternative name. Ask the team to agree on a process for each change: who edits the zone, how serial numbers are bumped, how the change is tested with a client lookup, and how the change is recorded so the next topology change does not miss a record.
How long does it take to decide and deploy integrated or external DNS?
The decision usually depends on the ownership questions your organization must settle first, such as whether the DNS team accepts recurring record maintenance and whether a delegated subdomain is acceptable in the corporate zone. Those conversations, plus a short proof of resolution in a test environment, often set the pace more than the install itself. Deployment duration depends on the number of servers, the state of existing DNS zones, and any change approvals your organization requires. No duration figure is supplied here, so ask a partner to tie the schedule to a written scope and to the specific approval steps in your environment.
Can our own team set this up without a partner?
Yes, a capable team can install and run FreeIPA with its own staff, provided it has Linux administration skills, DNS experience and time to test. The areas most often underestimated are the record checks for an external DNS design, the replication and backup routine, and the rules for IP address SANs on certificates. A partner is most useful when the scope needs to be fixed in writing before work starts, when the team lacks one of those skills, or when a compliance assessment will later examine the controls. DeployOpen plans, implements, documents and supports FreeIPA inside your own infrastructure, and most engagements are fixed-scope, with the scope and deliverables agreed in writing before work starts.
What breaks first if external DNS records drift?
Clients fail to find domain controllers or the password and certificate services, and sign-in or enrollment errors appear before any obvious DNS alarm. Typical causes are a missing SRV record after a new replica is added, a stale address after a server is renamed, or a reverse record that no longer matches a forward record. Your team should test resolution from a sample of enrolled clients after each change and keep a checklist of the records FreeIPA expects. Confirm the exact record list against the version you deploy, because FreeIPA's requirements can change between releases.
Does the choice affect our certificates and security reviews?
It does, because IP address SANs on certificates need matching DNS and reverse records, and a compliance assessment will check how your DNS changes are controlled. Integrated DNS keeps much of that record handling inside FreeIPA, while external DNS moves it to a team with its own change process and logs. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications, which independent auditors and certification bodies do. Ask your assessor early which DNS change records they will want to see.
How DeployOpen scopes FreeIPA DNS decisions
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including FreeIPA. For integrated or external DNS, we start by writing down which zones FreeIPA must answer for, which team owns each record, and how clients will resolve names before any server is installed.
How we scope
- Inventory the zones, clients and existing DNS platforms that FreeIPA must integrate with or leave alone
- Record which team maintains SRV, ipa-ca and host records if DNS stays external
- Agree the written scope, deliverables and timeline before work starts, as engagements are fixed-scope
- Confirm the split DNS and IP address SAN constraints that affect your naming choices
How we build
- Build the DNS layout in a lab or staging copy of your environment before production changes
- Test forward and reverse resolution, SRV lookups and client dynamic updates from representative hosts
- Verify DNS server count in each client resolver configuration against the vendor deployment guidance
- Document every record or delegation that an external DNS team must create, change or monitor
How we hand over
- Deliver a written runbook covering zone ownership, update paths, forwarders and change procedures
- Provide test scripts that your team can rerun after upgrades, renewals or server additions
- Walk through the handover with the people who will own DNS records day to day
- Record open decisions, such as DNSSEC or zone transfers, with owners and review dates
How we support
- Offer ongoing support, upgrades and periodic testing as a retainer after handover
- Review DNS changes against the written design when new FreeIPA releases or replicas arrive
- Keep documentation current with changes made during support so your team can operate without us
- Scope each support request in writing so cost and responsibility stay visible
