Choosing a DNS domain and Kerberos realm name for FreeIPA

Choosing a FreeIPA DNS domain and realm name before the first install

Use a DNS domain you own or control as the primary domain of your FreeIPA deployment, and set the Kerberos realm to that domain in uppercase. Both values are fixed when the first server is installed, and changing them later is a rebuild, not a setting. The domain and realm name are the first thing you decide, so settle them with your DNS, identity and security owners before anyone runs the installer. The naming choice touches almost every component. FreeIPA combines 389 Directory Server for users, groups, hosts and policies, MIT Kerberos for single sign-on, the Dogtag certificate system, SSSD on clients, and optional ISC BIND DNS. Kerberos principals, service names, host entries, SRV records, certificate subject names and client configuration all derive from the domain and realm. A name chosen casually for a lab can end up in certificates, keytabs and every enrolled Linux host, so treat it as a permanent identifier.

Teams face this decision in three situations: a new deployment, a migration from another directory or from a non-RHEL install, and a deployment that must coexist with Active Directory. In the coexistence case, the IPA domain must not overlap with any domain in the AD forest, which is a hard rule for a cross-forest trust. Check every AD forest and any future merger partner before you pick a name. Avoid inventing top-level domains such as .local or other names that are not delegated to you, because public certificate and resolution behavior can break in ways that are hard to diagnose. Confirm your naming policy with your DNS team and record the decision in a design document that names the domain, the realm, and the reasons.

Which naming pattern fits your organization

A dedicated identity subdomain, such as ipa.example.com (illustrative), sits under a domain your organization already runs in corporate DNS. The parent zone stays with your existing DNS team, and the FreeIPA realm follows the subdomain, for example IPA.EXAMPLE.COM (illustrative). This keeps the namespace familiar to staff, but the parent zone must delegate the subdomain to FreeIPA name servers, and every new FreeIPA DNS server needs its own delegation entry. Confirm with your DNS team who owns those records and how they change them.

Delegation load: Each FreeIPA DNS server you add needs matching NS records in the parent zone, so changes depend on another team's change process.
Trusts: A subdomain under a shared parent is easy to confuse with AD domains that use the same parent, so check every existing forest name before you commit.
Mergers: A later merger that brings in the same parent domain usually means reworking names, not just adding a forest.
Naming clarity: Staff and tools can tell identity hosts apart from application hosts when the subdomain is named for its purpose.
Confirm: Ask your DNS team whether they can delegate a subdomain, and who approves changes to the parent zone.

A primary domain you own, used for nothing else, gives FreeIPA the whole namespace. An illustrative example is corp-identity.example with realm CORP-IDENTITY.EXAMPLE. Because no other directory uses the name, FreeIPA can own its own zone without splitting records with another system. The cost is that the domain must be registered and kept in your control, and your organization needs to decide how it will be used for email, web and hosts.

Ownership: You control the zone outright, so delegation is simpler than under a shared parent.
Registration: The domain must be registered to your organization and renewed on schedule, which is a recurring administrative task.
Trusts: An unused domain avoids overlap with any AD forest, which the trust design requires.
Mergers: A separate primary domain makes it easier to add or join another forest later, because the names do not collide.
Confirm: Check that the domain is not used by any AD forest, partner or public website your teams rely on.

Naming options compared

This table compares five ways to name a FreeIPA DNS domain and its Kerberos realm. Read each row for the pattern, the situations where it fits, the risks that are hard to undo, and what to confirm before install. The main takeaway is that any option overlapping an Active Directory DNS domain blocks a cross-forest trust, so check that first.

Pattern	When it fits	Risks	What to confirm
Own primary domain used only for FreeIPA	Greenfield Linux identity with no AD forest planned and a domain your organization owns and controls	Needs DNS delegation or a registered name you control; the name becomes hard to change later	Domain is registered to you, no AD domain or sibling zone uses it, and the realm will be the uppercase form
Delegated subdomain of a corporate domain	Corporate DNS team can delegate a zone such as an ipa subdomain to FreeIPA name servers	Parent zone changes needed for every new FreeIPA DNS server; overlap with existing corporate records is easy to miss	Delegation process and owner, whether the subdomain is used by any other system, and that no AD domain overlaps it
Existing corporate domain shared with AD	Organization already runs AD on the same domain and wants Linux users in the same namespace	Trusts require a non-overlapping DNS domain, so a cross-forest trust with AD is not possible on this name; split-DNS pressure follows	Whether a trust is needed at all, and whether AD domain names already cover the proposed IPA domain
Invented or unregistered top-level domain	Lab or isolated network where no public naming is planned	Unregistered top-level names can collide with real names later; certificates and external resolution become hard to manage	Whether the network will ever connect to other organizations, and whether a registered domain can be used instead
Split DNS view with the same name inside and outside	Teams want one hostname to resolve differently on internal and external networks	DNS views are discouraged for FreeIPA; clients and certificate names can disagree, and the setup is hard to troubleshoot	Whether the need can be met by separate internal names or by an external DNS team maintaining public records

