Chapter 7. Configuring DNS and realm settings for a trust


Before establishing a trust between Identity Management (IdM) and Active Directory (AD), you must ensure that both environments can mutually resolve domain names correctly.

To configure DNS resolution between an IdM server, using an integrated DNS server and a Certification Authority (CA), and an AD Domain Controller, perform the following tasks:

  • Prepare the IdM environment: configure the necessary DNS zones and resource records.
  • Enable cross-domain resolution: configure conditional DNS forwarding on the AD server to point to IdM.
  • Validate connectivity: verify the DNS configuration to ensure seamless communication between realms.

7.1. Unique primary DNS domains

For a successful Identity Management (IdM) to Active Directory (AD) trust, each environment must occupy a unique, dedicated DNS domain and Kerberos realm. This separation allows Active Directory to route authentication requests correctly via name suffix routing.

Each system must have its own unique primary DNS domain configured. For example:

  • ad.example.com for AD and idm.example.com for IdM
  • example.com for AD and idm.example.com for IdM
  • ad.example.com for AD and example.com for IdM

The most convenient management solution is an environment where each DNS domain is managed by integrated DNS servers, but it is possible to use any other standard-compliant DNS server as well.

Kerberos realm names as upper-case versions of primary DNS domain names
Kerberos realm names must match the primary DNS domain names, with all letters uppercase. For example, if the domain names are ad.example.com for AD and idm.example.com for IdM, the Kerberos realm names are required to be AD.EXAMPLE.COM and IDM.EXAMPLE.COM.
DNS records resolvable from all DNS domains in the trust
All machines must resolve DNS records from all DNS domains involved in the trust relationship.
IdM and AD DNS Domains
Systems joined to IdM can be distributed over multiple DNS domains. Deploy IdM clients in a DNS zone separate from those managed by Active Directory. The primary IdM DNS domain must have proper SRV records to support AD trusts.
Note

In some environments with trusts between IdM and AD, you can install an IdM client on a host that is part of the Active Directory DNS domain. The host can then benefit from the Linux-focused features of IdM. This is not a recommended configuration and has some limitations.

You can acquire a list of the required SRV records specific to your system setup by running the following command:

$ ipa dns-update-system-records --dry-run

The generated list can look for example like this:

IPA DNS records:
  _kerberos-master._tcp.idm.example.com. 86400 IN SRV 0 100 88 server.idm.example.com.
  _kerberos-master._udp.idm.example.com. 86400 IN SRV 0 100 88 server.idm.example.com.
  _kerberos._tcp.idm.example.com. 86400 IN SRV 0 100 88 server.idm.example.com.
  _kerberos._tcp.idm.example.com. 86400 IN SRV 0 100 88 server.idm.example.com.
  _kerberos.idm.example.com. 86400 IN TXT "IDM.EXAMPLE.COM"
  _kpasswd._tcp.idm.example.com. 86400 IN SRV 0 100 464 server.idm.example.com.
  _kpasswd._udp.idm.example.com. 86400 IN SRV 0 100 464 server.idm.example.com.
  _ldap._tcp.idm.example.com. 86400 IN SRV 0 100 389 server.idm.example.com.
  _ipa-ca.idm.example.com. 86400 IN A 192.168.122.2

For other DNS domains that are part of the same IdM realm, it is not required for the SRV records to be configured when the trust to AD is configured. The reason is that AD domain controllers do not use SRV records to discover KDCs but rather base the KDC discovery on name suffix routing information for the trust.

Use the Identity Management (IdM) Web UI to configure DNS forward zones. This allows the IdM server to route queries for external domains, such as an Active Directory environment, to their respective DNS servers.

Prerequisites

  • Access to the IdM Web UI with a user account that has administrator rights.
  • Correctly configured DNS server.

Procedure

  1. Log in to the IdM Web UI with administrator privileges.
  2. Click the Network Services tab.
  3. Click the DNS tab.
  4. In the drop down menu, click DNS Forward Zones.

    Screenshot of the IdM Web UI displaying the contents of the DNS drop-down submenu of the "Network Services" tab. The DNS drop-down menu has four options: DNS Zones - DNS Forward Zones - DNS Servers - DNS Global Configuration. "DNS Forward Zones" is highlighted.

  5. Click the Add button.
  6. In the Add DNS forward zone dialog box, add a zone name.
  7. In the Zone forwarders item, click the Add button.
  8. In the Zone forwarders field, add the IP address of the server for which you want to create the forward zone.
  9. Click the Add button.

    Screenshot of the "Add DNS forward zone" pop-up window with text entry fields for "Zone name" - "Reverse zone IP network" - "Zone forwarders." The "Forward policy" option has three radial buttons for "forward first" - "forward only" - "forward disabled." There is a checkbox for "Skip overlap check" and there are four buttons at the bottom: "Add" - "Add and Add Another" - "Add and Edit" - "Cancel."

    The forwarded zone has been added to the DNS settings and you can verify it in the DNS Forward Zones settings. The Web UI informs you about success with the following pop-up message: DNS Forward Zone successfully added.

    Note

    After adding a forward zone to the configuration, the Web UI might display a warning about a DNSSEC validation failure.

    Screenshot displaying a pop-up window that reads "DNSSEC validation failed - record ad.example.com SOA failed DNSSEC validation on server 192.168.122.2. Please verify your DNSSEC configuration or disable DNSSEC validation on all IPA servers."

    DNSSEC (Domain Name System Security Extensions) secures DNS data with a digital signature to protect DNS from attacks. This service is enabled by default in the IdM server. The warning appears because the remote DNS server does not use DNSSEC. Enable DNSSEC on the remote DNS server.

    If you cannot enable DNSSEC validation on the remote server, you can disable DNSSEC in the IdM server:

    1. Open the /etc/named/ipa-options-ext.conf file on your IdM server.
    2. Add the following DNSSEC parameters:

      dnssec-validation no;
    3. Save and close the configuration file.
    4. Restart the DNS service:

      # systemctl restart named

    Note that DNSSEC is only available as Technology Preview in IdM.

