FreeIPA DNS locations for site-aware clients

How FreeIPA DNS locations keep clients on nearby servers

DNS locations let FreeIPA clients prefer the servers in their own site through location-aware SRV records. In a multi-site deployment, a branch or data center client that looks up FreeIPA services without any site awareness may pick a server across the WAN, so every Kerberos ticket request, LDAP lookup and certificate operation crosses the link. A location is a named grouping of FreeIPA servers, typically one per data center or branch, and each server is assigned to the location where it sits. FreeIPA then publishes SRV records for each location so that clients in that site are directed to the local servers first.

The practical effect is less cross-site authentication traffic and fewer logins that depend on a distant server being reachable. Assigning servers to locations is a design decision you make before clients are enrolled: each site should have at least two or three replicas, as the FreeIPA deployment recommendations describe, so a local location has real capacity behind it. Make a list of which servers belong to which site, and check that every client subnet maps to the right location. Clients that cannot reach their local servers still need a fallback to other sites, so test what happens when a local replica is down.

The exact record names, the ipa command syntax for creating locations and assigning servers, and the order in which clients fall back to other servers must be confirmed against the FreeIPA DNS documentation for the version you run. This page does not supply version-specific behavior, and the behavior of location-aware lookups has changed between releases. Before you rely on this design, ask your implementation partner to show the SRV records a test client receives from each site, and verify that a client in one site falls back correctly when its local servers are unavailable.

Which location design fits your sites

This table compares three ways to group FreeIPA servers into DNS locations: one location for the whole deployment, one per data center, and one per branch or office. Read each row as a trade-off between administration effort, failover behavior and cross-site traffic, then check the server count guidance before choosing.

Design choice	What it looks like	Trade-off	When to choose it
One location for everything	All FreeIPA servers share a single location, so clients have no site preference	Simplest to administer, but clients may authenticate across WAN links when a nearby server exists	Small deployments with one site or fast, reliable links between sites
One location per data center	Each data center has its own location with two to three replicas assigned	Clients prefer local servers and fail over to remote ones, with more location objects to maintain	Several data centers where local authentication and WAN reduction matter
Location per branch or office	Small offices get a location, often without a local replica or with a single nearby server	Fine-grained routing, but a branch with one server has little local failover and adds administration	Many branches with limited links, where you confirm local servers can carry the load
Servers per location	Recommendations point toward two to three replicas in each data center	Fewer servers reduce cost and upkeep, but a location with one server has no local redundancy	Plan at least two replicas per location where local failover is required, confirming against your sizing
Which servers join a location	Assign servers by physical site, carry CA, DNS and trust roles deliberately	Mixing sites in one location sends clients across links, while role placement affects failover	Assign each server to the site it serves, and check which roles each location depends on

How the site layout changes what locations must do

When most users sit in one data center and several offices connect over a WAN link, the server layout is usually simple. The main site carries the replicas, and offices reach them across the network. Locations help most at the offices, where clients would otherwise send every Kerberos and LDAP request across the link. At the main site, clients already sit beside a replica, so a location there adds configuration without reducing traffic.

Server roles: Run two to three replicas in the main data center, with DNS and CA roles on at least one of them if you use FreeIPA DNS.
Where locations help: An office with its own replica benefits from a location that points its clients to that server first.
Where they add little: Main-site clients usually resolve to a replica on the same subnet, so a location there changes little.
Offices without a server: A small office with no replica depends on the WAN path regardless of location. Decide whether a local replica is justified before you add a location for it.

Check which offices have a local replica, and confirm that each client's resolver lists at least two DNS servers, so a single failed server does not leave the office without name resolution.

How to assign servers to locations and verify the answers

This sequence creates FreeIPA locations, assigns each DNS-enabled server to its site, and confirms that clients in each site receive SRV answers pointing to their local servers. It ends with a login test per site so the design is proven before clients depend on it.