Avoiding overlap with Active Directory domains

The IPA domain you choose must not overlap with any DNS domain in an Active Directory forest you plan to trust. FreeIPA can establish a cross-forest trust with Active Directory through Samba components, and the FreeIPA Trusts page states that the IPA domain must use a DNS domain that does not overlap with any domain in the AD forest. Before you name anything, list every DNS domain the AD forest uses: the forest root, every child domain, and any tree roots added to the forest. Include domain names that appear only in internal certificates, Kerberos realms or old mail routing, because those are the ones teams tend to forget. Ask the Windows team to confirm the list from the forest itself rather than from a diagram.

Settle this before the trust design, not after. The trust type, the ID mapping approach, the DNS forwarding between the two environments and the way Windows clients find domain controllers all depend on which names are in use. If the IPA domain overlaps an AD domain, the trust design has to be reworked, and the IPA realm and domain names are hard to change later. Record the chosen names alongside the AD inventory so that the trust, forwarding and coexistence decisions can reference one agreed naming plan. Use the trust and AD coexistence topics on this page for the follow-on decisions, including which trust type fits your forest layout and how DNS forwarding should be arranged between the two systems.

Why invented top-level domains cause trouble

An invented suffix such as one ending in .corp or .internal works until the name meets the public internet, a partner or an auditor. The cards below show where that happens, so you can check each risk with your DNS and certificate teams before the realm is set.

Collision with public domains

Any suffix you invent may already belong to a company, a product or a future public top-level domain. If your FreeIPA domain matches such a name, clients may resolve the public record instead of your internal host, and sign-in can fail with errors that do not point to DNS. Ask your DNS team whether the suffix appears in the public root and whether any vendor product in your estate uses it.

Certificates trusted only internally

Public certificate authorities issue certificates only for names they can validate through the public DNS hierarchy, so a suffix nobody owns cannot be validated. Services that partners or browsers must trust then depend on your private CA being installed everywhere it is needed. Ask your certificate team which hostnames must be publicly trusted and keep those under a subdomain of a domain you own.

Conflicts with future delegation

A subdomain you delegate later, such as one for a new business unit or an acquired company, may fall under the same invented suffix already used internally. Two teams then answer for the same names, and records published by one can shadow the other. Map the expected naming tree before choosing the realm and list every suffix your organization may need to delegate.

Harder external DNS and secondary service

When an external DNS provider or secondary server must host a zone, the zone needs a parent that can delegate it. An invented suffix has no delegation chain you can audit, so NS records, zone transfers and resolver settings depend on private arrangements that outside teams may not understand. Confirm with your network and DNS teams how the zone will be served before you commit to the name.

Proving ownership of the name

When an auditor, a partner or a public certificate authority asks who controls a domain, an invented suffix offers no public registration record and no delegation from a root you hold. Your evidence then rests on internal documents that outsiders cannot check. Ask your compliance lead which evidence of ownership assessors accept and whether an owned subdomain of a registered domain meets that bar.

Overlap with Active Directory names

If you plan a cross-forest trust with Active Directory, the IPA domain must use a DNS domain that does not overlap with any domain in the AD forest. An invented suffix chosen only because it looks unused internally can still match an AD forest name. Compare your candidate name with every AD forest domain before the realm is set, using the FreeIPA Trusts documentation as the rule to check against.

How to settle the domain and realm before install

This sequence turns the naming question into a written decision that DNS, PKI and Active Directory owners have all reviewed, so the FreeIPA domain and Kerberos realm are fixed before any server is built.

