Why teams encrypt DNS inside FreeIPA with DNS over TLS
Identity teams that run FreeIPA often find that name lookups between Linux clients and their IdM DNS servers still travel in clear text, which exposes hostnames, service records and lookup patterns to anyone on the path. FreeIPA 4.13.0 added DNS over TLS between clients and IdM DNS servers, so the same servers that issue Kerberos tickets and host policy can now answer queries over an encrypted TLS session. The feature is set at installation with --dns-over-tls, and it is most relevant where the network between clients and DNS servers is shared with workloads you do not control, such as branch sites, leased segments or hosts that cross a zone boundary.
DNS over TLS protects the query and response in transit between a client and the IdM DNS server it is configured to use. It does not protect the zone data stored on that server, the security of the server host itself, or what happens after the query leaves the IdM DNS service. If the server forwards to an upstream resolver, the path from IdM to that resolver is a separate hop, which is why the --dot-forwarder option exists for an upstream DoT server. Teams should map every hop from client to authoritative answer and decide which ones carry encryption, instead of assuming the whole resolution path is protected. Confirm with your own network design which hops remain clear text after the change.
Teams usually need this when name resolution itself is a sensitive signal, for example in zero trust designs where each network segment must authenticate and encrypt its traffic, or in regulated environments where auditors ask how internal service discovery is protected. Before enabling it, check that every client and replica you plan to serve can reach the IdM DNS servers on the TLS port, and that you have a certificate plan for the DNS endpoint. Decide early whether a fallback to unencrypted DNS is acceptable during rollout, because the policy choice determines how clients behave when the encrypted path fails.
Which DoT install options fit which design
This table compares the four FreeIPA 4.13.0 DoT options, from enabling DoT at install time to choosing between an upstream DoT forwarder and certificate handling. Read each row as a decision: the design it fits and the operating commitment it creates for your team.
| Option | Fits this design | What the team commits to operate |
|---|---|---|
| --dns-over-tls at installation | New IdM deployments where clients should send DNS queries to IdM servers over TLS from the start | Plan client resolver settings, certificate lifecycle and TLS port reachability for every IdM DNS server before go-live |
| --dot-forwarder | Environments where IdM DNS forwards to an upstream resolver that itself accepts DoT | Own the upstream DoT endpoint, its availability and its trust chain, and confirm the forwarder address and port with that provider |
| --dns-over-tls-key and --dns-over-tls-cert | Organizations that require certificates issued by their own CA or a specific certificate chain for the DoT listener | Track key and certificate expiry, renewal and distribution to replicas, and confirm clients trust the issuing CA |
| --dns-policy (fallback) | Mixed estates where some clients or networks cannot yet use DoT and must still resolve names during rollout | Accept that a downgrade to unencrypted DNS can occur, and monitor which clients still fall back |
| --dns-policy (strict) | Zero trust designs where unencrypted name resolution is not acceptable on enrolled hosts | Confirm every client and network path supports DoT before enforcing, since failed TLS sessions will block resolution |
| Combined install with forwarder and certificates | Full DoT design: encrypted client-to-IdM traffic plus encrypted upstream queries under organization-controlled certificates | Operate two encrypted hops, each with its own certificate and endpoint, and test both during change windows |
Choosing certificates and upstream DoT forwarders
The certificate choices for DoT determine who trusts the IdM DNS servers and how often someone must touch them. The 4.13 install options include --dns-over-tls-key and --dns-over-tls-cert for supplying the key and certificate that the DNS server presents to clients, and --dot-forwarder for pointing IdM at an upstream DoT server. Decide early whether the server certificate comes from the IdM CA, from your enterprise CA, or from a public CA, because each choice sets the trust store that every enrolled client must already hold. Confirm the exact file formats, key types and chain expectations for these options in the FreeIPA 4.13.0 release notes and in the 4.13 install documentation, then check them against your own CA policy rather than assuming a default.
Renewal is the operational cost that is easy to miss. A certificate supplied at install time is not renewed by the same automation that manages IdM's internal CA certificates, so the team must name an owner, a renewal date and a reload procedure before go-live. Test the full chain from a client that has only the trust store it will really use, because a missing intermediate often passes on the server and fails on clients. Record the expiry date in your monitoring system and rehearse replacement once in a non-production environment.
The upstream DoT provider adds a second trust relationship. Confirm the provider's certificate chain, the hostname it presents, and whether that hostname must match the name IdM uses when it connects. A forwarder that works by IP address but fails certificate name checks will produce intermittent resolution errors that look like DNS outages. Ask the provider for its supported TLS versions, its certificate renewal process, and its service levels in writing, and treat any forwarder you cannot verify as a dependency to be tested rather than trusted. The policy choice between strict and fallback behavior, covered in the sibling section on DNS policy, should be tested against each forwarder you select.
Strict or fallback DNS policy: how to decide
A fallback policy lets DNS queries continue over unencrypted DNS when the DoT path is unavailable. Resolution keeps working during a certificate problem, a network change or an upstream outage, but the query stream can be read or altered by anyone on the path during that window. The policy is set with the --dns-policy option at installation, using the fallback value supported by the FreeIPA 4.13.0 release notes.
- Failure mode: When the TLS session to the DoT server cannot be established, clients and the IdM DNS service revert to plain DNS without stopping lookups.
- Effect on clients: Hostnames still resolve, so logins, Kerberos service discovery and application traffic continue, and a broken encrypted path is less likely to be noticed by users.
- Security gap: During fallback, queries are visible to network observers, so this mode does not meet a zero trust requirement that all name resolution be protected.
- Signals to watch: Failed TLS handshakes to the forwarder, DNS query logs that show unencrypted traffic from clients, and certificate expiry warnings for the DoT key pair.
- Monitoring gap: Fallback can hide the fault, so set alerts on DoT connection errors rather than on resolution failures alone.
Before choosing this mode, confirm with your security team whether a documented exception is required for unencrypted fallback.
A strict policy requires encrypted DNS between clients and IdM DNS servers, and between those servers and the upstream DoT forwarder given by --dot-forwarder. The policy is set with the strict value of --dns-policy in the FreeIPA 4.13.0 release notes. When the encrypted path fails, queries fail instead of going out in plain text, so the failure is visible and the encryption requirement holds.
- Failure mode: When the TLS session cannot be established or the server certificate is not accepted, lookups fail for the affected clients.
- Effect on clients: Name resolution stops for hosts that depend on the failed path, which can break logins, Kerberos service discovery and service calls until the path is restored.
- Dependency risk: Every DoT path becomes a service that must be available, so a single forwarder with no alternative is a common cause of outages.
- Signals to watch: Resolution errors on enrolled hosts, certificate validity dates for the DoT server and key files, and DoT connection failures reported by the IdM DNS service.
- Recovery planning: Document how to switch the policy back to fallback in an emergency, who may authorize it and how the change is reverted afterward.
Ask your platform team to test the failure path in a non-production environment before you enforce the policy.
The choice depends on whether your risk model requires every query to be encrypted at all times, and on how much your resolution path can tolerate a fault. Many teams start with fallback during rollout to find configuration gaps, then move to strict once the forwarders, certificates and client resolver settings have been tested under failure. The decision should be written down with the owner of DNS, the owner of security controls and the owner of the business services that depend on name resolution.
- Start with the requirement: If an external policy or internal standard demands encryption for all name resolution, strict enforcement is the only option that meets it.
- Check redundancy first: Confirm that clients have at least two DNS servers in their resolver configuration, as the FreeIPA deployment recommendations advise, so one failed server does not stop lookups.
- Test the fault: Simulate an expired certificate or an unreachable forwarder and record which services stop and how long recovery takes.
- Plan the transition: Decide whether fallback is a temporary rollout state or a permanent exception with a review date.
- Record the decision: Keep the chosen policy, the reason, the approver and the rollback steps in your change records.
Confirm the policy value and behavior against the FreeIPA 4.13.0 release notes for your exact release before you write it into a runbook.
How to enable DNS over TLS on a FreeIPA 4.13 server
This sequence takes an IdM DNS server from a version check through certificate planning, DoT enablement, upstream forwarding and DNS policy, ending with a test query that proves clients reach it over an encrypted connection.
Confirm the server runs FreeIPA 4.13 or later
The administrator on the IdM server checks the installed FreeIPA version with the package manager and the ipa command-line tool. DNS over TLS between clients and IdM DNS servers was introduced in FreeIPA 4.13.0, so older servers cannot use this path. Confirm the exact package versions your distribution ships and whether your server is on the same version as its replicas. Done when the version reported on this server is 4.13 or later and every DNS-enabled replica that clients might reach is on the same release.
Plan the DoT certificate and private key
Decide which certificate and key the DoT listener will present to clients, and who issues it. Read the 4.13.0 release notes for the options that accept a key and certificate file, and confirm the expected file formats and ownership with your team's security standards. Check that the certificate name matches the hostname clients will use to reach the DNS server, and that the key is readable only by the service account. Done when you have written down the certificate source, the subject name and the file locations for both key and certificate.
Enable DoT during server installation or through the documented path
For a new server, add the DNS over TLS option to the installation command together with the certificate and key options named in the 4.13.0 release notes. For an existing server, confirm in the release notes and your environment whether the same settings can be applied afterward and what the procedure requires. Run the command in a maintenance window on a lab replica first. Done when the installer or configuration tool finishes without errors and the DNS service restarts with the DoT listener configured.
Configure the upstream DoT forwarder
If this server forwards queries it cannot answer, point it at an upstream resolver that supports DNS over TLS using the forwarder option described in the 4.13.0 release notes. Confirm with your resolver operator the hostname, the TLS port and the certificate chain they present, and make sure the IdM server trusts that chain. Keep the list of forwarders short and documented. Done when the server resolves a name outside its zones through the upstream, and the query path is confirmed as encrypted in the next verification step.
Set the DNS policy to strict or fallback
Choose the DNS policy that controls what happens when an encrypted upstream is unavailable. The 4.13.0 release notes describe a setting that allows fallback to unencrypted DNS or enforces strict DoT. Strict mode fails queries rather than sending them in clear text, which suits a zero trust design but raises availability risk, while fallback keeps resolution working during upstream outages. Record the choice, the owner who accepts the trade-off and the monitoring you will use. Done when the policy is set and the value reported by the configuration matches your decision.
Restart services and check the DoT listener
Restart or reload the DNS services as the release notes and your environment require, then confirm the listener is active. Check the service status, the logs for certificate or forwarder errors, and that the TLS port accepts connections from a client subnet. Also confirm the other replicas and client resolver configurations still list at least two DNS servers, as the deployment recommendations advise. Done when the service reports healthy, the logs show no TLS errors and the port answers a handshake from a test host.
Verify with a DoT-capable test query from a client
From a Linux client enrolled in IdM, run a name lookup against the DoT-enabled server using a DNS tool that supports DNS over TLS, and confirm the query succeeds over the encrypted port. Then query a name outside the IdM zones to test the forwarder and the policy, and run a lookup that should fail under strict mode when the upstream is blocked in a test environment. Capture the results and store them with the change record. Done when internal and external names resolve as designed, the encrypted transport is confirmed in the tool output and the failure behavior matches the policy you chose.
Security and operational considerations
Encrypting DNS changes what can break at login and service discovery, so the design has to cover certificates, keys, resolver settings and monitoring together. The cards below cover the decisions and checks that connect those areas for an IdM DNS deployment.
Certificate lifecycle and renewal
The DoT listener presents a certificate supplied through --dns-over-tls-cert and --dns-over-tls-key at install. Record the issuer, subject names that clients will validate, and expiry date for each DNS server. Confirm with your team how renewal will happen before go-live, because an expired listener certificate under a strict policy stops encrypted resolution on every affected server.
Private key protection
The DoT private key sits on the DNS server's disk and is readable by the services that need it, so file ownership, permissions and backup handling matter. Confirm where the key is stored on each replica, who can read it, and whether backups of the server capture it. Treat the key as a credential with the same handling rules as other service keys in your environment.
Client resolver configuration
Clients still depend on resolv.conf to find DNS servers, and FreeIPA recommends at least two DNS servers in each client's configuration. Check that every listed server has DoT enabled, because a client that reaches a non-DoT server under a strict policy will fail lookups. Review resolver settings after any change to server roles or addresses.
Replica coverage across sites
DoT is only available on servers where it was enabled, so a site with no DoT-enabled DNS server may have no encrypted path at all. Plan at least one DNS-enabled replica per datacenter, as the deployment recommendations advise for PKI or DNS roles, and confirm which replicas are configured for DoT. Test name resolution from each site after adding or removing servers.
DoT listener health monitoring
A listener can be running while the certificate is invalid or the port is blocked by a host firewall, and clients may only report a generic lookup failure. Add checks that open a TLS session to the DoT port on each server, verify the certificate chain and expiry, and alert before expiry. Run the same checks against upstream DoT forwarders if you use them.
Effect of a strict policy outage
Under a strict DoT policy, a server or certificate failure blocks name resolution rather than falling back to unencrypted DNS, which can stop logins, Kerberos host lookups and service discovery at the same time. Decide with your security and operations teams whether strict or fallback suits each zone, and document the recovery steps. Test a failure in a non-production environment before the policy is enforced.
How DNS over TLS fits a zero trust network design
DNS over TLS protects the name resolution path between clients and IdM DNS servers from passive observation and in-transit tampering. In a zero trust design, every network path is treated as hostile, and name lookups are one of the few signals an observer on the local network can read freely. Enabling --dns-over-tls at installation, and pointing upstream queries at a DoT server with --dot-forwarder, encrypts those lookups on the segments you choose to cover. That reduces what a passive observer learns about which hosts resolve which services, and it makes forged answers harder to inject on the path. The documented capability covers the query channel only. It does not change which hosts are allowed to reach a service, and it does not prove that the answer came from the right server.
Several controls still carry the zero trust argument, and DoT does not replace them. Kerberos and certificate-based identity still decide who a client is, so a correctly resolved name is not a reason to trust the host behind it. Host-based access control, sudo rules and network segmentation still decide what a resolved host may do. Confirm with your own architecture team which network paths DoT actually covers, because queries that leave through a forwarder you do not control, or traffic that bypasses the IdM resolvers, fall outside the design. Also confirm which clients in your estate can use encrypted resolution, since that depends on their resolver configuration and the FreeIPA release they run.
The practical decision is whether DoT is one layer in a broader design or a substitute for the others. Review the --dns-policy choice against your risk tolerance: a fallback policy keeps resolution working when encrypted paths fail, which protects availability but allows unencrypted lookups, while a strict policy protects confidentiality and makes DNS outages more visible. Document both the policy and the trust anchor for each DoT server, and test the failure behavior before go-live. Treat the release notes and your own configuration tests as the authority on exact behavior, and keep identity, segmentation and policy enforcement in the design as separate, verified controls.
Limits to confirm in your environment
DNS over TLS changes how every client resolves names, so the design holds only where the client, resolver and certificate paths all behave as planned. The cards below list the checks to run against your own distributions, network and upstream provider before you choose strict or fallback policy.
Client DoT support per distribution
Ask whether the resolver stack on each enrolled Linux distribution, including SSSD and any local caching resolver, can send queries over TLS to the IdM DNS servers. Confirm this on every release in your fleet, not only the current one. A client that cannot speak DoT under a strict policy will fail name resolution, so test login, sudo, Kerberos and package updates on each image before enabling the policy broadly.
Non-IdM clients and bypassed resolvers
Ask which hosts will never receive the configured resolvers, such as appliances, containers with their own resolv.conf, or machines pointed at a public resolver by a DHCP option. These clients keep querying in plain text and sit outside the encryption boundary. Decide whether to block outbound port 53 at the network edge, and document which systems remain unencrypted by design.
DNSSEC and external DNS interaction
Ask how encrypted transport interacts with your DNSSEC validation and with any zones hosted outside IdM. Confirm which resolver validates signatures, whether DoT changes the answers your clients receive for externally delegated names, and how split-horizon records resolve from inside and outside the network. Write these answers into the design before the DNS policy is set.
Upgrade behavior from earlier 4.x releases
Ask what changes on servers that started on releases before 4.13 when they are upgraded, and whether DoT options can be added to an existing DNS deployment or only applied at installation. Check the upgrade notes for each step in your path, and plan a test replica upgrade first. Keep a current backup, since restoring an outdated backup into an active topology can break replication.
Upstream DoT provider requirements
Ask whether the upstream DoT forwarder meets your data handling, availability and certificate requirements. Confirm its hostname and certificate chain, how it behaves under failure, which query logs it keeps, and where it runs. Your IdM servers depend on it for every external lookup, so a single provider needs a documented failover plan.
Questions buyers ask before enabling DNS over TLS
What does DNS over TLS cost to enable on FreeIPA?
No fixed price applies, because the cost follows from the written scope. The main components are the time to design the DNS path, prepare certificates, change server and client configuration, and test every client group. Installing with the DoT options is only one step. Costs rise with the number of IdM DNS servers, the number of client types, any upstream DoT forwarders you must integrate, and how much fallback testing you require. Ask for a quote that lists each component separately, states what is one-time (design, build, test) and what recurs (certificate renewal, upgrades, monitoring), and names who performs each task.
How long does a DNS over TLS rollout take?
The timeline depends on how much of the DNS path is already understood and how many systems must change. Teams with a single IdM DNS server, a known upstream resolver and an inventory of clients usually finish faster than teams with several datacenters, external resolvers and mixed Linux distributions. Plan time for certificate issuance and trust distribution, a pilot on a non-production replica, a strict-policy test where clients fail if the encrypted path breaks, and a rollback plan. No duration is given here because none is supported by a researched source. Ask for a schedule tied to milestones in the written scope.
What must our team provide before the work starts?
Expect to supply the TLS material and the network facts. That means the certificate and private key that the DNS service will use (passed with the --dns-over-tls-cert and --dns-over-tls-key options), the trust chain clients need, and the name and address of any upstream DoT forwarder with its certificate details (--dot-forwarder). You should also provide a list of client operating systems and SSSD versions, a firewall policy that allows TCP 853 where needed, and a set of test clients in each network segment. Confirm with your PKI owner whether the certificate comes from the FreeIPA CA or an external authority, because that changes how clients obtain trust.
Can our internal team enable DNS over TLS without a partner?
Yes, if your team already runs FreeIPA DNS and can read the release notes for the installed version. The install options are documented in the FreeIPA 4.13.0 release notes, and the work is a configuration change plus testing. The risk sits in the details: certificate lifetimes, the difference between the strict and fallback DNS policies, client behavior during failure, and the effect on resolver lists. A partner adds value when the team lacks time, when many clients need validation, or when the change must be documented for an assessor. Compare the internal effort with a fixed-scope engagement that includes testing and handover.
What changes when FreeIPA runs across several sites?
Multi-site layouts add decisions about where the DoT-enabled DNS servers sit and which clients reach them. Each site should have at least one DNS-capable replica, and the deployment recommendations advise at least two DNS servers in each client's resolv.conf, so the encrypted path needs to exist in every site, not only the primary one. Certificates must be valid for every server name clients will use. Upstream forwarders may differ by location. Test failover between sites while the strict policy is active, because a site that loses its encrypted path may stop resolving names unless fallback is planned deliberately.
What breaks if the encrypted DNS path fails?
With the strict DNS policy, clients that cannot complete a DoT session cannot resolve names through that path, so logins, SSH sessions and service discovery can fail. The fallback policy keeps resolution working by allowing unencrypted queries, which protects availability but weakens the encryption guarantee for those queries. Decide which policy each network zone needs before rollout, and monitor certificate expiry, forwarder reachability and TCP 853 connectivity. Test failure cases on purpose, including an expired certificate and an unreachable forwarder, so the team knows the exact behavior before production.
How does DNS over TLS support a zero trust network design?
DNS over TLS protects the query path between clients and IdM DNS servers from observers on the network, which is one control among several in a zero trust design. It does not authenticate users, authorize access or replace host-based policy. Pair it with strong client identity through SSSD and Kerberos, access rules through host-based access control, and monitoring of DNS logs. Do not describe the change as a compliance outcome on its own. Independent auditors decide whether the controls meet a given requirement, and DeployOpen prepares the systems and evidence for that review.
What a DeployOpen DoT engagement covers
A fixed-scope DNS over TLS engagement for FreeIPA would normally start with a written design covering which IdM DNS servers will accept encrypted queries, which clients will use them, and whether the upstream forwarders you rely on offer DoT at all. The design fixes the installation choices before any server changes: whether --dns-over-tls is set at installation or the feature is added to an existing IdM DNS server, which upstream server is passed through --dot-forwarder, and whether --dns-policy is set to strict enforcement or to fallback. Deliverables typically include that design document, the configuration changes on each DNS server, and a runbook for the operations team. Confirm in the statement of work exactly which of these servers and client groups are in scope, since replicas, hidden replicas and non-IdM resolvers each need a different treatment.
Certificate handling is usually the largest piece of work. The engagement should state who issues the server certificate and key used with --dns-over-tls-cert and --dns-over-tls-key, how the certificate chain is trusted by clients, how renewal will be scheduled, and where the private key is stored and who can read it. DeployOpen can prepare these inputs, configure the servers, and document the renewal procedure, but it does not issue audit reports, attestations or certifications. If your assessor expects evidence of a control, DeployOpen can supply configuration records, test results and procedures for that assessor to review. Ask the provider to name the evidence it will hand over and in what format.
The client typically provides access to the IdM servers and the target clients, change windows, the list of upstream resolvers and their DoT endpoints, a test plan owner, and staff who will run the system after handover. Verification should show that encrypted queries succeed, that strict policy fails closed when the DoT path is unavailable, and that fallback behaves as documented. Ask for test cases, rollback steps and the acceptance criteria in writing before work begins, and confirm with your IdM vendor or the release notes which behaviors apply to your installed version.
How DeployOpen scopes, delivers and supports FreeIPA DNS encryption
DeployOpen plans, implements, hardens, documents and supports FreeIPA inside your own infrastructure, including the DNS over TLS settings for IdM DNS servers. Each engagement starts from a written scope that sets which clients, servers and upstream resolvers are covered before any change is made.
How we scope
- Inventory which clients, IdM DNS servers and upstream resolvers will use encrypted DNS, and which will stay on plain DNS during transition.
- Agree in writing whether the DoT policy is strict or fallback, and which clients are expected to resolve through it.
- Confirm the certificate source, validity handling and who owns renewal before any installation option is chosen. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we build
- Set up a test FreeIPA topology that mirrors your replica layout, DNS locations and client resolver configuration.
- Configure DoT at installation or on existing servers, with upstream DoT forwarders and certificate files checked against your policy.
- Test name resolution from enrolled clients under both strict and fallback behavior, including failure of the upstream DoT server.
How we hand over
- Document the install options, forwarder settings, certificate paths and policy values as they were deployed in your environment.
- Provide runbooks for certificate renewal, forwarder changes, rollback to plain DNS and checks on each IdM DNS server.
- Walk your operations and security teams through the verification results and the evidence they can keep for internal and assessment reviews.
How we support
- Review DoT settings and certificate expiry as part of each FreeIPA upgrade, including changes that arrive in later 4.x releases.
- Re-test client resolution after topology changes, replica additions or changes to upstream resolvers.
- Ask any support provider to confirm response scope, change control and how DNS incidents are escalated before signing a retainer.