Confirm forward and reverse DNS for every server
The administrator checks each FreeIPA server from a client in its own site and from a server in another site. Each host name must resolve to the correct address forward, and the address must resolve back to the same host name. Run the lookups with the tools already in your standard build, and record the results in your change ticket. This step is complete when every server returns consistent forward and reverse answers from every site. Fix any mismatch before continuing, because location-aware SRV records depend on correct host names.
Create one location entry per site
The administrator creates a location entry for each physical or logical site, using a short, stable name that matches your naming standard. Location names become part of DNS record names, so changing them later means regenerating records and retesting clients. Confirm the names with the team that owns client configuration before creating them. This step is complete when the location list shows every planned site and no test or duplicate entries remain. Check the exact command and any naming limits in the documentation for your installed FreeIPA version.
Assign each DNS-enabled server to its location
The administrator sets the location on each server that runs the DNS role, so that the server's SRV records are published under its site. Servers without DNS are not assigned here through the same path, so confirm which roles each host carries before you start. Assign one server at a time and keep a record of each mapping. This step is complete when the server list shows the intended location for every DNS-enabled server and no server is left unassigned by mistake. Confirm the command syntax against the documentation for your release first.
Check the SRV answers each site receives
From a test client in each site, the engineer queries the Kerberos, LDAP and related SRV records that clients use to find the IPA domain. The answers should list the local site's servers first, with the other sites' servers present as fallbacks. Save the output from each site for comparison. This step is complete when every site's client receives the expected priority order. If a site returns servers from another location first, check the location assignment and the DNS zone contents on the server before changing the client.
Test client authentication against the local server
The engineer enrolls or selects a test client in each site and logs in with a test user while watching which server handles the request. The server logs and the client's SSSD and Kerberos logs should show the local replica answering. Run the test with and without the local server reachable, to confirm that clients fail over to another site. This step is complete when each site's test login is served locally and the failover case works as documented. Record the results in the change ticket for audit purposes.
Run the full sequence in a non-production copy first
Before any change touches production, the team repeats every step in a non-production copy of the deployment with the same server roles and site layout. Exact commands, record names and client settings must come from the documentation for the FreeIPA version you run, not from older examples. Ask your DeployOpen or internal engineers to confirm each command in the copy, then promote only the verified steps. This step is complete when the copy passes every check above and the production change plan lists the same checks in the same order.

Security and operations to plan with site-aware DNS

Location assignments and DNS answers only stay correct if the server layout, DNS roles and change history are managed together. The cards below cover the failure modes that show up after a server moves, is removed, or is reconfigured, and what to check before and after each change.

Stale answers after a server move

When a replica changes site, its SRV records and location membership must move with it, or clients in the old site keep receiving the server's address and cross-site traffic returns without any error. Check the location assignment for every server after a move, then query the _ldap._tcp SRV records from a client in each site and confirm the first answer is a server in that site. Repeat the check from a client that is not enrolled yet, since it will rely on DNS alone.

Location records left after decommissioning

Removing a server without removing its location membership and DNS records leaves dangling entries that clients may try first. Before retiring a server, confirm the remaining replicas in that location still cover the site, then clear the server's records and location assignment alongside the removal. Afterward, list the SRV answers for each location and confirm that no retired hostname appears.

DNS over TLS to IdM DNS servers

FreeIPA 4.13.0 introduced DNS over TLS between clients and IdM DNS servers, which encrypts lookups that previously travelled in clear text. Confirm which of your clients resolve through IdM servers, that those servers present a certificate your clients trust, and that firewalls allow the TLS port. Treat the feature as a change to test in one site first, since a client that cannot reach its DNS server over TLS may lose name resolution entirely.

Keeping DNS roles on dedicated servers

FreeIPA's deployment recommendations advise dedicated servers without other applications, and at least one replica per datacenter running DNS if DNS is used. Location-aware answers depend on those DNS servers being available, so sharing them with heavy workloads raises the chance that a site's lookups fail. Check each site for at least one dedicated DNS-capable replica, and confirm that every client's resolver configuration lists at least two DNS servers.

Auditing DNS and location changes

Location assignments, SRV-related settings and DNS records can change through the web UI, the command line or automation, and a silent change can move traffic between sites. Record who changed which location, server or record, and keep those changes in version-controlled automation where possible. Review the audit trail after each planned change and compare live SRV answers with the intended layout to detect drift.

What clients do when their local servers are down

