When FreeIPA DNS forwarders and forward zones are needed
Forwarders and forward zones let a FreeIPA DNS server answer questions it is not authoritative for by passing them to another resolver. In practice, a forward zone sends queries for one named domain, such as an Active Directory domain or a corporate zone, to specific upstream servers, while a global forwarder is used for queries that FreeIPA does not answer from its own zones. Both are settings inside the FreeIPA DNS service, so the decision is made when you design how the IdM servers resolve names, not in the clients. Your situation is common: the identity deployment must resolve hosts in corporate or Active Directory domains while its own zones stay authoritative for their names.
The supplied documentation for this page does not describe forwarding behavior in enough detail to state exact semantics, including how a forward-first policy differs from forward-only, how forward zones rank against global forwarders, or what happens when an upstream server is unreachable. Confirm these points against the FreeIPA release you run, using its DNS management documentation and command help, and test them on a non-production replica before you rely on them. Also check whether your release applies forwarding settings per server or across the topology, because that affects every replica you plan to add.
Before you change anything, write down which domains must be forwarded, which upstream servers answer for each, and which zones FreeIPA must keep authoritative. Confirm that no forwarded domain overlaps with the IdM DNS domain, since overlapping names are a common source of confusing resolution failures. Ask the corporate or Active Directory DNS team to confirm that the upstream servers accept queries from every IdM server and that they will keep those answers stable when the directory changes. Record the plan with the zone list, so the forwarding settings can be reviewed alongside the delegation and reverse zone decisions covered elsewhere on this page.
Global forwarders, per-domain forward zones and the two forwarding policies
This table compares global forwarders, per-domain forward zones, and the forward first and forward only policies, with the fit and main risk of each. Policy names and precedence depend on your installed FreeIPA and BIND versions, so confirm them with ipa dnsconfig-show and ipa dnsforwardzone-show before relying on any row. The main takeaway is that forward only gives tighter control, but a forwarder outage then affects every lookup it covers.
| Option | What it applies to | When it fits | Main risk |
|---|---|---|---|
| Global forwarders | Queries FreeIPA DNS cannot answer from its own zones, across the server | Isolated networks with one upstream resolver, or one corporate resolver for external names | Internal names sent upstream may fail or resolve wrongly if that resolver lacks the zones |
| Per-domain forward zone | Queries for one named domain, sent to the servers you list for that domain | Hybrid estates where a separate AD or corporate domain must be answered by its own DNS | Overlap with a domain FreeIPA also serves can shadow records, so confirm zone ownership first |
| Forward first policy | Forwarders are tried first; FreeIPA falls back to its own recursive lookup if they fail | Mixed environments where a forwarder outage should not stop external lookups | Fallback can bypass the corporate resolver and reach names you meant to keep internal |
| Forward only policy | Queries go only to the listed forwarders, with no recursive fallback | Networks where all external lookups must pass through a controlled resolver | A forwarder outage stops external name resolution, which can break installs and client lookups |
| Forward zone to AD DNS | Names in the AD domain, answered by Windows DNS servers | Hybrid estates running FreeIPA beside AD, with AD DNS authoritative for its own domain | Overlapping namespaces break resolution; the IPA domain must not overlap any AD forest domain |
| Forward zone to corporate DNS | Names in a corporate zone that FreeIPA does not own | Split ownership, where the corporate team manages records outside the IPA subdomain | Forwarding loops if corporate DNS sends the IPA zone back to FreeIPA; test both directions |
| Configuration precedence | Per-domain zone settings expected to override global forwarders for matching names | Designs that need one exception to a global forwarding setting | Unexpected routing when a zone and global setting disagree; document both and confirm in your version |
Forwarding to Active Directory, corporate DNS or both
Use this tab when the AD forest owns the zone you want to forward, for example a Windows domain that your Linux hosts must resolve during join, login and trust setup. The forward zone in IdM must point to the DNS servers that are authoritative for that AD domain, usually the domain controllers that run DNS. Forwarding to a random Windows server or a load balancer address is a common mistake, because only authoritative servers return the SRV records that clients depend on.
- Target servers: list the AD DNS servers that answer for the AD domain, not the ones that only hold a cached copy.
- AD side permissions: confirm that those DNS servers accept recursive or forwarded queries from the IdM server addresses and that no firewall rule blocks them.
- Naming constraint: the IPA DNS domain must not overlap any domain in the AD forest. If the IPA domain is a child or sibling of an AD domain, plan a rename before deployment, because the FreeIPA trust documentation states this restriction.
- Trust setup: if you also plan a cross-forest trust, the same naming rule applies, and the forwarding and trust design should be reviewed together.
- Confirm: which AD DNS servers answer for each zone, and whether their Windows DNS policies allow queries from your IdM servers.
Use this tab when the corporate DNS team runs the authoritative service for other internal zones, such as office networks, legacy subdomains or shared service names, and FreeIPA should forward those names rather than hold copies. Each forward zone maps one domain to a specific set of corporate resolvers. The IdM servers act as clients of those resolvers, so the corporate side must treat them like any other internal client, with the source addresses and query policy that implies.
- Target servers: name the corporate resolvers per zone, and record whether they are authoritative or recursive for that zone.
- Corporate side permissions: the corporate team must confirm that the IdM server addresses are allowed to query, and that responses are not restricted by views or access lists that hide internal names.
- Zone ownership: agree in writing which team creates and changes records in each zone, because IdM will not manage those records.
- Forward policy: decide whether a failed lookup should fall back to public resolution or stop, and set the forward policy on each zone to match.
- Confirm: which corporate DNS servers answer for each zone and whether they accept queries from every IdM server, including any replicas you add later.
Use this tab when the estate contains both an AD forest and a corporate DNS service, which is the common case in banks, public bodies and large enterprises. The design question is which forwarder answers for which zone, and what happens when a name falls outside every explicit forward zone. Set the global forwarders for general internet and unmatched queries, then add per-domain forward zones so that AD and corporate names each go to their owner. Keep the list of zones short, because every extra rule is a place where a stale address can linger.
- Zone map: write a table with each domain, its authoritative servers, the forward policy and the owning team.
- Overlap check: confirm that no AD domain or corporate zone matches the IPA domain or a parent of it, since overlap causes split resolution.
- Priority: test which rule wins for a name that matches both a global forwarder and a per-domain zone, and document the result.
- Redundancy: list at least two answering servers for each zone so that one outage does not break Kerberos or LDAP lookups.
- Confirm: with each team, which DNS servers answer for their zones and whether they accept queries from the IdM servers, then test from every IdM host before cutover.
Use this tab after the forward zones are defined and before clients depend on them. Testing should cover each forward zone from every IdM server, because a rule that works on the first server may fail on a replica that sits in another network segment. Record the exact query, the answering server and the response for each domain, so that the owning teams can reproduce any failure without waiting for a live incident.
- Per-zone queries: resolve a known A record, an SRV record and a negative answer for each forwarded domain from each IdM server.
- Failure behavior: stop one forwarder in a test window and check that the forward policy behaves as designed.
- Client path: resolve the same names from an enrolled Linux client, since clients use the resolver list in the same way.
- Change control: require a written request to both teams before any forwarder address changes.
- Confirm: that every owning team has signed off the test results and knows who to call when a forwarder address changes.
How configuration priority decides which forwarder answers
A forwarder rule can hide a zone that the IdM server should answer itself. When a query arrives at an IdM DNS server, the server has to decide whether it is authoritative for the name, whether a per-domain forward zone covers it, or whether the global forwarders should handle it. The exact precedence between a more specific forward zone, the global forwarders and the local authoritative zones is not something to assume from memory. Confirm it against the FreeIPA DNS documentation for your release and your own configuration before you rely on it. If a forwarder is placed for a domain that IdM is supposed to serve, queries for records in that zone can be sent upstream and return an answer the IdM server never sees, or return nothing at all. The failure is quiet: the IdM server looks healthy while clients get wrong results.
Test every rule from two vantage points, and test after every change. Run the same queries from an IdM server and from an enrolled client, because the two may use different resolver paths. Query the names you expect IdM to answer, such as the IdM host records and the _kerberos and _ldap SRV records in your realm's zone, and names you expect to be forwarded, such as a corporate or Active Directory domain. Record the answer, the flags and the server that replied for each query before you change anything. Then make one change at a time, such as adding a forward zone, changing the forward policy or removing a global forwarder, and repeat the same queries. A change that fixes one name can break another, so keep the test list in a file and rerun it each time. Treat any difference between the IdM server result and the client result as a finding to explain before moving on.
How to add a global forwarder and a forward zone safely
This sequence takes an IdM DNS deployment from a recorded baseline to a tested global forwarder or per-domain forward zone, with a rollback path and a check that every IdM DNS server holds the same setting.
Record the current DNS configuration on every server
The administrator who owns the FreeIPA deployment logs in to each IdM server that runs DNS and saves the current global DNS settings and the list of forward zones. Use the DNS configuration and forward zone show commands for the installed version, and confirm the exact command names with the help output on that version before you rely on them. Store the output with the change record. The step is done when you hold one saved baseline per DNS server, so any later difference between servers is visible and rollback has a known starting point.
Confirm target resolvers answer from the IdM network
From each IdM DNS server, the network team or administrator queries the proposed forwarder addresses directly for the names you need, such as an Active Directory domain or a corporate zone. Run the queries from the same network segment and with the same firewall path the IdM servers will use, not from a workstation. Confirm that the resolvers answer, that DNSSEC validation behaves as your corporate DNS expects, and that no firewall blocks UDP and TCP port 53. The step is done when every IdM server gets correct answers from every proposed forwarder.
Add the global forwarder or forward zone
For a server-wide fallback, the administrator adds the forwarder with the global DNS configuration command. For a single domain, the administrator creates a forward zone with the forward zone command and lists the resolver addresses for that domain only. Make the change on one IdM DNS server first, using the version-specific syntax confirmed in the previous step. Record the exact command lines in the change record. The step is done when the new entry appears in the output of the show command on the server where it was made.
Set forward first or forward only
The administrator chooses the forwarding policy for the new entry. Forward first sends the query to the listed resolvers and falls back to the IdM server's own recursion or authoritative data if the forwarders do not answer. Forward only sends the query to the forwarders and returns failure if they do not answer. Choose forward only when the forwarders are the sole legitimate source, and forward first when the IdM server must still resolve names if the forwarders fail. Confirm the chosen policy in the show output. The step is done when the recorded policy matches the decision in the change record.
Verify the setting on every IdM DNS server
The administrator repeats the show command on each other IdM DNS server and compares the forwarders, the policy and the forward zone list with the server where the change was made. Differences between servers mean the change was not replicated or was applied to only part of the topology, so the administrator resolves them before testing. Confirm the replication state with your standard topology checks for the version in use. The step is done when all DNS servers report the same forwarding configuration.
Test resolution from an IdM server and a client
From an IdM DNS server, the administrator runs lookups for a name inside the forwarded domain and for a name outside it, and checks that the forwarded name resolves through the expected resolver. Then, on a client enrolled in the IdM domain, the administrator runs the same lookups through the client's configured resolvers. Check that at least two DNS servers appear in the client's resolver configuration as your deployment requires. Stop the forwarder or block its path in a test window if your policy needs to see the forward only failure behavior. The step is done when the forwarded names resolve from both the server and the client as recorded in the test plan.
Keep a tested rollback ready
Before the change goes live, the administrator writes the reverse commands that remove the forwarder or forward zone and restores the baseline recorded in the first step. Apply the rollback on one server in a planned window, confirm that the entry disappears from the show output, and then reapply the change so the rollback path is proven. Keep the baseline output with the change record for later audits. The step is done when the rollback has been run once in a controlled way and the team can restore the earlier settings without guessing.
Security and operating a forwarding design over time
Forwarding decisions change who can resolve your internal names, so treat the forwarder list as a security control, not a convenience setting. Limit changes to the people who already administer FreeIPA DNS, and record every change to global forwarders and per-domain forward zones with the reason, the requester and the approver. Before adding any forwarder, confirm that the resolver is one your organization operates or contractually controls. A forward zone sends queries for that domain to the named server, so a resolver you do not control can see the names your teams look up, including internal service and host names. Ask the owner of each target resolver which networks can query it and how it logs queries.
Review the configuration on a fixed schedule and after every change to the corporate DNS or Active Directory. Compare the live settings against the change record, check that each forward zone still points at servers that answer for that domain, and remove forwarders that no longer have an owner. Keep a copy of the exported configuration with the change log so you can show what was in place on any given date. Plan one owner for the forwarding design so that a DNS team change elsewhere does not silently break logins.
A forwarder outage does not usually stop FreeIPA itself, but it does stop anything that depends on names outside the IPA domain. Client enrollment, Kerberos realm discovery for other domains, and logins for users from a trusted Active Directory forest can fail when their names cannot be resolved. The FreeIPA deployment recommendations advise at least two DNS servers in each client's resolv.conf, so a single resolver failure does not leave a client without name service. Confirm which servers each client actually uses, test name resolution for every forwarded domain from a representative client, and decide ahead of time which failures are tolerable for your organization.
What goes wrong with forwarders in mixed DNS estates
Forwarders and forward zones sit between FreeIPA, Active Directory and corporate DNS, so a mistake in one place shows up as a name resolving slowly, wrongly or not at all. The cards below cover the failure modes we see most often in mixed estates, each with the cause and a check you can run before and after a change.
Forward zone shadows a local zone
A forward zone for a domain that IdM also hosts locally sends queries for that domain to the forwarder instead of the local zone. Records you added in IdM then appear to be missing for clients. Check whether the domain exists as a primary zone in IdM and as a forward zone at the same time, and confirm which one answers with a direct query to each IdM server for a record you know exists.
Forwarder refuses IdM servers
The upstream resolver may only accept queries from approved networks, so queries from the IdM servers are silently dropped or refused. Resolution then depends on which server a client happens to reach. Query the forwarder directly from each IdM server's address, and confirm that the firewall rules allow DNS over UDP and TCP from every IdM host to every forwarder.
Forward first masks a missing record
With forward first, IdM falls back to the forwarder when its own zone has no answer, so a missing record in an IdM zone can still resolve through a different path. The problem stays hidden until the forwarder is removed or changes its answer. Test with forward only on a non-production zone to confirm that each name you rely on is served by IdM itself.
AD or corporate names resolve to the wrong address
A forwarder for an Active Directory or corporate domain can return an address that differs from the one IdM or the directory team expects, especially when split-horizon answers or stale records exist upstream. Clients then connect to the wrong host without any error. Compare answers for critical service names across the forwarder, the AD DNS servers and IdM, and record which source each client actually uses.
Forwarders unreachable after a network change
Forwarders often sit in a different subnet or behind a route that changes during a network migration, a firewall rule update or a cloud subnet change. Every query that falls through to them then times out, which slows logins and Kerberos lookups. Before a network change, list every forwarder address in the global and per-zone settings and test each one from every IdM server.
Inconsistent settings across IdM servers
Global forwarders and per-zone forwarders are set per deployment, but a server that was offline during a change or was installed later can keep older values. Clients then get different answers depending on the server they reach. Compare the forwarder settings and forward zones on every IdM server, and run the same test queries against each one after any change.
What do teams ask before forwarding FreeIPA DNS to outside resolvers?
Can our own team configure DNS forwarders in FreeIPA without a partner?
Yes, a team with Linux and DNS experience can usually add global forwarders and per-domain forward zones itself, because FreeIPA exposes them through its command line and web UI. The harder part is knowing which zones must go where, what the corporate DNS team will allow, and how each client resolves names during and after the change. Teams that lack a test plan or a change window often find that a forwarding mistake breaks sign-in or service discovery before it is noticed. A partner is useful when the change touches several AD domains or when the team wants the work documented and tested before it goes into production.
What makes forwarder work take longer or cost more?
Scope is the main driver. The effort rises with the number of forward zones, the number of Active Directory domains and forests that must resolve, the number of DNS servers involved, and how many client types must be tested. Coordination with the team that owns the corporate DNS is often the slowest step, because they may need to approve conditional forwarding, firewall rules and ownership of new records. Testing scope matters too: a short check of a few hostnames costs less than a full run across Linux clients, services and trusted domains. Ask any quote to list these drivers explicitly.
What do we need to provide before the work starts?
Plan to provide a named owner for the DNS platform and for the corporate or AD DNS servers, a zone inventory listing each domain that must be forwarded and the server that currently answers it, and agreed change windows. Test clients that represent each operating system and each network segment are also needed, along with access to the current resolver configuration. Written approval for firewall changes between FreeIPA servers and the target resolvers should be in place before the first change. Missing any of these items usually adds waiting time rather than technical effort.
Should we use forward first or forward only for a given zone?
Forward first tries the configured forwarders and falls back to FreeIPA's own recursive resolution if they do not answer, which can keep names resolving during a forwarder outage but may send queries to public or unexpected servers. Forward only sends queries solely to the listed forwarders and fails if they are unreachable, which suits internal namespaces such as Active Directory domains that only the corporate servers can answer. As a general pattern, internal zones usually fit forward only, while global forwarders for general internet names may fit forward first. Confirm the choice against the current FreeIPA forwarding documentation and your own failure tests before you commit.
How long does forwarder configuration take?
Duration depends on scope, so no reliable figure can be given without a written scope. The main variables are the number of zones, the number of AD domains and resolver owners involved, the time needed for approvals and firewall changes, and the depth of testing. Ask for a schedule that separates design, approval, change execution and verification, and that states which steps depend on other teams. Any timeline that does not list these dependencies should be questioned.
What does a fixed-scope DeployOpen engagement cover for forwarding?
Most DeployOpen engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before work begins. For forwarding, that scope typically needs to name the zones in the inventory, the forwarders and forward policy for each, the AD or corporate DNS dependencies, the test cases and the rollback approach. DeployOpen works inside the client's own infrastructure and documents the resulting configuration for the team that will run it. Ongoing support after the change is a separate retainer, and the written scope should say which items are included.
Can forwarding to Active Directory DNS break FreeIPA trust or clients?
It can, if the forwarding design ignores the rules that FreeIPA and AD place on naming. The IPA domain must use a DNS domain that does not overlap with any domain in the AD forest, so a forward zone should never try to claim a namespace that the IPA domain itself owns. Clients also rely on at least two DNS servers in their resolver configuration, so a forwarder that is the only path to AD names can become a single point of failure. Verify client name resolution for both IPA and AD hostnames before and after the change, and confirm the trust requirements against the FreeIPA Trusts documentation.
Limits to confirm in your environment before you forward
Forwarding looks simple until a query takes the wrong path. The cards below cover the points that decide whether a forwarder or forward zone behaves as designed, and each one names who in your organization or vendor chain should answer.
Forwarding semantics in your release
Confirm how your FreeIPA release applies forward first and forward only and how it ranks global forwarders against per-zone forward records. Ask the team that runs your IdM servers to test a query for a zone with a per-domain forwarder and a global one, then record which server answered. Read the documentation for the exact release you will deploy, not a summary from an older version. Owner: your IdM administrators.
Query types your resolvers must answer
Forwarded resolvers must return every record type your clients and services request, including SRV records used for Kerberos and LDAP discovery, plus PTR records for reverse zones and the TXT and CNAME records your applications publish. Ask the corporate DNS team to confirm support for each type with a test query from an IdM server, not from a workstation. A resolver that answers A queries but drops SRV lookups will break enrollment in ways that look like Kerberos failures. Owner: your corporate DNS team.
DNSSEC validation through external resolvers
Find out whether the forwarder validates DNSSEC and whether it returns responses that your IdM DNS servers can validate. A forwarder that strips signatures or returns SERVFAIL for signed zones can make names appear to vanish. Confirm this before you enable validation on the IdM side, and decide which resolver is authoritative for validation when a zone is both forwarded and signed. Owner: your DNS engineering team, with your security team reviewing the decision.
Naming overlap with Active Directory
If an Active Directory forest shares the namespace, the IPA domain must not overlap any AD domain, so a forward zone that points AD names to AD DNS can collide with IdM's own zone. Ask your Windows and Active Directory team to list every AD DNS domain, including child and tree domains, and confirm each one is either a forward zone or left out of the IdM domain. Owner: your Active Directory administrators.
Ownership of the forwarder targets
A forwarder is only as stable as the team that runs it. Confirm in writing who owns the forwarder addresses, how changes are announced, and whether the corporate DNS team will accept IdM servers as clients with a fixed source address. Ask how long a forwarder change takes to reach their change process, since a retired address will cause resolution failures on every IdM server that still points to it. Owner: your corporate DNS team and their change manager.
How DeployOpen scopes and delivers FreeIPA DNS forwarding
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, including FreeIPA DNS. For forwarders and forward zones, we start from your resolver topology, Active Directory or corporate DNS dependencies, and the lookups your clients must make, then deliver a written, fixed-scope configuration you can test and operate.
How we scope
- Inventory every domain that FreeIPA clients must resolve, including Active Directory and corporate DNS zones.
- Record which forwarders exist today, who owns them, and which lookups must stay internal.
- Agree in writing whether each forward zone uses forward first or forward only, with reasons.
How we build
- Configure global forwarders and per-domain forward zones in a lab copy that mirrors your production DNS layout.
- Test configuration priority so per-zone forwarders override global forwarders as your design expects.
- Verify resolution from enrolled clients, including SRV lookups for Kerberos and LDAP services in each domain.
How we hand over
- Deliver a forwarding inventory listing each zone, forwarder address, policy and the owning team.
- Provide test commands and expected answers so your team can repeat resolution checks after changes.
- Walk your operators through change steps for adding forwarders, retiring zones and rolling back a bad setting.
How we support
- Review forwarder changes against the written inventory before your team applies them in production.
- Offer ongoing support, upgrades and continuous testing for FreeIPA DNS as a retainer, if you want it.
- Confirm with your own DNS and AD owners which upstream servers, ports and failover behavior apply to your network.
