DNSSEC in FreeIPA DNS

What DNSSEC in FreeIPA DNS does today

FreeIPA validates DNSSEC by default at install, and zone signing is a Technology Preview in RHEL IdM. These are two separate capabilities. Validation means the resolver checks the signatures on answers it receives from signed zones, so a signed record that fails verification is not trusted. Signing means the authoritative server holds the keys for a zone it hosts and publishes signatures for that zone's records. The sources behind this page do not cover DNSSEC settings, key handling or the exact scope of the preview, so confirm the behavior described here against the FreeIPA release and the RHEL IdM documentation you run before you plan around it.

Treat the signing question as a support and risk decision before it is a technical one. A Technology Preview should not be assumed to be production ready, so check the support terms that apply to your RHEL subscription and ask your vendor in writing what is covered. Signing also creates work that continues after the first setup: key generation and storage, scheduled key rollover, and a DS record in the parent zone that must match your current keys. Confirm with your DNS team who owns each of those steps, and whether your parent zone or registrar can accept the DS records you would publish.

If a zone must be signed now, plan that signing on an authoritative server outside the FreeIPA topology, such as a managed DNS provider or an existing signed external server, and keep FreeIPA as an internal resolver that validates. Before relying on either setup, run a test query with dig +dnssec against a FreeIPA DNS server and check for RRSIG records in the answer and the AD flag on validated responses. Repeat the same test from a client after each configuration change, record the results for your change board, and rehearse the change on a non-production replica first.

Which DNSSEC option fits your zones

This table compares the three ways a FreeIPA team can use DNSSEC: validating on IdM resolvers, signing internal zones inside IdM, and signing zones on an external DNS platform. Read each row against the zones you own and the team that will hold the signing keys. The main takeaway is that validation is on by default at install, while zone signing in IdM is a Technology Preview that you should confirm for your release before relying on it.

Option	What it covers	Who operates the keys	When it fits
Validation only on IdM resolvers	IdM resolvers check DNSSEC signatures on answers from zones signed by others, enabled by default at install	Owners of the upstream zones sign them; the IdM team maintains the resolver configuration	Environments that consume signed public or partner zones and do not need IdM to sign any zone
Signing internal zones in IdM (Technology Preview)	IdM signs the zones it hosts so clients can validate internal answers	IdM administrators hold and manage the keys inside IdM	Internal zones where the team can accept Technology Preview status and has tested key handling in a lab first
Signing zones on an external DNS platform	Authoritative zones are signed by a separate DNS platform outside FreeIPA	The external DNS team holds the keys and runs rollover procedures	Organizations that already run signing on a platform they support, or that must keep keys outside the identity team
Mixed model	IdM validates and signs internal zones while an external platform signs public zones	Split: IdM team for internal zones, external DNS team for public zones	Internal names served by IdM and public names on an external platform; confirm zone boundaries and delegation first

Signing in FreeIPA or elsewhere, by team situation

When FreeIPA is the only DNS authority for the zones your clients use, validation at install is the baseline, and zone signing becomes a question of whether your team can operate the keys over time. Start by confirming which zones IdM serves, whether any parent zone or upstream resolver validates answers, and whether anything outside IdM depends on the zone being signed. If the answers stay internal, signing is a contained change that one team can own end to end.

Zone inventory: list every zone IdM serves, including reverse zones, and mark which ones clients query through validating resolvers.
Parent delegation: confirm whether each zone is delegated from a parent you control, because a DS record must then be published upward.
Key ownership: name the team that rotates keys and watches for signing failures.
Change window: decide how a key rollover or a signing fault would be reversed on the IdM servers.

Collect the zone list, a test client configuration that shows validation behavior, and a written rollback procedure, then rehearse signing on a lab copy of the topology before any production change.

Checking DNS readiness before you enable DNSSEC

This sequence confirms that the release, name resolution, delegation and client resolver settings are sound before any DNSSEC change touches a zone. Each step closes with a check you can run, so the team knows what passed before moving on. Where possible, work through it in a test or staging topology first.