A location only helps while the servers in it are healthy. When every FreeIPA server in a client's own location is unreachable, the client does not stay idle. SSSD and the Kerberos libraries work through the SRV records they can still resolve, so the next candidates are servers in other locations. Authentication then succeeds, but it crosses the WAN, and the latency and traffic you designed the locations to avoid come back. The failure is quiet: logins keep working, so nobody notices the traffic pattern until a link saturates or a remote site becomes slow for its own users.

Because the fallback path decides what happens during an outage, the team must confirm the order in which clients try servers before go-live. Check which location-specific SRV records each site publishes and what happens after the local ones fail, including whether clients fall through to records for other sites or to generic records that point anywhere in the topology. On the client side, review the SSSD settings that govern server discovery and failover for the id_provider and auth_provider domains, and the Kerberos krb5.conf settings that control KDC and kpasswd discovery. Record the timeouts your builds actually use, measured in your environment, rather than assuming the defaults in a sample file. Also confirm how DNS resolution behaves when local name servers are down, because a client that cannot resolve any SRV record cannot fail over at all.

Test the outage in a controlled window, not during an incident. Pick one non-production client group in a site, block its local FreeIPA servers at the network layer, and log in with a test account, then run kinit and an id lookup and watch which servers answer in the logs and on the network. Measure login time and confirm which WAN links carry the traffic. Repeat with a Kerberos-only test and with an SSH login if your clients use it. Ask the people who run the network and the remote sites to agree in advance to the window and the expected extra traffic. Keep the test results with the topology design, because the same fallback order governs what happens when a site is lost for real. Independent guidance on the server roles involved is in the FreeIPA deployment recommendations.

Limits to confirm before you rely on locations

DNS locations only help when the FreeIPA version, client software, resolver settings, network path and server topology all line up with the design. Check each of these in your own environment before you assign clients to a site or count on local authentication traffic staying local.

FreeIPA version and location behavior

Confirm that the FreeIPA server version you run supports the location behavior this design depends on, including location-aware SRV records and the way servers are assigned to locations. Read the release notes for the version you plan to deploy, and test location assignment on a non-production server before changing production clients. Do not assume a behavior from one release applies to every 4.x release you operate.

Client OS and SSSD priority handling

Each client distribution and its SSSD version decide how SRV record priority and weight are read when a client chooses a server. Test a client on each distribution and SSSD release in your fleet, and watch which server it actually contacts for Kerberos and LDAP lookups. Treat a mixed fleet as a mixed set of results until each combination is verified.

Resolver lists on every client

Each client's resolver configuration determines which DNS servers answer its location queries. Inventory the resolver settings on every host class, including servers that use static files, DHCP options or a different DNS service. A client that lists only a remote DNS server will not benefit from a local location, even when the local replica is healthy.

NAT, proxies and resolver paths

NAT devices, proxies and split-horizon DNS can change which resolver a client reaches or which address it sees for a server. Trace the actual query path from representative clients in each site, and confirm that the answer returned matches the intended location. Note any site where traffic passes through a shared egress point, because that path can hide the local preference you designed.

Topology and replication agreements

Location changes only work as intended when the replicas assigned to a location have healthy replication agreements to the rest of the topology. Review how many agreements each replica holds, confirm that a site still has a path to other sites when a local server fails, and retest after any server is added, removed or moved. Changes to server roles in one site can affect which servers clients are steered toward elsewhere.

Questions teams ask before they set up DNS locations

How much work does a site-aware DNS design take?

The effort depends mostly on how many sites you have, which servers you expect to run DNS, and how many client operating systems you need to test. Each site needs a location name, a set of servers assigned to it, and SRV records that point clients at those servers first. A deployment with two sites and one client OS is far smaller than one with many sites, several OS versions and clients that must fail over cleanly. Ask your implementation partner or your own engineers to break the work into design, record changes, client configuration and testing so each part can be estimated. Ask the FreeIPA documentation which DNS and location commands apply to your release before you count steps.

Can an in-house team set up DNS locations without a partner?

Yes, a team that already runs FreeIPA DNS and understands SSSD and resolver behavior can make the change itself. The work is mostly careful planning, DNS record review and testing on each client type. A partner is useful when the team has few FreeIPA administrators, when the site map is complicated, or when the change must be tested across many operating systems before production. Whichever route you choose, put the scope, deliverables and test steps in writing first. DeployOpen plans and implements these changes in infrastructure you control and works from a fixed, written scope.