Inventory existing DNS zones and AD domains
Collect every DNS zone your organization already serves or resolves internally, including split-horizon zones, cloud private zones and any Active Directory forest and domain names. The DNS team and the AD team each supply their list, and the output is a single spreadsheet with zone name, owner, authoritative servers and whether the zone is public or internal. Done when both teams have confirmed the list in writing and nobody knows of an omitted zone.
Pick the primary DNS domain and confirm ownership
Choose a DNS domain that your organization owns outright and can delegate, such as a subdomain of a registered domain you control, for example an illustrative ipa.example.com. Avoid invented top-level domains and avoid any name that overlaps a domain in the AD forest, because FreeIPA's trust documentation requires the IPA domain not to overlap with AD domains. Done when the DNS owner confirms in writing that the name is owned, delegable and not used for mail, web or other services.
Derive the uppercase Kerberos realm
Set the Kerberos realm as the uppercase form of the chosen DNS domain, so an illustrative ipa.example.com becomes IPA.EXAMPLE.COM. Check that the realm name does not collide with another realm your organization already trusts, such as an existing MIT Kerberos realm or an AD realm. Done when the realm string is written next to the domain string and the Kerberos owner has confirmed no clash.
Check for zone, host name and certificate conflicts
Query every candidate name and its subdomains from inside and outside your network, and confirm that no existing A, AAAA, SRV or CNAME records, host names or certificate subject names already use the domain. Review the internal certificate authority inventory for any certificate issued under the same names. Done when the query results are recorded and every conflict has an owner and a resolution, or the candidate name is replaced.
Record the decision with DNS, PKI and AD owners
Write a short decision record that states the primary DNS domain, the Kerberos realm, the reasons for the choice, the rejected alternatives and the trust plans, then obtain sign-off from the DNS, PKI and Active Directory owners. Include the planned delegation point and whether FreeIPA will serve DNS or only be delegated to. Done when all three owners have signed the record and it is stored where change control can find it.
Confirm install inputs against the version documentation
Before scheduling the build, read the install and prerequisite documentation for the exact FreeIPA version you plan to deploy and confirm which domain, realm, host name and DNS inputs it expects and how it validates them. Note any differences from earlier releases your team may have used. Done when the install inputs are listed in the decision record, checked against the version's documentation, and the platform team has accepted them.

Security considerations in the naming choice

The domain and realm name become part of certificates, Kerberos identities, delegation chains and access rules. Each card below covers one place where the naming decision carries security weight, and what to check before the first server is installed.

Certificate names and SANs

FreeIPA issues host and service certificates from its own Dogtag certificate authority, and those certificates carry names taken from the domain. A name chosen now is embedded in every service certificate you issue later. Confirm the fully qualified host names and service aliases you will use, and check that they fall under a domain you own and can prove control of. Clients that trust the IPA CA will accept any name it signs, so keep the namespace under your control.

Control of the parent zone

If you delegate a subdomain such as ipa.example.com from corporate DNS, the parent zone owner controls whether FreeIPA resolves at all. Whoever can edit the parent zone can add or remove NS records and redirect the delegated name. Record who owns that parent zone, how changes are approved, and whether the same team also manages the FreeIPA servers. Separating those duties reduces the chance that one compromised account can redirect authentication traffic.

Who can change DNS records

Inside an integrated FreeIPA DNS zone, the zone is also the source of service records that clients use to find Kerberos KDCs and the CA. Anyone with permission to change records in that zone can influence where clients send authentication requests. Review the FreeIPA DNS permissions and the client dynamic update settings before go-live, and confirm which groups hold write access to the zone and to the reverse zones.

Realm name in principals and trusts

The realm is normally the uppercase form of the primary domain, and it appears in every Kerberos principal, such as user@REALM. Cross-realm and cross-forest trusts identify your realm by that name. FreeIPA's trust documentation requires the IPA domain not to overlap with any domain in an Active Directory forest you trust, so a name collision with an existing AD domain creates a trust that cannot be configured cleanly. Check the planned realm against every forest and trust partner before install.

Effect on hardening and access policy

Host-based access control, sudo rules, password policies and certificate profiles are written against host and user names that include the domain. A rename after rules are written means editing those objects and retesting access. Decide the naming scheme for host groups and service principals before writing policy, so that access rules match stable names. Plan a review of these rules whenever you apply security hardening or change authentication methods.

Check advisories before setting names

FreeIPA 4.13.4, dated July 9, 2026, fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials, and it hardened authentication checks across the API. Install the current stable release rather than a version that predates those fixes, and read the advisories for your release before you finalize the naming and access design. Ask your implementation team to confirm which release and advisories apply at the time of your install.

Questions buyers ask about FreeIPA domain and realm naming

Can we change the FreeIPA domain or realm name after deployment?

Plan as if you cannot, because the name is recorded in host and service principals, certificates, DNS records and client configuration across the whole deployment. Renaming is not a routine operation in the FreeIPA documentation, so treat any change as a project in its own right. The fallback is a new deployment with a planned cutover: the ipa-migrate tool moves users, groups, hosts, DNS, OTP tokens and policies between two FreeIPA deployments over LDAP. Your team should confirm exactly what changes for the version you intend to run by testing a rename in a lab that mirrors production. The naming review should therefore end with a written decision record that the DNS, PKI and identity owners have all signed off.

Do we need a public domain for FreeIPA, or is an internal name enough?

