When delegating a DNS subdomain to FreeIPA is the right approach
Delegation fits when your corporate DNS team owns example.com and you want FreeIPA to serve its own child zone, such as ipa.example.com, with the FreeIPA name servers answering for every record inside it. In the parent zone, the corporate team adds NS records that name the FreeIPA DNS servers for the child zone. From that point, resolvers that ask the parent for names under ipa.example.com are referred to FreeIPA, and FreeIPA alone is authoritative for those names. Nothing in the parent zone needs to hold the individual host records, service records or certificate authority records inside the child zone.
This arrangement compares with the alternative in which FreeIPA does not serve DNS at all and an external DNS team maintains every record by hand. Delegation keeps the FreeIPA-managed records under FreeIPA's control, so they follow host enrollment, service changes and server changes without a ticket to the DNS team each time. External management suits organizations whose policy requires every record to pass through one team's change process, but that team then has to maintain the SRV and service records FreeIPA clients depend on. Confirm with the DNS team which records they will own, who approves NS changes in the parent, and whether your security policy allows FreeIPA name servers to be authoritative for a zone at all.
Choose the domain and Kerberos realm names before you delegate, because changing them later is far harder than changing NS records. Those decisions, along with overlaps with Active Directory, are covered on the sibling page on naming a FreeIPA deployment. The exact NS and glue layout depends on your chosen DNS design, the number of FreeIPA DNS servers and the FreeIPA version in use, so confirm the record set against that version's documentation and against your own parent zone before the change window. Treat the first delegation as a design decision that the rest of the DNS plan depends on.
Delegation options and when each one fits
This table compares three ways to delegate a subdomain to FreeIPA name servers: one server, every IdM DNS server, and a narrower zone that holds only the names FreeIPA needs. Read each row against your corporate DNS platform's change process, because the cost of adding a server depends on how that platform handles NS and glue records.
| Option | What the parent zone holds | What changes when a server is added | When it fits |
|---|---|---|---|
| Single FreeIPA DNS server delegated | One NS record and glue for one IdM DNS server | Nothing in the parent zone changes, but clients depend on that one server for delegated answers | Small, short-lived or lab environments where resilience is handled elsewhere (confirm this is acceptable for your clients) |
| Delegation to every IdM DNS server | An NS record and glue for each IdM DNS server | Parent zone must be updated for each new server, and removed when one is retired | Most production deployments, since the recommendation is at least two DNS servers in each client's resolv.conf |
| Full subdomain delegation | NS records for the whole ipa subdomain, with all FreeIPA-served zones below it | Changes stay inside FreeIPA, but the parent team must still update NS and glue when servers change | Organizations that want FreeIPA to own all names under one subdomain and keep parent zone edits rare |
| Narrow delegation of selected names | Delegation only for the zones FreeIPA must answer, with other names kept in corporate DNS | Each new FreeIPA-served zone needs a parent change, which can add review work | Environments that keep most records in corporate DNS and only need FreeIPA for service and realm names |
| Forwarding instead of delegation | No NS records for FreeIPA; corporate DNS forwards queries to IdM | Forwarder targets change when IdM servers change, and automatic records may not resolve as expected | Teams that do not want IdM to be authoritative for a subdomain (confirm how this affects automatic SRV records) |
| Parent zone platform handling | Depends on whether glue is required and how the platform validates NS changes | Confirm whether glue records are created automatically, how changes are approved and how long they take to publish | Every option above, before the design is finalized |
Set up the delegation step by step
This sequence moves ipa.example.com from a single corporate DNS zone to FreeIPA name servers, so that the parent zone points resolvers at FreeIPA and every server answering for the subdomain returns the same records. Each step ends with a check you can run before moving on.
Agree the subdomain name with the DNS owner
Before any installation, the FreeIPA owner and the corporate DNS owner agree on the exact subdomain, such as ipa.example.com, and on which server names will act as its name servers. Confirm in writing that the parent zone is editable by the team that will make the change, and that no other record already uses the subdomain. The output is a short written record of the zone name, the planned name server hostnames and the person who will add the NS records. Check it by querying the parent zone for the subdomain and confirming that it returns no existing delegation or conflicting records.
Install FreeIPA with integrated DNS for the zone
Install the first FreeIPA server with integrated DNS and set the primary DNS domain to the agreed subdomain, so FreeIPA is authoritative for ipa.example.com and its apex. The install creates the zone apex records, including the SOA and the NS records for the first server, and the automatic SRV records clients use to find the domain. Keep the naming decisions from the planning pages in mind, because the domain cannot be changed later without rework. Check the result by querying the first server directly for the zone apex and its NS set, and confirming that the answer is authoritative.
Confirm the apex and NS set on every FreeIPA DNS server
Add each additional FreeIPA DNS server (replica running DNS) and confirm that each one serves the same zone and lists the same NS set at the apex. The deployment recommendations advise at least two to three replicas in each datacenter, with at least one replica per datacenter running DNS if it is used, so plan this set before delegating. Query every listed server for the NS records of the zone with the authoritative flag set, and compare the answers. Do not continue until every server returns the same NS names and each one answers authoritatively.
Add NS records in the parent zone
In the corporate parent zone, the DNS owner adds one NS record for the subdomain for each FreeIPA name server name agreed in the first step. These records create the delegation, so resolvers for the parent zone send queries for the subdomain to FreeIPA rather than to corporate servers. Do not add the records to the subdomain itself, and do not list servers that do not yet serve the zone. Check by querying the parent zone's servers for the NS set of the subdomain and confirming that it lists exactly the agreed names.
Add glue records for in-zone name servers
If a name server name sits inside the delegated zone, such as ns1.ipa.example.com for the zone ipa.example.com, the parent zone must also carry an address record for that name. Without this glue, resolvers cannot reach the server by name because the lookup would depend on the same delegation. Add an A record (and AAAA if IPv6 is used) for each such name in the parent zone, with the address of the FreeIPA server. Check by querying the parent zone for the glue address of each in-zone name server and confirming the address matches the server's own configuration.
Wait for the parent TTL to pass
Resolvers keep the old answers until the cache expires, so the delegation takes effect gradually after the parent zone changes are published. Confirm the TTL on the NS and glue records in the parent zone with the DNS owner, and do not run cutover tests until that period has passed. Record the time of the change so that the test results can be compared against it. The output is a confirmed publication time and an agreed test window. Check it by querying the parent zone's published serial and confirming the new records are visible from its authoritative servers.
Verify delegation from several vantage points
Test the delegation from a client network, from a server in each datacenter and from an external resolver if the zone is meant to be reachable from outside. Run a query for the NS set of the subdomain and compare it with the NS set on each FreeIPA server, then resolve a known host record and an SRV record for the Kerberos service such as _kerberos._udp. Check for resolution from each vantage point, and treat any NXDOMAIN, SERVFAIL or mismatched NS answer as a stop condition. Keep the results with the change record so that later troubleshooting starts from a known-good baseline.
Document the delegation and its owners
Store the agreed subdomain, the NS and glue records, the list of FreeIPA DNS servers, and the owner of each record in the change system, so that every future FreeIPA DNS server requires a matching NS update in the parent zone. The documentation should also name who approves that change and what test must pass before it is considered complete. This record is the reference for adding or removing a server later, which the replication and DNS planning pages cover in more detail. Check that the documented NS set matches the live parent zone and the live FreeIPA servers.
Why every new FreeIPA DNS server needs a new delegation change
Adding or removing a FreeIPA DNS server does not update the parent zone on its own. The NS records for ipa.example.com live in the corporate zone, so every change to the set of FreeIPA name servers needs a matching change in the corporate DNS change process. FreeIPA will happily start or stop answering queries on a new host, but resolvers that query the parent zone will keep using whatever NS set was last published there. Plan the delegation change as part of the server change, not as an afterthought once a client has already failed to resolve.
The link to replica planning is direct. The FreeIPA deployment recommendations advise at least one replica per datacenter running DNS when DNS is used, so a multi-site topology implies several NS entries that must all be published and kept current. Before you add a DNS-enabled replica, confirm which NS records the corporate team will publish, which datacenter each one points to, and whether the replica is intended to stay. Ask your DNS team how long a corporate change takes from request to published record, and confirm that lead time with them rather than assuming one. Schedule server changes around that window.
A stale NS entry is the most common way this goes wrong. When the parent zone lists a server that has been decommissioned or renamed, queries sent to it receive no answer, which is a lame delegation. Resolvers then retry other listed servers, so the symptom can be slow or intermittent resolution rather than a clean outage, and it often appears only from some networks. Keep a change record that ties each FreeIPA server's hostname and IP address to its NS and glue entries in the parent zone, with the date of each change and the request reference. Review that record on every server add, remove or rename, and test each listed server directly from outside the FreeIPA network before closing the change.
Common delegation failures and how to avoid them
Most delegation problems show up as resolution failures that look random to the people who hit them. Each failure below has a distinct symptom and a check that confirms or rules it out, so you can test the parent zone, the FreeIPA side and the resolvers in a fixed order.
Lame delegation from a listed server
The parent zone lists a FreeIPA name server that no longer answers for the subdomain, or answers without being authoritative for it. Queries for names under ipa.example.com time out or return SERVFAIL intermittently, which often gets blamed on clients. Query each NS name directly with dig using the +norec flag and confirm each one returns the aa flag and the SOA for the delegated zone. Repeat this for every NS record, not just the first.
Missing or wrong glue records
When a name server name sits inside the delegated zone, the parent must carry A or AAAA glue for it, or resolvers cannot reach the server to ask for the NS names in the first place. A missing or stale glue address sends queries to a host that has moved or is not running DNS. Compare the glue in the parent response (the additional section of an NS query sent to the parent) with the address each FreeIPA server reports for itself.
NS names that resolve to wrong addresses
An NS record can be correct while the host name it points to resolves to an address that belongs to another machine, a load balancer or an old IP. Resolvers then query the wrong host and the failure appears as lame delegation even though the parent is right. Resolve each NS target from outside the FreeIPA network and confirm the answer matches the server's own address. Also confirm reverse records exist, because the FreeIPA install and later checks depend on them.
Caching hides a fix
Recursive resolvers cache NS records and glue for the TTL set in the parent zone. After you correct a delegation, some clients keep receiving the old answer until those cached entries expire, so a fix appears to fail. Before changing a delegation, record the current TTL with dig NS ipa.example.com and plan the cutover around it. After the change, query the authoritative servers directly first, then query your production resolvers, and only then declare the fix complete.
Split DNS answers from internal and external views
If the corporate DNS serves one answer for ipa.example.com to internal clients and another to outside queries, FreeIPA may hold records the internal resolvers never return. Clients enrolled through the internal view can then fail to find SRV records or the CA host. Query the same name from an internal resolver and from an external one and compare the answers. Keep the delegation identical in both views unless you have documented why it must differ.
Parent zone changed before FreeIPA is ready
The corporate DNS team may publish NS records before the FreeIPA name servers are installed, reachable, and serving the zone, or they may remove the old delegation before the new one is answering. Either order produces an outage for every host that depends on the subdomain. Agree on a sequence in which the FreeIPA side is verified first, the parent change is made second, and the old records are removed only after resolution through the new servers has been confirmed.
How to test resolution after delegation
Start on a FreeIPA server that runs DNS, because it shows whether the zone is loaded and answering authoritatively. Run dig NS ipa.example.com, dig SOA ipa.example.com, dig A host.ipa.example.com for a host you know exists, and dig A nonexistent.ipa.example.com for a name that should not exist. Use @127.0.0.1 so the query does not leave the machine.
- NS query: The answer should list every FreeIPA DNS server you intend to publish, with the
aaflag set in the response header. - SOA query: The answer should return the zone's primary server and a serial number. A missing SOA usually means the zone was never created or is not loaded.
- A query for a known host: A correct address confirms the record exists and the server is authoritative for it.
- NXDOMAIN for the missing name: A
NXDOMAINanswer with a SOA in the authority section is the expected result. Forwarding or a wildcard would show up here as an unexpected address.
If the server refuses or returns SERVFAIL, check that the named service is running and that the zone is listed in the server's configuration. Confirm the expected behavior of your FreeIPA version with the FreeIPA documentation before you change any settings.
Run the same queries from an enrolled client without naming a server, so the test uses the resolv.conf the client actually receives. Check /etc/resolv.conf first, then run dig NS ipa.example.com, dig SOA ipa.example.com, dig A host.ipa.example.com and dig A nonexistent.ipa.example.com. Compare the answers with the FreeIPA server results.
- Configured resolvers: Confirm that the client lists at least two DNS servers, as the FreeIPA deployment recommendations advise.
- Matching answers: The same records should return from the client as from the server. Differences often point to a stale or wrong nameserver entry.
- Name service switch: Check the
hostsline in/etc/nsswitch.confand comparegetent hosts host.ipa.example.comwithdig. A difference suggests a cache, a local resolver or a misordered lookup. - Negative answer: The missing name should return
NXDOMAINon the client, not an address from a search domain.
When a client fails but the server passes, look at the resolver configuration, a local caching service and firewall rules on UDP and TCP port 53 between the subnet and the FreeIPA servers.
The corporate recursive resolver is where most delegation faults appear, because it must follow the NS records from the parent zone to the FreeIPA name servers. Query it directly with dig @resolver-address NS ipa.example.com and then the SOA, A and NXDOMAIN queries. Use +norec against the parent-zone authoritative servers as well, so you can see the delegation itself.
- Referral path: A query to the parent zone's authoritative servers should return the NS records for
ipain the authority section, with glue addresses where the name servers sit inside that zone. - Recursive answer: The recursive resolver should return the same NS, SOA and A answers as the FreeIPA servers, with the
aaflag cleared because the answer is not authoritative for the subdomain. - Stale cache: If the answer is old, compare the TTL in the response with the TTL you set on the delegation.
- SERVFAIL: This usually means the resolver cannot reach a listed name server or that DNSSEC validation failed. Confirm the state of DNSSEC with your FreeIPA version before you change validation settings.
A failure here points to the parent zone, a missing or wrong glue record, or a forwarder on the resolver that bypasses the delegation.
Test from outside the corporate network only if the zone is meant to resolve publicly. Most FreeIPA zones are internal, so a failure here may be the intended result. Confirm the intended audience before you run the test. Use a public resolver or a host outside your network and query the published zone with the same four queries.
- Expected behavior: An internal-only zone should return no answer or
REFUSEDto outside resolvers. A public-facing zone should return NS and A records that match your published design. - Authoritative reachability: Query each published FreeIPA name server directly from outside with
+norec. Timeouts point to firewall rules or to a name server that does not listen on the public address. - Split exposure: Check that internal host records and address ranges do not appear in answers you did not intend to publish.
- Protocol support: Test over TCP as well as UDP, because large responses and zone-related queries may fall back to TCP.
A failure here usually points to network filtering, a name server listening on the wrong interface, or records that were published in error. Confirm the public exposure policy with your security team before you open the zone.
Security and change control for the parent zone
Delegating a subdomain changes what the corporate parent zone publishes and who can influence resolution for an entire identity domain. The cards below cover who may edit that zone, how delegation changes get reviewed, which hosts may write to the FreeIPA zone, who may transfer it, and how NS changes are recorded.
Who can edit the parent zone
Write access to the corporate parent zone is the most sensitive DNS permission in the design, because an NS record change there decides which name servers answer for the whole ipa subdomain. Limit write access to a named group of DNS administrators, and keep FreeIPA administrators out of that group unless they have been approved for it. Check who holds rights to the parent zone today, including service accounts used by automation and any registrar or DNS hosting console access.
Review delegation like other DNS changes
An NS delegation record is a production change with the same blast radius as an A record for a critical service. Route it through the change process your DNS team already uses, with a written request, a named approver, a rollback plan and a test window. Confirm that the request names every FreeIPA server that will hold the zone, not only the first one installed.
Restrict dynamic updates by host
FreeIPA accepts dynamic DNS updates from enrolled clients, so the zone can change without a ticket. Decide which hosts and principals may update records, and confirm in your FreeIPA version how dynamic update permissions are granted and whether they are limited to the hosts that need them. Keep updates from outside the IPA domain blocked at the parent zone and at the network edge.
Limit zone transfer targets
Zone transfers copy the full contents of the ipa subdomain to any server that is allowed to request them, so transfer lists should name only known secondary servers. Transfers are disabled by default in FreeIPA, but confirm that state in your version and on each replica before enabling anything. Record the source addresses allowed to transfer and review them when the secondary topology changes.
Log every NS change
An audit trail should show who changed the delegation, when, from which account, and which name servers were added or removed. Enable logging on the parent DNS platform and export it to your central log store, then alert on any change to NS records for the ipa subdomain. Keep the record of approved changes beside the logs so an auditor can match each change to its request.
What to confirm in your environment before you change the parent zone
Before you add a single NS record to the parent zone, confirm which DNS software and which FreeIPA version you run, and how that version's DNS service behaves in your deployment. The delegation depends on FreeIPA answering authoritatively for the child zone on every name server you list, so you need to know the exact package set, the service that listens on port 53, and whether the FreeIPA DNS service is enabled on each server you intend to delegate to. Check the FreeIPA version against the release notes you plan to follow, because DNS behavior has changed between 4.x releases. Ask the team that owns FreeIPA to show you the output from each server, not a summary, and record it as the baseline for your change record.
Next, confirm whether your corporate DNS platform accepts glue records for name servers that sit inside the zone being delegated. A delegation such as ipa.example.com served by ns1.ipa.example.com is only resolvable if the parent zone carries address records for those servers, and some platforms reject, hide or silently rewrite them. Also confirm the TTL on the NS and glue records in the parent zone and the caching policy of your recursive resolvers, since a resolver that cached the old answer will keep sending queries to the previous servers until the TTL expires. Plan the change window around that value and confirm it with the operators of the resolvers your clients use. Verify the parent zone's own TTL and any minimum-TTL policy with the platform owner, not from memory.
Finally, decide how the delegation interacts with DNSSEC and with internal and external views. If the parent zone or the child zone is signed, the DS record and the signing keys must be coordinated before the delegation goes live, and that work is covered in the DNSSEC sibling topic. Confirm whether the same name is published in both an internal and an external view, because a split view can return one set of name servers to internal clients and another to external ones, and a resolver that sees conflicting NS sets will fail in ways that are hard to diagnose. DeployOpen confirms each of these items against the written scope before any parent zone change is made, and the outcome is recorded in the delivery documentation.
Questions teams ask before delegating DNS to FreeIPA
How much effort does delegating a DNS subdomain to FreeIPA take?
The effort is mostly coordination rather than configuration. The work is small per record (an NS record set in the parent zone, plus glue where the name servers sit inside the delegated domain), but it grows with the number of FreeIPA DNS servers, the number of zones involved, the change approval process at the corporate DNS owner, and how far the testing goes. Each new FreeIPA DNS server needs its own NS record in the parent zone, so every server added later repeats the change. Ask any partner to break its quote into parent zone changes, FreeIPA configuration, client resolver checks and test cases.
How long does the parent zone change take to reach clients?
The timing depends on two things: the corporate change window and DNS caching. Most corporate DNS teams approve changes to production zones only during scheduled windows, so the calendar often sets the start date. After the change is live, resolvers keep the old answer until the cached records expire, which is controlled by the TTL values on the NS records and on any cached negative answers. Ask the corporate DNS owner for the TTL on the parent zone and for the change calendar before setting a go-live date.
What does the corporate DNS owner need to provide?
The corporate DNS owner must approve and publish the NS records for the delegated subdomain, confirm the names and addresses of the FreeIPA DNS servers, and agree on who edits the parent zone afterward. They also need to know whether the parent zone is signed with DNSSEC, because a delegation to a server that does not follow the same signing policy can cause validation failures. The identity team needs to supply the server host names, IP addresses, the domain name in use, and a list of clients that will query the new servers.
Can an internal team delegate the subdomain without outside help?
Yes, if the team has someone who can edit the parent zone under change control, someone who runs FreeIPA, and a way to test resolution from every client segment. The steps are not complex, but mistakes are costly because a wrong delegation can make a whole domain unreachable from the corporate network. Teams without recent DNS change experience often use a short review of the plan, a rehearsal on a non-production zone, and a documented rollback. A partner can supply that review as part of a fixed-scope engagement.
When is it worth bringing in a partner for the delegation?
A partner is worth considering when the delegation is one step in a larger FreeIPA rollout, when several zones or sites must be delegated at once, when the corporate DNS platform is shared with other teams and change control is strict, or when the internal team lacks time to test from each client segment. A partner can also plan the repeatable procedure for adding future FreeIPA DNS servers so that each addition does not need the same discovery work again. Ask for a written scope that lists the zones, servers, test cases and handover documents before work starts.
How do we test that resolution works after delegation?
Test from the authoritative side and from the client side. From the corporate resolver, query the parent zone for the NS records and check that they match the FreeIPA servers. Then query a host name in the delegated domain from several network segments and check that answers come back from the expected servers. Also confirm that each client's resolver configuration lists at least two DNS servers, as FreeIPA's deployment recommendations advise. Record the results so the corporate DNS owner can compare them after each later change.
What happens when we add another FreeIPA DNS server later?
You repeat the delegation: the new server needs an NS record in the parent zone, and clients and monitoring should be updated to match. The change follows the same approval path as the first delegation, so the cost of each addition depends on how fast that path runs. Ask whether the corporate DNS owner can approve a standing procedure for these changes, and confirm which team owns the monitoring checks that verify the NS records after each change.
How DeployOpen scopes and delivers DNS delegation for FreeIPA
DeployOpen approaches delegating a DNS subdomain to FreeIPA as a planned change to the corporate DNS, not a one-line record edit. We agree the subdomain, name servers and test cases in writing, build the delegation with your DNS team, and hand over the records and tests that keep it working. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- Confirm the subdomain, parent zone owner and which FreeIPA servers will answer for it before any change request is raised.
- Inventory every FreeIPA DNS server and the NS records that must exist in the parent zone for each one.
- Agree in writing which parent zone changes, resolver settings and test cases are in scope and who approves each change.
How we build
- Prepare the NS and glue record changes for the parent zone and review them with your DNS administrators before publication.
- Test resolution of the delegated subdomain from clients, from the FreeIPA servers and from the corporate resolvers.
- Check that the first FreeIPA server still answers SOA and NS queries for the delegated zone after each record change.
How we hand over
- Document the delegation record set, the owner of each record and the steps to add a repeated delegation for a new FreeIPA DNS server.
- Provide a resolution test script that your team can rerun after parent zone changes or server replacements.
- Walk your operations team through the runbook so the delegation can be changed without the original engagement team.
How we support
- Offer retainer support for NS record changes, new FreeIPA DNS servers and repeated resolution testing after upgrades.
- Re-run the delegation tests when topology changes, such as adding or retiring a replica that runs DNS.
- Confirm with your parent zone provider how record changes are submitted and how long they take to publish before planning a change window.