What must our team provide before the work starts?

Your team needs to supply a site inventory, a placement list for FreeIPA servers, the resolver settings on each client group, and a test window. The inventory should list every site, its subnets and the servers and clients that sit there. The placement list shows which FreeIPA servers run DNS in each site, since locations only help when a nearby server actually runs DNS. Resolver settings matter because clients need at least two DNS servers in their resolver configuration, according to the FreeIPA deployment recommendations. A test window lets you change clients in a controlled group and roll back if authentication behaves unexpectedly.

How long does a DNS locations project take?

The timeline depends on the number of sites, how many servers need a location assigned, how many client types need testing and how quickly change approvals move in your organization. Do not accept a duration that is not tied to these inputs. Ask for the expected duration broken into design, DNS record changes, client rollout and testing, and ask what would extend each phase. If the project includes a new DNS server in a remote site, add the time needed to install and verify that server. Your partner or internal team should confirm any figure against your own environment and the release you run.

What should a quote for this work include?

A quote should list the written scope, deliverables, assumptions and the work each party carries out. Look for the site list and the number of servers covered, the DNS roles that change, the client operating systems in scope and the test cases you will run. It should also state what is one-time work, such as design and initial rollout, and what recurs, such as monitoring or retained support. Ask how changes will be documented and handed over, and what happens if a site or client group is added during the project. DeployOpen does not publish a price list, so a quote follows from the agreed scope.

Do DNS locations replace a topology redesign?

No, locations change how clients choose servers, but they do not change where your replicas sit or how they replicate. If your sites lack enough replicas, or if your replication agreements are poorly arranged, a location assignment will not fix that. Locations work best after the topology is sound, so review the number of replicas per datacenter and the agreements per replica first. The FreeIPA deployment recommendations advise two to three replicas in each datacenter and no more than four replication agreements per replica. Treat location work as a complement to topology design, and confirm the current guidance for your release with the documentation.

What breaks if a location is misconfigured?

The most common failure is clients resolving a server that is not reachable, which causes slow or failed logins until the resolver times out and tries another server. A location can also send clients to a DNS server that is out of date, so checks must confirm each assigned server answers correctly. Clients with stale resolver settings may ignore the change until they refresh their configuration. Before rollout, test name lookups from each site, confirm failover to a second server, and verify logins with a test account. Keep a documented rollback so you can restore previous SRV priorities quickly.

Does this design reduce cross-site authentication traffic?

It can, because clients that prefer a nearby FreeIPA server send Kerberos and LDAP requests across a local link instead of a wide area link. The reduction depends on how many clients sit in each site, whether each site has its own DNS and replica servers, and whether the location assignments match the real network layout. Measure traffic before and after the change so you can show the effect in your own network. Ask your team to confirm how your release handles location-aware SRV records and to test failover, since a site-aware design should still reach another site when local servers are down.

How DeployOpen scopes and delivers site-aware FreeIPA DNS

DeployOpen plans, implements, documents and supports FreeIPA in infrastructure you control, including the DNS locations, server assignments and client settings that let clients prefer nearby servers. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory every site, network segment and client group, and record which FreeIPA servers serve each one.
Agree which DNS locations to create, which servers belong to each, and the fallback order when a local server is down.
Confirm the client platforms, resolver setup and DNS forwarding that the location design must work with.

How we build

Create DNS locations and assign each FreeIPA server to its location, checking the server roles it holds at each site.
Verify location-aware SRV records and confirm that test clients resolve the expected local servers first.
Test failover by taking a local server out of service and checking that clients move to the next server without manual changes.

How we hand over

Deliver a written topology record listing locations, servers, DNS records, client configuration and the verification results.
Document the steps to add a server to a location, move a server between locations and retire a location.
Run a handover session with your platform and security teams so they can confirm the design and operate it independently.

How we support

Review location assignments after server additions, removals or renames, since these change the SRV records clients use.
Recheck location behavior after FreeIPA upgrades, using the release notes to identify changes that affect DNS or clients.
Ongoing support, upgrades and continuous testing are available as a retainer, with scope agreed in writing.