Confirm the release and its DNSSEC documentation
The platform owner records which FreeIPA or RHEL IdM release runs on each server that serves DNS, then reads the DNSSEC documentation for that exact version. In RHEL IdM, zone signing is a Technology Preview, so support boundaries and procedures can differ from upstream FreeIPA. Upstream 4.13.4, dated July 9, 2026, fixed two CVEs, so confirm whether your servers include that fix or a later one. Run rpm -q ipa-server on every IdM server. Done when each server reports the same package version and you hold the matching documentation for it.
Verify forward and reverse name resolution
The DNS administrator checks that every IdM server name resolves to its address and that the address resolves back to the same name. Run dig +short against each server's fully qualified name, then run dig -x against its IP address. Reverse zones must exist for every server address, and each PTR record should match the forward record. Done when every server returns a matching forward and reverse answer from both the server itself and a client.
Confirm delegation and NS records in the parent zone
The team compares the NS records in the parent zone with the IdM servers that actually serve the subdomain. In the illustrative case of ipa.example.com delegated from example.com, the parent should list only the FreeIPA DNS servers, each with a matching glue record where required. Any server added later needs its own delegation entry. Run dig NS ipa.example.com @parent-server and dig SOA ipa.example.com @each-idm-server. Done when the NS set matches the server list and each server answers authoritatively for the zone.
Confirm clients list at least two DNS servers
The client platform team reviews resolver configuration on a sample of Linux machines in each site. The FreeIPA deployment recommendations advise at least two DNS servers in each client's resolv.conf. If NetworkManager, DHCP or another tool manages that file, confirm which tool is the source of truth before editing anything. Run cat /etc/resolv.conf on each sampled host and getent hosts for an IdM server name. Done when every sampled client lists at least two reachable IdM DNS servers and resolves them.
Test resolution and validation from clients
The DNS administrator queries each IdM DNS server directly from a client, then through the normal resolver path. Check the Kerberos and LDAP SRV records that FreeIPA publishes, such as _kerberos._tcp and _ldap._tcp under the IdM domain, and compare answers across servers. Validation is enabled by default at install, so query a name you know is signed upstream with dig +dnssec and look for the ad flag. Done when all servers return identical SRV answers and the signed external name validates through the resolver the clients use.
Record a baseline before any signing change
The DNS administrator captures a fresh backup and a written baseline before anything changes. The baseline should list the release, zone list, forwarders, SOA serial on each server, and the output of the checks above. Take the backup with ipa-backup and keep it with the change record, since the backup documentation warns that restoring an outdated backup into an active replica topology can break replication. Done when the backup and baseline are stored with the change ticket and the team can repeat the same checks after the change.

What Technology Preview status means for support planning

A Technology Preview label tells you that a feature is offered for evaluation and feedback, and that the vendor does not position it as ready for unrestricted production use. The exact meaning depends on the vendor's support policy, which is the document that governs what you can expect in a ticket. For DNSSEC zone signing in FreeIPA DNS on RHEL IdM, do not infer support terms from the label alone. Ask Red Hat, in writing, which parts of zone signing are covered, which configurations are excluded, and whether the feature is expected to move out of preview. Confirm the answers against the release you plan to run, because a preview feature can change between minor releases.

Upgrade behavior and rollback deserve the same scrutiny. Ask how signed zones, key material and DNS configuration are handled when you move to a newer IdM release, whether a signed zone can be returned to unsigned state without DNS outages, and what the supported procedure is if a key rollover or upgrade goes wrong. Your answers will decide how risky a signed zone is to change. If the vendor cannot give a clear rollback path, treat that as a planning input, not a footnote. Check the documentation for each release you plan to run, and test the upgrade and rollback sequence in a lab that mirrors your replica topology before you sign a production zone.

Document a fallback plan before the first signature is published. The plan should name who can disable signing, which DS records must be removed from the parent zone first so that validating resolvers do not return SERVFAIL, how long you expect resolver caches to hold the old data, and who signs off on the change. Keep the procedure with your DNS runbook, and rehearse it. If your organization needs a supported signing path with clearer support boundaries, weigh signing the zone on an external DNS platform instead, and make sure the FreeIPA side of that decision is recorded with it.

Key handling and trust risks to plan for

DNSSEC adds a trust chain that depends on keys, a parent zone entry and healthy validation. The cards below cover the controls a team has to own, because a mistake in any one of them can make names unreachable for validating resolvers rather than merely slow.

DS record publication at the parent

Validation only works once the parent zone publishes a DS record matching your zone's signing key. The DS record is a manual handoff to whoever controls the parent, so it sits outside FreeIPA's control. Before enabling validation for a signed zone, confirm who publishes the DS record, how it is verified against the live key, and who removes it during a key rollover or when signing is turned off.

Key storage and access

The zone signing keys live on the IdM DNS servers, so anyone with root on those hosts can use them to sign forged answers. Treat the DNS servers as tier-zero hosts: restrict root and sudo access, log administrative changes to DNS, and confirm where key material is held and whether a hardware-backed option fits your environment. Ask the platform team to document this before go-live.

Effect of a key error on resolution

