When FreeIPA DNS zone transfers to external servers are needed
Zone transfers are needed when an organization must serve its FreeIPA DNS zones from name servers outside FreeIPA, such as existing secondary servers, a corporate DNS platform or a provider that the security or network team already operates. A zone transfer is the mechanism by which one authoritative server copies zone data to another. Without it, the external servers have no current copy of the zone and cannot answer for it reliably. The decision starts with an inventory: which name servers already answer for your domains, who operates them, and whether they are contractually or procedurally required to hold copies of every zone.
Transfers are disabled by default, so sharing a zone is a deliberate change that must be designed, not a side effect of installation. The two transfer types work differently. AXFR copies a full zone in one exchange, which is simple but heavier for large zones. IXFR copies only the changes since a previous version, which reduces traffic but depends on both sides tracking zone versions correctly. Your choice between them, and the access controls that decide which secondary servers may request transfers at all, should follow from how the external servers are configured and how often your zones change. Confirm the transfer and access-control settings, and the exact names of the options that enable them, against the FreeIPA DNS documentation for your release before you write any change plan.
Plan this decision before you choose how DNS is integrated, because it affects who owns the zone data. If the external servers will be the only place where some records are edited, you have an external DNS team to coordinate with, and that team must know which zone changes originate in FreeIPA. Ask the external operator which transfer type they support, which source address they will connect from, and how they will be notified of changes. Then record the answers as the acceptance criteria for the topic's configuration steps.
Transfer options and when each fits
This table compares four ways to share FreeIPA zones with external secondaries: no transfers, full transfers, incremental transfers and restricted transfer lists. Read each row as a trade-off between operational simplicity, bandwidth, source control and audit evidence. Confirm the exact configuration keys in the FreeIPA version you run before you write any change.
| Option | What it means | Main trade-off | When it fits |
|---|---|---|---|
| Transfers disabled | Secondaries get zone data by another route, such as a manual export or a separate sync process | Keeps the zone source single and simple, but the external team depends on a process you must document and test | Small zone sets, or when the external team cannot accept any zone transfer from IdM |
| Full transfers (AXFR) only | The secondary requests the complete zone each time it refreshes | Simple to reason about, but every refresh copies the whole zone, which costs more as zones grow | Small or slowly changing zones, and secondaries that do not support incremental transfers |
| Incremental transfers (IXFR) | The secondary requests only changes since its last known SOA serial, falling back to a full transfer when needed | Less data moved per refresh, but both sides must support IXFR and the serial history must stay consistent | Larger or frequently changing zones, where the secondary software is confirmed to support IXFR |
| Restricted allow-transfer lists | Transfers are limited to named addresses or to a shared TSIG key | Narrows who can pull zone data, but lists drift as addresses change and keys need rotation | Any case where transfers are enabled, so that only approved secondaries can request zone data |
| Single transfer source | All secondaries pull from one IdM server, not from each replica | Avoids conflicting SOA serials between servers, but creates a dependency on that server being available | Most deployments with more than one IdM DNS server, so the secondaries see one consistent serial |
| Audit evidence | Logs and records showing which secondary pulled which zone, and when | Needs log retention and a named owner for the allow list, which the team must set up on purpose | Regulated environments where an assessor may ask who received zone data |
Why secondaries should follow one IdM server
Each zone should have one IdM server chosen as the transfer source for external secondaries. The reason is that FreeIPA DNS servers do not always hold the same SOA serial for a zone at the same moment. Dynamic updates from clients and replication from other IdM servers reach each server at a different time, so one server can be ahead of another for a short period. A secondary that pulls from one IdM server and then from another can see the serial go backward or forward, and two secondaries can disagree about which version of the zone is current. Serial disagreement is easy to miss in a lab, but it surfaces in production as records that resolve on some secondaries and not others.
Pinning transfers to one source keeps the serial sequence the secondaries see consistent. In practice, decide which IdM server is the transfer source for each zone, record that choice in your DNS runbook, and set the allow-transfer and secondary configuration to match. Confirm in your own environment how the zone's SOA serial moves across your IdM servers before you rely on it, and confirm the transfer behavior of the secondary software you plan to use, since AXFR and IXFR handling differs between products. Choose the source server with the same care you give server roles, and review the server layout against the FreeIPA deployment recommendations so the chosen server is not overloaded or placed where its network path to the secondaries is weak.
Plan the fallback before the first outage. If the chosen source is down, secondaries still need a path to a current copy, so decide in advance which other IdM server takes over, who changes the secondary configuration, and how you will confirm the secondaries have resumed following the expected serial. Test the switch in a non-production environment, and make sure the runbook names the people who can approve it outside office hours. A fallback that exists only on paper is the same as no fallback when the primary fails at night.
Set up transfers to an external secondary
This sequence turns a list of FreeIPA zones into a tested, audited zone transfer from one IdM source server to a named external secondary, with transfers closed to everyone else. It is written for the team that owns the FreeIPA DNS and the team that runs the external name servers.
Confirm zones and secondary software support
The FreeIPA administrator lists every zone that must leave IdM and checks which zones are primary zones held by IdM rather than forward zones. The DNS team confirms the external server software, its version, and whether it supports AXFR and IXFR, and whether it accepts TSIG keys for transfer authentication. Confirm these details with the vendor or project documentation for your exact version, not from memory. Done means a written list of zones, the secondary software and version, and a yes or no for each transfer type.
Choose the single IdM source server
Pick one IdM server as the only source for transfers. Secondaries must pull from this server because the SOA serial numbers on different IdM DNS servers can differ, so a secondary that alternates between servers may see serials move backward or stall. Record the server's hostname and the IP address the secondary will connect to. Check with a query such as dig against that server for the SOA record of each zone and note the serial values. Done means one named source and a baseline serial per zone.
Decide transfer types and access restrictions
Decide whether the secondary needs full transfers only (AXFR), incremental transfers (IXFR), or both, based on what the secondary software supports and how often the zones change. Decide which addresses and any shared keys will be allowed, and whether the connection will be restricted by network path as well as by key. Agree the change window and the owner who approves it. Confirm the approach against the FreeIPA DNS documentation for your release, because the exact configuration options depend on the version. Done means a written decision record listing transfer types, allowed address, and key owner.
Allow transfers only to the named secondary
On the IdM source, the administrator enables zone transfer only for each approved zone and restricts it to the named secondary's address, so that no other host can request a transfer. Transfers are disabled by default, so this step is the deliberate opening of the zone. Apply the change through the supported FreeIPA DNS interface for the zone and avoid editing generated BIND files by hand, since they can be overwritten. Done means each zone shows the allow-transfer setting with exactly one permitted address, which the administrator confirms in the configuration output.
Configure the secondary to pull from the source
On the external secondary, the DNS team configures each zone as a secondary zone whose master is the single IdM source chosen earlier. Set the transfer type and key settings that match the decision record. Start the secondary and let it load the zones. Done means the secondary reports each zone as loaded, and its log shows a completed transfer from the named source address rather than from any other host.
Test transfers from allowed and denied addresses
From the approved secondary address, request a full transfer of each zone with dig using the AXFR option and confirm the zone data returns. From a second host that is not on the allow list, run the same request and confirm it is refused. Run the test from both hosts for every zone on the list. Done means the approved host receives records and the denied host receives a refusal, and both results are saved with timestamps.
Check serial match after a record change
Make a harmless test change in one zone on the IdM source, such as adding and then removing a test TXT record in a non-production zone. Read the SOA serial from the source, then wait for the secondary to refresh or trigger a notify where it is configured. Compare the secondary's SOA serial with the source value. Done means the serials match and the test record appears on the secondary, which confirms that updates flow from the one chosen source. If they do not match within the refresh interval, check the secondary's log before going further.
Record the change for audit
The FreeIPA administrator and the DNS team write one change record that names each zone, the source server, the secondary address, the transfer types, the key owner, the test results, and the serial comparison. Store it with the change ticket and the configuration output. Ask the team that handles audit evidence which format it needs, because the required evidence depends on your assessment. Done means the record is filed and linked to the zones it covers, so a later reviewer can see who opened transfers and why.
Security and operational risks of sharing zones
Sharing a FreeIPA zone with secondary servers moves data and dependencies outside the IdM servers you run day to day. The cards below pair each risk with the control and check that keeps the shared zone accurate, private and available.
Unrestricted transfers expose host names
A zone transfer hands over every record in the zone, including internal host names, service records and addresses that most networks never publish. Transfers are disabled by default in FreeIPA DNS, so the risk comes from enabling them without limits. Restrict allow-transfer to the exact addresses of approved secondaries, and confirm that no broader network range or unmanaged host can request the zone.
Source server health
Secondaries pull their copy from the source. If the source IdM server is down, overloaded or unable to answer transfer requests, every secondary keeps serving stale data until the problem clears. Monitor the source server's DNS service and its response to transfer requests, and treat the source as a service with its own health checks rather than an afterthought.
SOA serial drift between secondaries
Each DNS server keeps its own SOA serial, so serials from different IdM servers do not line up and a secondary can appear to be ahead or behind without a real content problem. Point every secondary at one IdM server as its transfer source, then compare the serial each secondary reports against that source on a schedule and alert when a secondary falls behind.
Transfer path and keys
A transfer can run over an unprotected network path, and some deployments add transaction keys to authenticate the requesting server. Whichever mechanism you choose, keep the path limited to the secondaries, store any key outside shared configuration files, and record who holds it. Confirm the exact options your FreeIPA and secondary DNS software support before you rely on them.
Source changes that break secondaries
Renaming or removing an IdM server changes the address and name that secondaries expect to transfer from. A secondary still configured for the old source stops updating while it looks healthy. Before any server change, update the secondary configuration and the transfer source in the same change window, then check that each secondary completes a transfer from the new source.
Reviewing allow-transfer changes
Changes to allow-transfer settings alter who can copy your zones, so they deserve the same review as firewall rule changes. Log every change with the person, the reason and the approval, and review the current list on a regular cadence against the list of approved secondaries. Remove entries for retired secondaries promptly so access does not outlive the systems it was granted to.
Who owns what in a shared DNS setup
The platform team owns the IdM servers that hold the authoritative zones and decides which server acts as the transfer source. Transfers are disabled by default in FreeIPA DNS, so this team must enable them deliberately, zone by zone. Because SOA serial numbers can differ between IdM servers, secondaries should be pointed at one chosen IdM server rather than at all of them.
- Transfer source choice: Pick one IdM server as the designated source for each zone and record why it was chosen and what happens if it is unavailable.
- Per-zone transfer settings: Set the allow-transfer list and transfer behavior for each zone, and keep the exact values in change records.
- Replication awareness: Document how zone changes made on one replica reach the transfer source, since restoring an outdated backup into an active topology can break replication.
- Backup and restore notes: Keep backup timing and restore runbooks that include DNS data so zone state can be recovered consistently.
- Evidence to keep: Configuration exports for each zone, the chosen source server, and dated change tickets.
Confirm the transfer settings and source server in your own environment before the external team configures anything.
The external DNS team owns the secondary name servers that receive copies of the FreeIPA zones and serves them to the rest of the network. This team decides how secondaries are configured, how often they are checked, and how changes are requested from the platform team. Its work depends on the source server staying stable, so it needs clear contacts and a documented change path.
- Secondary configuration: Configure each secondary to pull from the agreed IdM source and keep the configuration under version control.
- Serial monitoring: Track the SOA serial on each secondary against the source and alert when they diverge for longer than your agreed tolerance.
- Transfer testing: Confirm that full and incremental transfers complete after each change and record the results.
- Change requests: Define the form a zone change request takes, who approves it and how the platform team confirms the update.
- Evidence to keep: Secondary configuration files, serial monitoring logs, transfer test output and approved change requests.
Confirm with your DNS software documentation which transfer modes it supports and how it reports transfer failures.
The security team reviews who may request zone copies and what those copies reveal. A zone transfer returns every record in the zone, including internal host names, service records and infrastructure details, so the allow-transfer list is a disclosure control. This team also confirms that transfer activity is logged and that someone reviews those logs.
- Allow-transfer review: Approve each address or key allowed to transfer a zone, and remove entries when a secondary is retired.
- Exposure of internal names: Decide which zones may leave the internal network and whether any zone should stay private to FreeIPA.
- Logging and alerting: Require logs of transfer requests on the source and secondaries, and define who receives alerts for unexpected requests.
- Access path review: Confirm that transfer traffic uses only the ports and networks approved for it.
- Evidence to keep: Signed approvals for each allowed peer, log samples showing transfer activity, and periodic review records.
Confirm your logging retention and review cadence against your own policy before relying on this setup.
Limits to confirm in your environment
Zone transfers to external servers depend on the FreeIPA release you run, the secondary DNS product you choose, and how your DNSSEC and delegation setup behave. Confirm each item below with the FreeIPA documentation and the secondary vendor before you commit to a design, because none of them should be assumed.
Transfer types and settings in your release
Confirm which zone transfer types and options your FreeIPA release supports before you draw the design. Check the release notes and the DNS documentation for the version you run, not a newer one. Ask whether transfer settings can be applied per zone or only globally, and whether a change needs a service restart. Record the answers as part of the design baseline.
AXFR and IXFR support on the secondary
Confirm that the external secondary supports both AXFR and IXFR, and that it can apply the same key or address controls you set on the FreeIPA side. A secondary that accepts only full transfers will move more data on every change. Test a transfer from the secondary to a FreeIPA server in a lab zone before you rely on it.
DNSSEC and transfers in your release
Confirm how zone signing interacts with transfers in the release you run. Signed zones may change how serials, signatures and key material move to the secondary, and the secondary must validate what it receives. Check the DNSSEC documentation for your release and ask the secondary vendor how it handles signed zones before you decide where signing happens.
Notifying the external team of changes
Decide how the external DNS team learns about zone changes, such as record updates, new zones or key rollovers. Confirm whether FreeIPA sends notifications to the secondary automatically, or whether your process must trigger them. Agree who owns the change record, who receives alerts, and how a missed notification is detected.
Delegated subdomains and parent NS records
Check whether any zone you share is a delegated subdomain. A delegated zone needs matching NS records in the parent zone that the external team maintains, and those records must list the name servers that actually answer for the zone. Confirm the parent zone owner, the change process for NS records, and how you will test resolution after each new FreeIPA DNS server is added.
Questions buyers ask about FreeIPA zone transfers
What drives the cost of setting up zone transfers to external DNS servers?
The cost depends mostly on how much DNS work sits around the transfer itself. The main drivers are the number of zones to share, the number of external secondary servers, how those servers are already managed, and whether your change process and audit needs add documentation and review steps. A quote for a fixed scope should list each zone, each secondary, the transfer method, the access controls on each server, the test plan and the evidence you will receive. Ask whether the price covers only configuration or also testing, handover and runbooks. Recurring costs are usually limited to changes you request later, so ask how changes to zones or secondaries are scoped and priced after handover.
How long does it take to share FreeIPA zones with secondary servers?
Duration depends on the number of zones and secondaries, how many change windows your organization allows, how long the external DNS team takes to review and approve changes, and how much testing your environment requires. Transfers can be configured quickly on a lab system, but production work usually waits for approval cycles and a maintenance window. Ask for a timeline in the written scope that separates preparation, test runs, the production change and the post-change check. Confirm the dates your external DNS team can be available before the work starts.
What does our team need to provide before zone transfer work begins?
Most of the work depends on access and decisions from your side. You will need a named contact on the external DNS team who can approve the secondary server list, the allowed transfer clients and the change window. The engagement also requires access to the FreeIPA servers that host the zones, a test environment that mirrors production DNS as closely as possible, and written change approval from the owners of each zone. Confirm who can accept the secondary IP addresses, who owns the TSIG or access-control decisions, and who signs off on the final configuration.
Can our own team set up zone transfers to external DNS servers without a partner?
Yes, if your team has working knowledge of DNS zone transfers (AXFR and IXFR), FreeIPA DNS administration and a test environment where changes can be checked before production. The main risks for in-house work are secondaries that serve stale data because transfers point at the wrong server, and transfers that are open to anyone who can reach the port. Check whether your team understands why secondaries should point at one IdM server, since SOA serial numbers differ between IdM servers. A partner adds value when that knowledge is thin, when the change must be finished within a fixed window, or when you need documented evidence for an assessment.
Does DeployOpen issue an audit report or attestation for our DNS controls?
No. DeployOpen does not issue audit reports, attestations or certifications. DeployOpen prepares the systems, configuration and evidence that an independent auditor or certification body reviews, such as documented transfer settings, access restrictions on the allowed transfer clients and records of testing. Ask your auditor which evidence they expect for DNS zone transfers before the work starts so the scope includes it. The final assessment conclusion always comes from the independent assessor.
What should we check after transfers are enabled to confirm the secondaries are correct?
Check that each secondary holds the same serial number as the FreeIPA server it transfers from, that AXFR and IXFR requests succeed only from the addresses you approved, and that a test record change on the FreeIPA side reaches each secondary within the expected refresh interval. Confirm that requests from unapproved addresses are refused. Also check that the transfer settings still apply after a server restart and that the change is recorded in your configuration process. Ask the partner or your team to write these checks into a runbook so the same tests can be repeated after future changes.
How DeployOpen scopes and delivers FreeIPA DNS transfer work
DeployOpen plans and implements zone transfers from FreeIPA to external secondary DNS servers inside your own infrastructure. Engagements are fixed-scope, so the transfer design, allowed peers, record set and test plan are agreed in writing before any configuration changes are made.
How we scope
- Inventory every zone that must reach secondaries and confirm which IdM server holds the authoritative copy.
- Agree the list of secondary servers, their addresses and the allow-transfer rules that will restrict each zone.
- Confirm whether transfers use full AXFR, incremental IXFR, or both, and record the expected TSIG or access controls.
How we build
- Configure transfer settings on the chosen IdM server and point each secondary at that single source rather than at several peers.
- Test a full transfer and an incremental update for each zone, checking serial numbers and resolution from the secondary.
- Document the configuration, record ownership and the change steps your team must repeat when a zone or secondary is added.
How we hand over
- Provide a runbook covering transfer settings, the source server, monitoring of zone serials and recovery if a transfer fails.
- Walk your DNS and platform engineers through a live zone update so they can confirm the process end to end.
- Record which changes belong to the external DNS team and which stay with the FreeIPA administrators.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, covering transfer changes after go-live.
- Retest transfers after FreeIPA upgrades or topology changes, including any change to the server acting as transfer source.
- Quotes follow from the written scope, so ask for the transfer, testing and handover items to be listed separately.