Verification

  • Use the nslookup command with the name of the remote DNS server:

    $ nslookup ad.example.com
    Server:        192.168.122.2
    Address:       192.168.122.2#53
    
    No-authoritative answer:
    Name:          ad.example.com
    Address:       192.168.122.3

    If you configured the domain forwarding correctly, the IP address of the remote DNS server is displayed.

7.3. Configuring a DNS forward zone in the CLI

Use the Identity Management (IdM) CLI to configure DNS forward zones. This allows the IdM server to route queries for external domains, such as an Active Directory environment, to their respective DNS servers.

Prerequisites

  • Access to the CLI with a user account that has administrator rights.
  • Correctly configured DNS server.

Procedure

  • Create a DNS forward zone for the AD domain, and specify the IP address of the remote DNS server with the --forwarder option:

    # ipa dnsforwardzone-add ad.example.com --forwarder=192.168.122.3 --forward-policy=first
    Note

    You might see a warning about a DNSSEC validation failure in the /var/log/messages system logs after adding a new forward zone to the configuration:

    named[2572]: no valid DS resolving 'host.ad.example.com/A/IN':  192.168.100.25#53

    DNSSEC (Domain Name System Security Extensions) secures DNS data with a digital signature to protect DNS from attacks. This service is enabled by default in the IdM server. The warning appears because the remote DNS server does not use DNSSEC. Enable DNSSEC on the remote DNS server.

    If you cannot enable DNSSEC validation on the remote server, you can disable DNSSEC in the IdM server:

    1. Open the /etc/named/ipa-options-ext.conf file on your IdM server.
    2. Add the following DNSSEC parameters:

      dnssec-validation no;
    3. Save and close the configuration file.
    4. Restart the DNS service:

      # systemctl restart named

    Note that DNSSEC is only available as Technology Preview in IdM.

Verification

  • Use the nslookup command with the name of the remote DNS server:

    $ nslookup ad.example.com
    Server:        192.168.122.2
    Address:       192.168.122.2#53
    
    No-authoritative answer:
    Name:          ad.example.com
    Address:       192.168.122.3

    If the domain forwarding is configured correctly, the nslookup request displays an IP address of the remote DNS server.

7.4. Configuring DNS forwarding in AD

Configure a conditional forwarder in Active Directory (AD) to enable the Windows environment to resolve the Identity Management (IdM) domain. This is essential for AD to locate IdM Kerberos and LDAP services.

Prerequisites

  • Windows Server with AD installed.
  • DNS port open on both servers.

Procedure

  1. Log in to the Windows Server.
  2. Open Server Manager.
  3. Open DNS Manager.
  4. In Conditional Forwarders, add a new forwarder and enter:

    • DNS Domain: The fully qualified domain name, for example, server.idm.example.com
    • IP Address: The IP address of the IdM DNS server.
  5. Save the settings.

7.5. Verifying the DNS configuration

Verify that both Identity Management (IdM) and Active Directory (AD) can resolve their own service records and those of the peer domain. Ensure successful bidirectional resolution before establishing the trust relationship.

Prerequisites

  • You are logged in with an account that has sudo permissions.

Procedure

  1. Run a DNS query for the Kerberos over UDP and LDAP over TCP service records.

    [admin@server ~]# dig +short -t SRV _kerberos._udp.idm.example.com.
    0 100 88 server.idm.example.com.
    [admin@server ~]# dig +short -t SRV _ldap._tcp.idm.example.com.
    0 100 389 server.idm.example.com.

    The commands return the SRV records for the IdM servers.

  2. Run a DNS query for the TXT record with the IdM Kerberos realm name. The returned value should match the Kerberos realm you specified when installing IdM.

    [admin@server ~]# dig +short -t TXT _kerberos.idm.example.com.
    "IDM.EXAMPLE.COM"

    If the previous steps did not return all the expected records, update the DNS configuration with the missing records:

    • If your IdM environment uses an integrated DNS server, enter the ipa dns-update-system-records command without any options to update your system records:

      [admin@server ~]$ ipa dns-update-system-records
    • If your IdM environment does not use an integrated DNS server:

      1. On the IdM server, export the IdM DNS records into a file:

        [admin@server ~]$ ipa dns-update-system-records --dry-run --out dns_records_file.nsupdate

        The command creates a file named dns_records_file.nsupdate with the relevant IdM DNS records.

      2. Submit a DNS update request to your DNS server using the nsupdate utility and the dns_records_file.nsupdate file. For more information, see Updating External DNS Records Using nsupdate in RHEL 7 documentation. Alternatively, refer to your DNS server documentation for adding DNS records.
  3. Verify that IdM is able to resolve service records for AD with a command that runs a DNS query for Kerberos and LDAP over TCP service records:

    [admin@server ~]# dig +short -t SRV _kerberos._tcp.dc._msdcs.ad.example.com.
    0 100 88 addc1.ad.example.com.
    [admin@server ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.ad.example.com.
    0 100 389 addc1.ad.example.com.
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2026 Red Hat
Back to top