A wrong DS record, an expired signature or a mismatched key does not degrade gracefully. Validating resolvers treat the zone as bogus and return failures to every client that uses them, so a single error can take down a domain for users who never touched the change. Plan a rollback path for each signing change and test name resolution from clients that use validating resolvers before and after the change.

Signing state in backups

Signing keys and zone state are part of the DNS data that must be restored consistently with the rest of the IdM topology. The FreeIPA backup documentation warns that restoring an outdated backup into an active replica topology can break replication. Confirm that backups include the signing material you depend on, rehearse a restore in a test environment, and record which server was restored so keys and serials do not diverge.

Monitoring validation failures

Validation failures often appear first as user complaints about one application, not as an alert. Monitor signature expiry dates, DS record mismatches and SERVFAIL rates from your validating resolvers, and route those signals to the team that owns the DNS servers. Set the check to run against the names your users need, not only the zone apex, and review it after every key change.

Ownership across teams

Signing touches the IdM team, the team that manages the parent zone and the team that runs resolvers. If no single owner signs off on changes, a rollover can stall between them. Write down who performs each step, who approves the DS change and who responds when validation fails, and agree how that handoff works before you enable signing on a zone.

How DNSSEC interacts with delegation and external DNS

When FreeIPA serves a delegated subdomain such as ipa.example.com, DNSSEC does not stop at the FreeIPA zone. The parent zone must carry a DS record that points to the signing key of the child zone, or validating resolvers will treat the subdomain as unsigned or fail it, depending on configuration. That makes the parent zone owner a required party in any signing plan. If the corporate DNS team owns the parent, the DS record is their change to publish, and it has to be created after the FreeIPA zone is signed and the key material is final. Confirm with that team who publishes DS records, how they receive the value, and how long their change process takes before you schedule a key rollover.

Once the zone is signed, the teams have to coordinate three things that otherwise drift apart: the DS record in the parent, the signed zone on each name server, and any secondary servers that receive the zone. Zone transfers to external servers carry signed data only if every secondary is configured to accept the signed zone and the serial sequence is understood. Because FreeIPA's guidance points secondaries at a single IdM server, the external team should know which server is authoritative for transfers and which signing keys are in use. The sibling topic on zone transfers to external servers covers the mechanics. Here, the decision is who owns each step and who is told when the signing state changes.

Ask the external DNS team these questions before work starts: who owns the parent zone and the DS publication step, whether they can validate DNSSEC on their own resolvers, which name servers they are willing to delegate to, and how they will confirm that the chain of trust is intact after a change. Write the answers into the change plan, along with a rollback that removes or updates the DS record before the signing keys are altered. The delegation and zone transfer topics in this group cover the NS records and transfer settings that these steps depend on.

What to confirm in your RHEL IdM version and environment

DNSSEC support in FreeIPA depends on the exact RHEL IdM release, how zones are signed, and what your clients and backup routines expect. The cards below list the questions to put to Red Hat or to test in a lab before a signing decision reaches production.

Zone signing availability in your release

Confirm whether zone signing is available in the exact RHEL IdM release you run, and whether it is supported or still a Technology Preview. Validation being on by default does not mean your zones can be signed. Ask for the release notes and support statement for your minor version, and record the answer against the version you will deploy, not the upstream FreeIPA version.

Supported algorithms and key storage

Ask which DNSSEC signing algorithms and key lengths the release supports, and where the zone signing keys are stored. Find out whether keys stay in software on the IdM servers or can sit in an HSM, and who may export or rotate them. Your key custody answer determines your audit trail and your recovery plan if a server is lost.

Behavior after replica promotion

Test what happens to signed zones and key material when a replica is promoted or a server is removed from the topology. Confirm which server performs signing and key maintenance, whether the new replica takes over with the same keys, and whether signatures stay valid across the change. Run this in a lab with the same replica count you plan to use.

Signed zones in backup and restore

Confirm how signed zones and their keys are captured by ipa-backup and restored by ipa-restore. Check whether a restore reproduces the same keys and signatures, and what happens if you restore an older backup into an active topology. The backup documentation already warns about restoring outdated data into active replicas, so verify the DNSSEC state explicitly in a restore test.

Client behavior with validating resolvers

Test how your clients, SSSD hosts and upstream resolvers behave when they validate signed answers. Include any forwarders, corporate DNS servers and resolvers on your Active Directory side. A misconfigured forwarder or a wrong trust anchor can turn a healthy zone into SERVFAIL responses for every client, so list each validating resolver and confirm its behavior with signed test records.

How much work is DNSSEC in FreeIPA DNS, and what do we need?

How much effort is validation-only DNSSEC compared with zone signing?