An internal name is enough for most FreeIPA deployments, but it must be a name your organization owns and controls. Use a subdomain of a domain you already hold, such as a dedicated zone for identity, so that delegation from your corporate DNS is straightforward. Avoid invented top-level suffixes and avoid .local, which multicast DNS reserves for its own use and which causes name resolution surprises on Linux hosts. The name does not have to resolve on the public internet, but any service that needs a certificate trusted outside your network will need public DNS names and a public certificate path. Confirm with your DNS and PKI owners which services are exposed before deciding.

Can we use our Active Directory domain name for FreeIPA?

No. The FreeIPA trusts documentation says the IPA domain must use a DNS domain that does not overlap with any domain in the Active Directory forest. In practice this rules out reusing the AD domain name, and it also needs a check of parent and child domains, because overlapping namespaces make trust and name resolution ambiguous. If you plan a cross-forest trust later, choose the IPA domain with that trust in mind from the start, and list every AD forest and domain the trust will touch. Confirm the exact overlap rules for your AD topology with your AD owner and against the FreeIPA Trusts page before fixing the name.

What does a FreeIPA naming review cost and how long does it take?

No price or duration figures have been published for this work, and DeployOpen does not publish a price list. A quote follows from a written, fixed scope. The main cost drivers are the number of DNS domains already in use, whether an Active Directory trust is planned, how many sites and replicas are expected, whether public certificates are needed, and whether an external DNS team must maintain delegation. Costs rise if existing LDAP directories or FreeIPA estates must be mapped into the new name. The review itself is a one-time cost, while ongoing change control is recurring. When you ask for a quote, request the list of decisions, the workshops and attendees, the deliverables such as the decision record and lab validation, and the assumptions about your environment.

What does the naming work need from our DNS, PKI, AD and security teams?

The naming decision touches four groups, and each should confirm specific facts before the workshop:

DNS owners: the parent zone, whether they will delegate a subdomain to FreeIPA name servers, and who maintains records if DNS is external.
PKI owners: the existing certificate hierarchy, whether FreeIPA's Dogtag CA will sit under or beside it, and which service names need certificates.
AD owners: every forest and domain in use, any planned trusts, and any existing names that could overlap.
Security owners: the policy on exposed names, the audit evidence required, and any sector rules that govern identity infrastructure.

The review needs named individuals with decision authority from each group, because a name agreed by only one team is the most common source of later rework.

Can our own team choose and document the FreeIPA naming?

Yes, if your team has working knowledge of DNS delegation, Kerberos realms, certificate chains and Active Directory namespaces, and can test the result in a lab before production. FreeIPA is a GPL-3.0-or-later community project with no paid edition, so the software itself carries no license fee, and the cost is staff time and the risk of an expensive mistake. Your team should produce a written decision record covering the domain, the realm, the AD overlap check, the public name strategy and the DNS ownership model. If one of those skills is missing, a fixed-scope review from DeployOpen can supply the missing expertise, and ongoing support is available as a retainer after the design is settled.

Which FreeIPA naming mistakes cause the most trouble later?

The most expensive mistakes tend to be the ones that are hardest to see during a quick design:

Reusing an Active Directory domain or a name that overlaps with an AD namespace, which blocks a future trust.
Choosing an invented suffix or .local, which conflicts with other resolvers and certificate expectations.
Sharing the identity domain with mail or web domains, which ties identity changes to unrelated services.
Relying on DNS views to show different answers to different clients, which the FreeIPA guidance discourages because split answers are hard to test and troubleshoot.

Each of these should be checked against your environment and tested in a lab. Confirm the DNS behavior with your DNS owners before the name is fixed.

How DeployOpen scopes the naming decision

The naming decision is settled in writing before any server is built. DeployOpen is a Chainscore Labs company, and it plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a FreeIPA domain and realm, that means the scope document records the chosen primary DNS domain, the Kerberos realm derived from it, the hostnames that will carry the realm, and the list of existing namespaces the choice must not collide with. Most engagements are fixed-scope, so these decisions are agreed and signed off before work starts rather than discovered during installation.

The decision touches several owners, and the scope should name each of them. The DNS team owns the parent zone and any delegation. The PKI owner needs to know the realm because certificate subjects and service principals depend on it. The identity and security owners decide whether an Active Directory forest or other Kerberos realm already exists under a related name. DeployOpen documents each deliverable, including the naming record, the DNS delegation or forwarding requirements and the verification steps, so your teams can check them without depending on the implementer. Ask for that document to name the owner who approves each item.

DeployOpen prepares the systems, configuration and evidence that a compliance assessment may examine, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. Ongoing support, upgrades and continuous testing can be set up as a retainer once the naming is in place, which matters because a later rename is far more expensive than a correct first choice. Confirm the retainer terms and the handover of the naming record in the written quote.