Validation-only work is usually the smaller job, because it checks signatures on answers your resolvers receive instead of changing how your own zones are published. Zone signing adds key generation, key rollover, delegation signer (DS) records at the parent zone, and ongoing checks that signatures stay valid. Zone signing is also a Technology Preview in RHEL IdM, so confirm with your vendor whether it is supported for your release and whether your change process allows a preview feature in production. Ask for the two options to be priced and scheduled separately so you can decide after the validation results.

What makes DNSSEC work in FreeIPA take longer?

Four factors move the effort most:

The number of zones to sign or validate, including reverse zones and any subdomains delegated to FreeIPA.
Coordination with external DNS, such as a corporate DNS team that owns the parent zone and must publish DS records.
Key policy: algorithm choice, key lifetimes, rollover schedule, and who holds the signing keys and approves changes.
Forwarders and secondary servers that sit between clients and FreeIPA, because each one must handle signed responses correctly.

Each zone adds test cases, and each external party adds a change window. Ask for these counts in the scope before you accept a figure.

Can our internal team implement DNSSEC in FreeIPA alone?

A team with working FreeIPA DNS experience can usually handle validation settings and lab testing alone, provided someone owns the change record and the rollback plan. Zone signing is harder to run alone the first time, because key rollover mistakes can make a signed zone fail validation for clients and break name resolution. Check whether your team has done a signed-zone rollback in a lab, whether it can test with the resolvers your clients actually use, and whether it has an on-call path for DNS outages. A partner can take the lab work, the runbook and the staged rollout, while your team keeps ownership of production.

What does the DNSSEC work need from our DNS and security teams?

Your DNS team must confirm the zone list, the delegation path from the parent zone, and who can publish DS records. Your security team must agree on the key policy, where keys are stored, who can access them, and how key events are logged and reviewed. Both teams should provide access to a lab that mirrors your resolver layout, test client configurations, and a maintenance window for any production change. Name one owner on each side before the work starts, because delays usually come from waiting for a parent-zone change, not from FreeIPA itself.

How long does a DNSSEC lab validation take?

The lab duration depends on the number of zones, the resolver paths you need to test, how many failure cases you want to exercise, and how quickly your team can provide a representative environment. A single zone with one resolver path is a much smaller test than a set of zones behind forwarders and external secondaries. Do not accept a duration that is not tied to a written scope. Ask the partner to list the zones, the test paths, the failure scenarios, and the evidence they will return, along with the calendar dependencies on your side.

What should a fixed-scope DNSSEC quote list?

A useful quote separates one-time work from recurring work and names each deliverable. Ask for the zones in scope, whether the work is validation-only or includes zone signing, the lab environment and test cases, the key policy to be documented, the rollout and rollback steps, and the handover runbook. List your responsibilities too, such as parent-zone changes, access to resolvers, and change approvals. Recurring items include key rollover support, monitoring, and any retainer for updates. Confirm what happens if a dependency slips, and ask how changes to the written scope are priced.

Is validation already on after a FreeIPA install?

DNSSEC validation is enabled by default at install in FreeIPA DNS, according to the scope notes for this topic, so the first question is whether validation is working for your clients and forwarders, not whether it is turned on. Confirm the setting on your installed version, then test lookups for signed and deliberately broken zones from the resolvers your clients use. Check that forwarders and any upstream resolvers do not strip or reject signed responses. Zone signing is a separate decision and should not be turned on as part of a routine install or upgrade.

How DeployOpen scopes DNSSEC work in FreeIPA

DeployOpen treats DNSSEC in FreeIPA DNS as a scoped decision before it is a configuration task. We confirm what the platform's DNSSEC support covers in your release, then agree in writing which zones, keys and validation settings are in and which are handled elsewhere.

How we scope

Inventory every DNS zone in the FreeIPA deployment and record which are internal, delegated or externally served.
Confirm with your vendor or release documentation whether zone signing is supported for your RHEL IdM version.
Write down whether DNSSEC signing applies to any zone, or whether validation alone is the agreed scope.

How we build

Plan key management, including who holds signing keys, rollover ownership and where key material is stored.
Test signing and validation in a non-production replica before any change reaches parent-zone or client-facing resolvers.
Verify resolution from clients and external resolvers after each step, with the test results kept with the change record.

How we hand over

Document the zones signed, the key roles, the rollover procedure and the rollback steps in a runbook your team owns.
Walk your DNS and security staff through validation failures, expired signatures and the checks they should run.
Record which items depend on a parent zone, registrar or external DNS team, so responsibilities stay visible after handover.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer, scoped to your FreeIPA DNS setup.
Ask any partner for a quote built from the written scope, including what recurs after key rollovers and release upgrades.