Working with DNS in Identity Management
Managing the DNS service integrated in RHEL IdM
Abstract
Providing feedback on Red Hat documentation Copy linkLink copied to clipboard!
We are committed to providing high-quality documentation and value your feedback. To help us improve, you can submit suggestions or report errors through the Red Hat Jira tracking system.
Procedure
Log in to the Jira website.
If you do not have an account, select the option to create one.
- Click Create in the top navigation bar.
- Enter a descriptive title in the Summary field.
- Enter your suggestion for improvement in the Description field. Include links to the relevant parts of the documentation.
- Click Create at the bottom of the dialogue.
Chapter 1. Managing global DNS configuration in IdM using Ansible playbooks Copy linkLink copied to clipboard!
Configure global DNS settings using the freeipa.ansible_freeipa.dnsconfig Ansible module, including forwarders and forwarding policies that apply to all Identity Management (IdM) DNS servers.
The dnsconfig module supports the following variables:
- The global forwarders, specifically their IP addresses and the port used for communication.
- The global forwarding policy: only, first, or none. For more details on these types of DNS forward policies, see DNS forward policies in IdM.
The synchronization of forward lookup and reverse lookup zones.
- NOTE
- Global configuration has lower priority than the configuration for a specific IdM DNS zone.
1.1. Prerequisites Copy linkLink copied to clipboard!
DNS service is installed on the IdM server. For more information about how to install an IdM server with integrated DNS, see one of the following links:
1.2. How IdM ensures that global forwarders from /etc/resolv.conf are not removed by NetworkManager Copy linkLink copied to clipboard!
Understand how Identity Management (IdM) configures NetworkManager to preserve DNS settings in /etc/resolv.conf on DHCP networks.
Installing IdM with integrated DNS configures the /etc/resolv.conf file to point to the 127.0.0.1 localhost address:
# Generated by NetworkManager search idm.example.com nameserver 127.0.0.1
# Generated by NetworkManager
search idm.example.com
nameserver 127.0.0.1
In certain environments, such as networks that use Dynamic Host Configuration Protocol (DHCP), the NetworkManager service may revert changes to the /etc/resolv.conf file. To make the DNS configuration persistent, the IdM DNS installation process also configures the NetworkManager service in the following way:
The DNS installation script creates an
/etc/NetworkManager/conf.d/zzz-ipa.confNetworkManagerconfiguration file to control the search order and DNS server list:Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
The
NetworkManagerservice is reloaded, which always creates the/etc/resolv.conffile with the settings from the last file in the/etc/NetworkManager/conf.d/directory. This is in this case thezzz-ipa.conffile.
Do not modify the /etc/resolv.conf file manually.
1.3. Ensuring the presence of a DNS global forwarder in IdM using Ansible Copy linkLink copied to clipboard!
Add a global DNS forwarder to Identity Management (IdM) using Ansible to resolve queries for domains outside your IdM DNS zones.
In the example below, the IdM administrator ensures the presence of a DNS global forwarder with an Internet Protocol (IP) v4 address of 7.7.9.9 and IP v6 address of 2001:db8::1:0 on port 53.
Prerequisites
You have configured your Ansible control node to meet the following requirements:
- You are using Ansible version 2.15 or later.
-
You have installed the
ansible-freeipapackage. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_passwordand that you have access to a file that stores the password protecting the secret.yml file.
-
The target node, that is the node on which the
freeipa.ansible_freeipamodule is executed, is part of the IdM domain as an IdM client, server or replica.
Procedure
Navigate to the ~/MyPlaybooks/ directory:
cd ~/MyPlaybooks/
$ cd ~/MyPlaybooks/Copy to Clipboard Copied! Toggle word wrap Toggle overflow Make a copy of the forwarders-absent.yml Ansible playbook file from the relevant collections directory and rename it. For example:
cp /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfig/forwarders-absent.yml ensure-presence-of-a-global-forwarder.yml
$ cp /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfig/forwarders-absent.yml ensure-presence-of-a-global-forwarder.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Open the
ensure-presence-of-a-global-forwarder.ymlfile for editing. Adapt the file by setting the following variables:
-
Change the
namevariable for the playbook toPlaybook to ensure the presence of a global forwarder in IdM DNS. -
In the
taskssection, change thenameof the task toEnsure the presence of a DNS global forwarder to 7.7.9.9 and 2001:db8::1:0 on port 53. In the
forwarderssection of thefreeipa.ansible_freeipa.ipadnsconfigportion:-
Change the first
ip_addressvalue to the IPv4 address of the global forwarder:7.7.9.9. -
Change the second
ip_addressvalue to the IPv6 address of the global forwarder:2001:db8::1:0. -
Verify the
portvalue is set to53.
-
Change the first
Change the
statetopresent.This the modified Ansible playbook file for the current example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Change the
Save the file.
For details about all variables used in the playbook, see the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/README-dnsconfig.mdfile on the control node.Run the playbook:
ansible-playbook --vault-password-file=password_file -v -i inventory.file ensure-presence-of-a-global-forwarder.yml
$ ansible-playbook --vault-password-file=password_file -v -i inventory.file ensure-presence-of-a-global-forwarder.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.4. Ensuring the absence of a DNS global forwarder in IdM using Ansible Copy linkLink copied to clipboard!
Remove a global DNS forwarder from Identity Management (IdM) using Ansible when decommissioning external DNS servers or changing your forwarding configuration.
In the example procedure below, the IdM administrator ensures the absence of a DNS global forwarder with an Internet Protocol (IP) v4 address of 8.8.6.6 and IP v6 address of 2001:4860:4860::8800 on port 53.
Prerequisites
You have configured your Ansible control node to meet the following requirements:
- You are using Ansible version 2.15 or later.
-
You have installed the
ansible-freeipapackage. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_passwordand that you have access to a file that stores the password protecting the secret.yml file.
-
The target node, that is the node on which the
freeipa.ansible_freeipamodule is executed, is part of the IdM domain as an IdM client, server or replica.
Procedure
Navigate to the ~/MyPlaybooks/ directory:
cd ~/MyPlaybooks/
$ cd ~/MyPlaybooks/Copy to Clipboard Copied! Toggle word wrap Toggle overflow Make a copy of the forwarders-absent.yml Ansible playbook file from the relevant collections directory and rename it. For example:
cp /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfig/forwarders-absent.yml ensure-absence-of-a-global-forwarder.yml
$ cp /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfig/forwarders-absent.yml ensure-absence-of-a-global-forwarder.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Open the
ensure-absence-of-a-global-forwarder.ymlfile for editing. Adapt the file by setting the following variables:
-
Change the
namevariable for the playbook toPlaybook to ensure the absence of a global forwarder in IdM DNS. -
In the
taskssection, change thenameof the task toEnsure the absence of a DNS global forwarder to 8.8.6.6 and 2001:4860:4860::8800 on port 53. In the
forwarderssection of thefreeipa.ansible_freeipa.ipadnsconfigportion:-
Change the first
ip_addressvalue to the IPv4 address of the global forwarder:8.8.6.6. -
Change the second
ip_addressvalue to the IPv6 address of the global forwarder:2001:4860:4860::8800. -
Verify the
portvalue is set to53.
-
Change the first
-
Set the
actionvariable tomember. -
Verify the
stateis set toabsent.
This the modified Ansible playbook file for the current example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ImportantIf you only use the
state: absentoption in your playbook without also usingaction: member, the playbook fails.-
Change the
Save the file.
For details about all variables used in the playbook, see the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/README-dnsconfig.mdfile on the control node.Run the playbook:
ansible-playbook --vault-password-file=password_file -v -i inventory.file ensure-absence-of-a-global-forwarder.yml
$ ansible-playbook --vault-password-file=password_file -v -i inventory.file ensure-absence-of-a-global-forwarder.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.5. The action: member option in ipadnsconfig ansible-freeipa modules Copy linkLink copied to clipboard!
Review examples showing when action: member is needed with the ipadnsconfig module for managing global forwarders in Identity Management (IdM) using Ansible.
Excluding global forwarders in IdM by using the ansible-freeipa ipadnsconfig module requires using the action: member option in addition to the state: absent option. If you only use state: absent in your playbook without also using action: member, the playbook fails. Consequently, to remove all global forwarders, you must specify all of them individually in the playbook. In contrast, the state: present option does not require action: member.
The following table provides configuration examples for both adding and removing DNS global forwarders that demonstrate the correct use of the action: member option. The table shows, in each line:
- The global forwarders configured before executing a playbook
- An excerpt from the playbook
- The global forwarders configured after executing the playbook
| Forwarders before | Playbook excerpt | Forwarders after |
|---|---|---|
| 8.8.6.6 |
| 8.8.6.7 |
| 8.8.6.6 |
| 8.8.6.6, 8.8.6.7 |
| 8.8.6.6, 8.8.6.7 |
| Trying to execute the playbook results in an error. The original configuration - 8.8.6.6, 8.8.6.7 - is left unchanged. |
| 8.8.6.6, 8.8.6.7 |
| 8.8.6.6 |
1.6. DNS forward policies in IdM Copy linkLink copied to clipboard!
Understand the DNS forward policy types in Identity Management (IdM) and how they determine whether queries are forwarded, resolved locally, or treated as non‑existent.
IdM supports the first and only standard BIND forward policies, as well as the none IdM-specific forward policy.
- Forward first (default)
-
The IdM BIND service forwards DNS queries to the configured forwarder. If a query fails because of a server error or timeout, BIND falls back to the recursive resolution using servers on the Internet. The
forward firstpolicy is the default policy, and it is suitable for optimizing DNS traffic. - Forward only
-
The IdM BIND service forwards DNS queries to the configured forwarder. If a query fails because of a server error or timeout, BIND returns an error to the client. The
forward onlypolicy is recommended for environments with split DNS configuration. - None (forwarding disabled)
-
DNS queries are not forwarded with the
noneforwarding policy. Disabling forwarding is only useful as a zone-specific override for global forwarding configuration. This option is the IdM equivalent of specifying an empty list of forwarders in BIND configuration.
You cannot use forwarding to combine data in IdM with data from other DNS servers. You can only forward queries for specific subzones of the primary zone in IdM DNS.
By default, the BIND service does not forward queries to another server if the queried DNS name belongs to a zone for which the IdM server is authoritative. In such a situation, if the queried DNS name cannot be found in the IdM database, the NXDOMAIN answer is returned. Forwarding is not used.
Example 1.1. Example Scenario
The IdM server is authoritative for the test.example. DNS zone. BIND is configured to forward queries to the DNS server with the 192.0.2.254 IP address.
When a client sends a query for the nonexistent.test.example. DNS name, BIND detects that the IdM server is authoritative for the test.example. zone and does not forward the query to the 192.0.2.254. server. As a result, the DNS client receives the NXDomain error message, informing the user that the queried domain does not exist.
1.7. Using an Ansible playbook to ensure that the forward first policy is set in IdM DNS global configuration Copy linkLink copied to clipboard!
Set the global DNS forwarding policy to forward first in Identity Management (IdM) using Ansible, which tries forwarders first then falls back to recursive resolution.
The forward first policy is the default policy. It is suitable for traffic optimization. If a query fails because of a server error or timeout, BIND falls back to the recursive resolution using servers on the Internet.
Prerequisites
You have configured your Ansible control node to meet the following requirements:
- You are using Ansible version 2.15 or later.
-
You have installed the
ansible-freeipapackage. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_passwordand that you have access to a file that stores the password protecting the secret.yml file.
-
The target node, that is the node on which the
freeipa.ansible_freeipamodule is executed, is part of the IdM domain as an IdM client, server or replica. - Your IdM environment contains an integrated DNS server.
Procedure
Navigate to the ~/MyPlaybooks/ directory:
cd ~/MyPlaybooks/
$ cd ~/MyPlaybooks/Copy to Clipboard Copied! Toggle word wrap Toggle overflow Make a copy of the set-configuration.yml Ansible playbook file from the relevant collections directory and rename it. For example:
cp /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfig/set-configuration.yml set-forward-policy-to-first.yml
$ cp /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfig/set-configuration.yml set-forward-policy-to-first.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Open the set-forward-policy-to-first.yml file for editing.
Adapt the file by setting the following variables in the
freeipa.ansible_freeipa.ipadnsconfigtask section:-
Indicate that the value of the
ipaadmin_passwordvariable is defined in the secret.yml Ansible vault file. Set the
forward_policyvariable to first.Delete all the other lines of the original playbook that are irrelevant. This is the modified Ansible playbook file for the current example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Indicate that the value of the
Save the file.
For details about variables and example playbooks in the FreeIPA Ansible collection, see the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/README-dnsconfig.mdfile and the/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfigdirectory on the control node.Run the playbook:
ansible-playbook --vault-password-file=password_file -v -i inventory.file set-forward-policy-to-first.yml
$ ansible-playbook --vault-password-file=password_file -v -i inventory.file set-forward-policy-to-first.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.8. Using an Ansible playbook to ensure that global forwarders are disabled in IdM DNS Copy linkLink copied to clipboard!
Disable global DNS forwarding in Identity Management (IdM) using Ansible to force the server to use recursive resolution instead.
Disabling forwarding is only useful as a zone-specific override for global forwarding configuration. This option is the IdM equivalent of specifying an empty list of forwarders in BIND configuration.
Prerequisites
You have configured your Ansible control node to meet the following requirements:
- You are using Ansible version 2.15 or later.
-
You have installed the
ansible-freeipapackage. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_passwordand that you have access to a file that stores the password protecting the secret.yml file.
-
The target node, that is the node on which the
freeipa.ansible_freeipamodule is executed, is part of the IdM domain as an IdM client, server or replica. - Your IdM environment contains an integrated DNS server.
Procedure
Navigate to the ~/MyPlaybooks/ directory:
cd ~/MyPlaybooks/
$ cd ~/MyPlaybooks/Copy to Clipboard Copied! Toggle word wrap Toggle overflow Make a copy of the disable-global-forwarders.yml Ansible playbook file from the relevant collections directory. For example:
cp /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfig/disable-global-forwarders.yml disable-global-forwarders-copy.yml
$ cp /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfig/disable-global-forwarders.yml disable-global-forwarders-copy.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Open the disable-global-forwarders-copy.yml file for editing.
Adapt the file by setting the following variables in the
freeipa.ansible_freeipa.ipadnsconfigtask section:-
Indicate that the value of the
ipaadmin_passwordvariable is defined in the secret.yml Ansible vault file. Set the
forward_policyvariable to none.This is the modified Ansible playbook file for the current example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Indicate that the value of the
Save the file.
For details about variables and example playbooks in the FreeIPA Ansible collection, see the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/README-dnsconfig.mdfile and the/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfigdirectory on the control node.Run the playbook:
ansible-playbook --vault-password-file=password_file -v -i inventory disable-global-forwarders-copy.yml
$ ansible-playbook --vault-password-file=password_file -v -i inventory disable-global-forwarders-copy.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.9. Using an Ansible playbook to ensure that synchronization of forward and reverse lookup zones is disabled in IdM DNS Copy linkLink copied to clipboard!
Disable automatic synchronization between forward and reverse DNS zones in Identity Management (IdM) using Ansible for independent zone management.
Prerequisites
You have configured your Ansible control node to meet the following requirements:
- You are using Ansible version 2.15 or later.
-
You have installed the
ansible-freeipapackage. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_passwordand that you have access to a file that stores the password protecting the secret.yml file.
-
The target node, that is the node on which the
freeipa.ansible_freeipamodule is executed, is part of the IdM domain as an IdM client, server or replica. - Your IdM environment contains an integrated DNS server.
Procedure
Navigate to the ~/MyPlaybooks/ directory:
cd ~/MyPlaybooks/
$ cd ~/MyPlaybooks/Copy to Clipboard Copied! Toggle word wrap Toggle overflow Make a copy of the disallow-reverse-sync.yml Ansible playbook file from the relevant collections directory. For example:
cp /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfig/disallow-reverse-sync.yml disallow-reverse-sync-copy.yml
$ cp /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfig/disallow-reverse-sync.yml disallow-reverse-sync-copy.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Open the disallow-reverse-sync-copy.yml file for editing.
Adapt the file by setting the following variables in the
freeipa.ansible_freeipa.ipadnsconfigtask section:-
Indicate that the value of the
ipaadmin_passwordvariable is defined in the secret.yml Ansible vault file. Set the
allow_sync_ptrvariable to no.This is the modified Ansible playbook file for the current example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Indicate that the value of the
Save the file.
For details about variables and example playbooks in the FreeIPA Ansible collection, see the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/README-dnsconfig.mdfile and the/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfigdirectory on the control node.Run the playbook:
ansible-playbook --vault-password-file=password_file -v -i inventory.file disallow-reverse-sync-copy.yml
$ ansible-playbook --vault-password-file=password_file -v -i inventory.file disallow-reverse-sync-copy.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Chapter 2. Managing DNS zones in IdM Copy linkLink copied to clipboard!
Manage Identity Management (IdM) DNS zones to control how the network resolves names. You can add, remove, and configure primary zones to maintain a healthy DNS infrastructure.
2.1. Prerequisites Copy linkLink copied to clipboard!
DNS service is installed on the IdM server. For more information about how to install an IdM server with integrated DNS, see one of the following links:
- You understand which DNS zone types are supported in IdM.
2.2. Adding a primary DNS zone in IdM Web UI Copy linkLink copied to clipboard!
Create a new primary DNS zone using the Identity Management (IdM) Web UI. This graphical interface provides an intuitive way to name and initialize subdomains within the IdM environment.
Prerequisites
- You are logged in as IdM administrator.
Procedure
In the IdM Web UI, click
Network Services→DNS→DNS Zones.Managing IdM DNS primary zones
- Click at the top of the list of all zones.
Provide the zone name.
Entering an new IdM primary zone
- Click .
2.3. Adding a primary DNS zone in IdM CLI Copy linkLink copied to clipboard!
Add new subdomains to the DNS domain by executing the ipa dnszone-add command. This command allows for direct input of the zone name or provides interactive prompts for missing details.
Prerequisites
- You are logged in as IdM administrator.
Procedure
The
ipa dnszone-addcommand adds a new zone to the DNS domain. Adding a new zone requires you to specify the name of the new subdomain. You can pass the subdomain name directly with the command:ipa dnszone-add newzone.idm.example.com
$ ipa dnszone-add newzone.idm.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow If you do not pass the name to
ipa dnszone-add, the script prompts for it automatically.
2.4. Removing a primary DNS zone in IdM Web UI Copy linkLink copied to clipboard!
Delete unnecessary DNS zones through the Network Services section of the IdM Web UI. Removing a zone permanently deletes its associated records from the Identity Management database.
Prerequisites
- You are logged in as IdM administrator.
Procedure
-
In the IdM Web UI, click
Network Services→DNS→DNS Zones. Select the check box by the zone name and click .
Removing a primary DNS Zone
- In the Remove DNS zones dialog window, confirm that you want to delete the selected zone.
2.5. Removing a primary DNS zone in IdM CLI Copy linkLink copied to clipboard!
Remove a primary DNS zone by using the ipa dnszone-del command. Specifying the target zone name instantly deletes the entry and its configuration from the IdM server.
Prerequisites
- You are logged in as IdM administrator.
Procedure
To remove a primary DNS zone, enter the
ipa dnszone-delcommand, followed by the name of the zone you want to remove. For example:ipa dnszone-del idm.example.com
$ ipa dnszone-del idm.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.6. DNS configuration priorities Copy linkLink copied to clipboard!
IdM applies DNS settings based on a specific hierarchy. Zone-specific settings take the highest priority, followed by per-server and global configurations, while manual entries in /etc/named.conf carry the lowest weight.
- Zone-specific configuration
-
The level of configuration specific for a particular zone defined in IdM has the highest priority. You can manage zone-specific configuration by using the
ipa dnszone-*andipa dnsforwardzone-*commands. - Per-server configuration
-
You are asked to define per-server forwarders during the installation of an IdM server. You can manage per-server forwarders by using the
ipa dnsserver-*commands. If you do not want to set a per-server forwarder when installing a replica, you can use the--no-forwarderoption. - Global DNS configuration
-
If no zone-specific configuration is defined, IdM uses global DNS configuration stored in LDAP. You can manage global DNS configuration using the
ipa dnsconfig-*commands. Settings defined in global DNS configuration are applied to all IdM DNS servers. - Configuration in
/etc/named.conf Configuration defined in the
/etc/named.conffile on each IdM DNS server has the lowest priority. It is specific for each server and must be edited manually.The
/etc/named.conffile is usually only used to specify DNS forwarding to a local DNS cache. Other options are managed using the commands for zone-specific and global DNS configuration mentioned above.
You can configure DNS options on multiple levels at the same time. In such cases, configuration with the highest priority takes precedence over configuration defined at lower levels.
2.7. Configuration attributes of primary IdM DNS zones Copy linkLink copied to clipboard!
Identity Management (IdM) initializes zones with default settings for refresh periods, transfers, and caching. You can modify these attributes to control SOA record behavior and update frequency via the CLI or Web UI.
In IdM DNS zone attributes, you can find the attributes of the default zone configuration that you can modify using one of the following options:
-
The
dnszone-modcommand on the command line (CLI). For more information, see Editing the configuration of a primary DNS zone in IdM CLI. - The IdM Web UI. For more information, see Editing the configuration of a primary DNS zone in IdM Web UI.
Along with setting the actual information for the zone, the settings define how the DNS server handles the start of authority (SOA) record entries and how it updates its records from the DNS name server.
| Attribute | Command-Line Option | Description |
|---|---|---|
| Authoritative name server |
| Sets the domain name of the primary DNS name server, also known as SOA MNAME.
By default, each IdM server advertises itself in the SOA MNAME field. Consequently, the value stored in LDAP using |
| Administrator e-mail address |
| Sets the email address to use for the zone administrator. This defaults to the root account on the host. |
| SOA serial |
| Sets a serial number in the SOA record. Note that IdM sets the version number automatically and users are not expected to modify it. |
| SOA refresh |
| Sets the interval, in seconds, for a secondary DNS server to wait before requesting updates from the primary DNS server. |
| SOA retry |
| Sets the time, in seconds, to wait before retrying a failed refresh operation. |
| SOA expire |
| Sets the time, in seconds, that a secondary DNS server will try to perform a refresh update before ending the operation attempt. |
| SOA minimum |
| Sets the time to live (TTL) value in seconds for negative caching according to RFC 2308. |
| SOA time to live |
|
Sets TTL in seconds for records at zone apex. In zone |
| Default time to live |
| Sets the default time to live (TTL) value in seconds for negative caching for all values in a zone that never had an individual TTL value set before. |
| BIND update policy |
| Sets the permissions allowed to clients in the DNS zone. |
| Dynamic update |
| Enables dynamic updates to DNS records for clients. Note that if this is set to false, IdM client machines will not be able to add or update their IP address. |
| Allow transfer |
| Gives a list of IP addresses or network names which are allowed to transfer the given zone, separated by semicolons (;).
Zone transfers are disabled by default. The default |
| Allow query |
| Gives a list of IP addresses or network names which are allowed to issue DNS queries, separated by semicolons (;). |
| Allow PTR sync |
| Sets whether A or AAAA records (forward records) for the zone will be automatically synchronized with the PTR (reverse) records. |
| Zone forwarders |
| Specifies a forwarder specifically configured for the DNS zone. This is separate from any global forwarders used in the IdM domain. To specify multiple forwarders, use the option multiple times. |
| Forward policy |
| Specifies the forward policy. For information about the supported policies, see DNS forward policies in IdM. |
2.8. Editing the configuration of a primary DNS zone in IdM Web UI Copy linkLink copied to clipboard!
Modify zone configuration attributes such as TTL and refresh intervals through the Settings tab in the IdM Web UI. Changes to most attributes take effect immediately across the IdM environment.
Prerequisites
- You are logged in as IdM administrator.
Procedure
In the IdM Web UI, click
Network Services→DNS→DNS Zones.DNS primary zones management
In the
DNS Zonessection, click on the zone name in the list of all zones to open the DNS zone page.Editing a primary zone
Click
Settings.The Settings tab in the primary zone edit page
Change the zone configuration as required.
For information about the available settings, see IdM DNS zone attributes.
Click to confirm the new configuration.
NoteIf you are changing the default time to live (TTL) of a zone, restart the
namedservice on all IdM DNS servers to make the changes take effect. All other settings are automatically activated immediately.
2.9. Editing the configuration of a primary DNS zone in IdM CLI Copy linkLink copied to clipboard!
Update existing DNS zone settings with the ipa dnszone-mod command. This tool overwrites current values or adds new ones for specific attributes like retry intervals and update policies.
Prerequisites
- You are logged in as IdM administrator.
Procedure
To modify an existing primary DNS zone, use the
ipa dnszone-modcommand. For example, to set the time to wait before retrying a failed refresh operation to 1800 seconds:ipa dnszone-mod --retry 1800
$ ipa dnszone-mod --retry 1800Copy to Clipboard Copied! Toggle word wrap Toggle overflow For more information about the available settings and their corresponding CLI options, see IdM DNS zone attributes.
If a specific setting does not have a value in the DNS zone entry you are modifying, the
ipa dnszone-modcommand adds the value. If the setting does not have a value, the command overwrites the current value with the specified value.NoteIf you are changing the default time to live (TTL) of a zone, restart the
namedservice on all IdM DNS servers to make the changes take effect. All other settings are automatically activated immediately.
2.10. Zone transfers in IdM Copy linkLink copied to clipboard!
Zone transfers copy resource records between name servers to ensure data consistency. Identity Management (IdM) supports the AXFR and IXFR standards to distribute authoritative data to servers outside the primary zone.
In an Identity Management (IdM) deployment that has integrated DNS, you can use zone transfers to copy all resource records from one name server to another. Name servers maintain authoritative data for their zones. If you make changes to the zone on a DNS server that is authoritative for zone A DNS zone, you must distribute the changes among the other name servers in the IdM DNS domain that are outside zone A.
The IdM-integrated DNS can be written to by different servers simultaneously. The Start of Authority (SOA) serial numbers in IdM zones are not synchronized among the individual IdM DNS servers. For this reason, configure your DNS servers outside the to-be-transferred zone to only use one specific DNS server inside the to-be-transferred zone. This prevents zone transfer failures caused by non-synchronized SOA serial numbers.
IdM supports zone transfers according to the RFC 5936 (AXFR) and RFC 1995 (IXFR) standards.
2.11. Enabling zone transfers in IdM Web UI Copy linkLink copied to clipboard!
Authorize specific name servers to receive zone records by updating the Allow Transfer settings in the IdM Web UI. This creates a secure list of IP addresses permitted to request full zone data.
Prerequisites
- You are logged in as IdM administrator.
Procedure
-
In the IdM Web UI, click
Network Services→DNS→DNS Zones. -
Click
Settings. Under
Allow transfer, specify the name servers to which you want to transfer the zone records.Figure 2.1. Enabling zone transfers
- Click at the top of the DNS zone page to confirm the new configuration.
2.12. Enabling zone transfers in IdM CLI Copy linkLink copied to clipboard!
Use the ipa dnszone-mod command with the --allow-transfer option to enable data distribution. This defines which external name servers can synchronize with the BIND service on the IdM host.
Prerequisites
- You are logged in as IdM administrator.
- You have root access to the secondary DNS servers.
Procedure
To enable zone transfers in the
BINDservice, enter theipa dnszone-modcommand, and specify the list of name servers that are outside the to-be-transferred zone to which the zone records will be transferred using the--allow-transferoption. For example:ipa dnszone-mod --allow-transfer=192.0.2.1;198.51.100.1;203.0.113.1 idm.example.com
$ ipa dnszone-mod --allow-transfer=192.0.2.1;198.51.100.1;203.0.113.1 idm.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
SSH to one of the DNS servers to which zone transfer has been enabled:
ssh 192.0.2.1
$ ssh 192.0.2.1Copy to Clipboard Copied! Toggle word wrap Toggle overflow Transfer the IdM DNS zone using a tool such as the
digutility:dig @ipa-server zone_name AXFR
# dig @ipa-server zone_name AXFRCopy to Clipboard Copied! Toggle word wrap Toggle overflow
If the command returns no error, you have successfully enabled zone transfer for zone_name.
Chapter 3. Using Ansible playbooks to manage IdM DNS zones Copy linkLink copied to clipboard!
Create and configure primary DNS zones in Identity Management (IdM) using Ansible to manage authoritative DNS data for your domain.
3.1. Prerequisites Copy linkLink copied to clipboard!
- DNS service is installed on the IdM server. For more information about how to use Ansible to install an IdM server with integrated DNS, see Installing an Identity Management server using an Ansible playbook.
3.2. Supported DNS zone types Copy linkLink copied to clipboard!
Understand the difference between primary zones for authoritative DNS data and forward zones for delegating queries to external servers.
This guide uses the BIND terminology for zone types which is different from the terminology used for Microsoft Windows DNS. Primary zones in BIND serve the same purpose as forward lookup zones and reverse lookup zones in Microsoft Windows DNS. Forward zones in BIND serve the same purpose as conditional forwarders in Microsoft Windows DNS.
Identity Management (IdM) supports two types of DNS zones: primary and forward zones.
- Primary DNS zones
Primary DNS zones contain authoritative DNS data and can accept dynamic DNS updates. This behavior is equivalent to the
type mastersetting in standard BIND configuration. You can manage primary zones using theipa dnszone-*commands.In compliance with standard DNS rules, every primary zone must contain
start of authority(SOA) andnameserver(NS) records. IdM generates these records automatically when the DNS zone is created, but you must copy the NS records manually to the parent zone to create proper delegation.In accordance with standard BIND behavior, queries for names for which the server is not authoritative are forwarded to other DNS servers. These DNS servers, so called forwarders, may or may not be authoritative for the query.
For example, in a scenario when the IdM server contains the
test.example.primary zone. This zone contains an NS delegation record for thesub.test.example.name. In addition, thetest.example.zone is configured with the192.0.2.254forwarder IP address for thesub.text.examplesubzone.A client querying the name
nonexistent.test.example.receives theNXDomainanswer, and no forwarding occurs because the IdM server is authoritative for this name.On the other hand, querying for the
host1.sub.test.example.name is forwarded to the configured forwarder192.0.2.254because the IdM server is not authoritative for this name.- Forward DNS zones
From the perspective of IdM, forward DNS zones do not contain any authoritative data. In fact, a forward "zone" usually only contains two pieces of information:
- A domain name
The IP address of a DNS server associated with the domain
All queries for names belonging to the domain defined are forwarded to the specified IP address. This behavior is equivalent to the
type forwardsetting in standard BIND configuration. You can manage forward zones using theipa dnsforwardzone-*commands.Forward DNS zones are especially useful in the context of IdM-Active Directory (AD) trusts. If the IdM DNS server is authoritative for the idm.example.com zone and the AD DNS server is authoritative for the ad.example.com zone, then ad.example.com is a DNS forward zone for the idm.example.com primary zone. That means that when a query comes from an IdM client for the IP address of somehost.ad.example.com, the query is forwarded to an AD domain controller specified in the ad.example.com IdM DNS forward zone.
3.3. Configuration attributes of primary IdM DNS zones when using Ansible Copy linkLink copied to clipboard!
Review the DNS zone attributes available in the Ansible ipadnszone module and tune them for optimal DNS performance.
Identity Management (IdM) creates a new zone with certain default configuration, such as the refresh periods, transfer settings, or cache settings. Below, you can find the attributes of the default zone configuration that you can modify using Ansible.
Along with setting the actual information for the zone, the settings define how the DNS server handles the start of authority (SOA) record entries and how it updates its records from the DNS name server.
| Attribute | ansible-freeipa variable | Description |
|---|---|---|
| Authoritative name server |
| Sets the domain name of the primary DNS name server, also known as SOA MNAME.
By default, each IdM server advertises itself in the SOA MNAME field. Consequently, the value stored in LDAP using |
| Administrator e-mail address |
| Sets the email address to use for the zone administrator. This defaults to the root account on the host. |
| SOA serial |
| Sets a serial number in the SOA record. Note that IdM sets the version number automatically and users are not expected to modify it. |
| SOA refresh |
| Sets the interval, in seconds, for a secondary DNS server to wait before requesting updates from the primary DNS server. |
| SOA retry |
| Sets the time, in seconds, to wait before retrying a failed refresh operation. |
| SOA expire |
| Sets the time, in seconds, that a secondary DNS server will try to perform a refresh update before ending the operation attempt. |
| SOA minimum |
| Sets the time to live (TTL) value in seconds for negative caching according to RFC 2308. |
| SOA time to live |
|
Sets TTL in seconds for records at zone apex. In zone |
| Default time to live |
| Sets the default time to live (TTL) value in seconds for negative caching for all values in a zone that never had an individual TTL value set before. |
| BIND update policy |
| Sets the permissions allowed to clients in the DNS zone. |
| Dynamic update |
| Enables dynamic updates to DNS records for clients. Note that if this is set to false, IdM client machines will not be able to add or update their IP address. |
| Allow transfer |
| Gives a list of IP addresses or network names which are allowed to transfer the given zone, separated by semicolons (;).
Zone transfers are disabled by default. The default |
| Allow query |
| Gives a list of IP addresses or network names which are allowed to issue DNS queries, separated by semicolons (;). |
| Allow PTR sync |
| Sets whether A or AAAA records (forward records) for the zone will be automatically synchronized with the PTR (reverse) records. |
| Zone forwarders |
| Specifies a forwarder specifically configured for the DNS zone. This is separate from any global forwarders used in the IdM domain. To specify multiple forwarders, use the option multiple times. |
| Forward policy |
| Specifies the forward policy. For information about the supported policies, see DNS forward policies in IdM. |
For details about all variables used in the playbook, see the /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/README-dnszone.md file on the control node.
3.4. Using Ansible to create a primary zone in IdM DNS Copy linkLink copied to clipboard!
Create a primary DNS zone in IdM to host authoritative DNS records for a domain managed by your IdM servers.
Prerequisites
You have configured your Ansible control node to meet the following requirements:
- You are using Ansible version 2.15 or later.
-
You have installed the
ansible-freeipapackage. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_passwordand that you have access to a file that stores the password protecting the secret.yml file.
-
The target node, that is the node on which the
freeipa.ansible_freeipamodule is executed, is part of the IdM domain as an IdM client, server or replica. - You know the IdM administrator password.
Procedure
Navigate to the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnszonedirectory:cd /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnszone
$ cd /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnszoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow Open your inventory file and ensure that the IdM server that you want to configure is listed in the
[ipaserver]section. For example, to instruct Ansible to configure server.idm.example.com, enter:[ipaserver] server.idm.example.com
[ipaserver] server.idm.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow Make a copy of the dnszone-present.yml Ansible playbook file. For example:
cp dnszone-present.yml dnszone-present-copy.yml
$ cp dnszone-present.yml dnszone-present-copy.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Open the dnszone-present-copy.yml file for editing.
Adapt the file by setting the following variables in the
ipadnszonetask section:-
Set the
ipaadmin_passwordvariable to your IdM administrator password. Set the
zone_namevariable to zone.idm.example.com.This is the modified Ansible playbook file for the current example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Set the
Save the file.
For details about variables and example playbooks in the FreeIPA Ansible collection, see the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/README-dnszone.mdfile and the/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnszonedirectory on the control node.Run the playbook:
ansible-playbook --vault-password-file=password_file -v -i inventory.file dnszone-present-copy.yml
$ ansible-playbook --vault-password-file=password_file -v -i inventory.file dnszone-present-copy.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.5. Using an Ansible playbook to ensure the presence of a primary DNS zone in IdM with multiple variables Copy linkLink copied to clipboard!
Create a DNS zone with custom settings such as administrator email, refresh intervals, and TTL values to meet your organization’s DNS requirements.
In the example below, you as an IdM administrator ensure the presence of the zone.idm.example.com DNS zone.
Prerequisites
You have configured your Ansible control node to meet the following requirements:
- You are using Ansible version 2.15 or later.
-
You have installed the
ansible-freeipapackage. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_passwordand that you have access to a file that stores the password protecting the secret.yml file.
-
The target node, that is the node on which the
freeipa.ansible_freeipamodule is executed, is part of the IdM domain as an IdM client, server or replica.
Procedure
Navigate to the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnszonedirectory:cd /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnszone
$ cd /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnszoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow Make a copy of the dnszone-all-params.yml Ansible playbook file. For example:
cp dnszone-all-params.yml dnszone-all-params-copy.yml
$ cp dnszone-all-params.yml dnszone-all-params-copy.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Open the dnszone-all-params-copy.yml file for editing.
Adapt the file by setting the following variables in the
freeipa.ansible_freeipa.ipadnszonetask section:-
Indicate that the value of the
ipaadmin_passwordvariable is defined in the secret.yml Ansible vault file. -
Set the
zone_namevariable to zone.idm.example.com. -
Set the
allow_sync_ptrvariable to true if you want to allow the synchronization of forward and reverse records, that is the synchronization of A and AAAA records with PTR records. -
Set the
dynamic_updatevariable to true to enable IdM client machines to add or update their IP addresses. -
Set the
dnssecvariable to true to allow inline DNSSEC signing of records in the zone. -
Set the
allow_transfervariable to the IP addresses of secondary name servers in the zone. -
Set the
allow_queryvariable to the IP addresses or networks that are allowed to issue queries. -
Set the
forwardersvariable to the IP addresses of global forwarders. -
Set the
serialvariable to the SOA record serial number. -
Define the
refresh,retry,expire,minimum,ttl, anddefault_ttlvalues for DNS records in the zone. -
Define the NSEC3PARAM record for the zone using the
nsec3param_recvariable. -
Set the
skip_overlap_checkvariable to true to force DNS creation even if it overlaps with an existing zone. Set the
skip_nameserver_checkto true to force DNS zone creation even if the nameserver is not resolvable.This is the modified Ansible playbook file for the current example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Indicate that the value of the
Save the file.
For details about variables and example playbooks in the FreeIPA Ansible collection, see the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/README-dnszone.mdfile and the/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnszonedirectory on the control node.Run the playbook:
ansible-playbook --vault-password-file=password_file -v -i inventory.file dnszone-all-params-copy.yml
$ ansible-playbook --vault-password-file=password_file -v -i inventory.file dnszone-all-params-copy.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.6. Using an Ansible playbook to ensure the presence of a zone for reverse DNS lookup when an IP address is given Copy linkLink copied to clipboard!
Use Ansible to create a reverse DNS zone to enable PTR record lookups for IP-to-hostname resolution.
In the example below, an IdM administrator ensures the presence of a reverse DNS lookup zone using the IP address and prefix length of an IdM host.
Providing the prefix length of the IP address of your DNS server using the name_from_ip variable allows you to control the zone name. If you do not state the prefix length, the system queries DNS servers for zones and, based on the name_from_ip value of 192.168.1.2, the query can return any of the following DNS zones:
- 1.168.192.in-addr.arpa.
- 168.192.in-addr.arpa.
- 192.in-addr.arpa.
Because the zone returned by the query might not be what you expect, name_from_ip can only be used with the state option set to present to prevent accidental removals of zones.
Prerequisites
You have configured your Ansible control node to meet the following requirements:
- You are using Ansible version 2.15 or later.
-
You have installed the
ansible-freeipapackage. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_passwordand that you have access to a file that stores the password protecting the secret.yml file.
-
The target node, that is the node on which the
freeipa.ansible_freeipamodule is executed, is part of the IdM domain as an IdM client, server or replica.
Procedure
Navigate to the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnszonedirectory:cd /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnszone
$ cd /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnszoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow Make a copy of the dnszone-reverse-from-ip.yml Ansible playbook file. For example:
cp dnszone-reverse-from-ip.yml dnszone-reverse-from-ip-copy.yml
$ cp dnszone-reverse-from-ip.yml dnszone-reverse-from-ip-copy.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Open the dnszone-reverse-from-ip-copy.yml file for editing.
Adapt the file by setting the following variables in the
freeipa.ansible_freeipa.ipadnszonetask section:-
Indicate that the value of the
ipaadmin_passwordvariable is defined in the secret.yml Ansible vault file. Set the
name_from_ipvariable to the IP of your IdM nameserver, and provide its prefix length.This is the modified Ansible playbook file for the current example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
The playbook creates a zone for reverse DNS lookup from the 192.168.1.2 IP address and its prefix length of 24. Next, the playbook displays the resulting zone name.
-
Indicate that the value of the
Save the file.
For details about variables and example playbooks in the FreeIPA Ansible collection, see the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/README-dnszone.mdfile and the/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnszonedirectory on the control node.Run the playbook:
ansible-playbook --vault-password-file=password_file -v -i inventory.file dnszone-reverse-from-ip-copy.yml
$ ansible-playbook --vault-password-file=password_file -v -i inventory.file dnszone-reverse-from-ip-copy.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Chapter 4. Managing DNS locations in IdM Copy linkLink copied to clipboard!
Manage Identity Management (IdM) DNS locations to optimize traffic and reduce latency between clients and servers. Configuring these locations ensures that clients discover and prioritize the nearest available services.
4.1. Prerequisites Copy linkLink copied to clipboard!
- You understand the concept of DNS-based service discovery in IdM.
- You understand deployment considerations for DNS locations in IdM.
- You understand the concept of DNS time-to-live (TTL).
4.2. Creating DNS locations using the IdM Web UI Copy linkLink copied to clipboard!
Define new DNS locations through the IdM Web UI to group servers by physical or logical site. This organization helps the environment to direct client requests to local infrastructure, improving response times.
Prerequisites
- Your IdM deployment has integrated DNS.
- You have a permission to create DNS locations in IdM. For example, you are logged in as IdM admin.
Procedure
-
Open the
IPA Servertab. -
Select
Topologysubtab. -
Click
IPA Locationsin the navigation bar. - Click at the top of the locations list.
- Fill in the location name.
- Click the button to save the location.
- Optional: Repeat the steps to add further locations.
4.3. Creating DNS locations using the IdM CLI Copy linkLink copied to clipboard!
Add DNS locations via the command line with the ipa location-add command. This tool quickly registers new geographic or network-based sites within the Identity Management (IdM) database for future server assignment.
Prerequisites
- Your IdM deployment has integrated DNS.
- You have a permission to create DNS locations in IdM. For example, you are logged in as IdM admin.
Procedure
For example, to create a new location
germany, enter:ipa location-add germany
$ ipa location-add germanyCopy to Clipboard Copied! Toggle word wrap Toggle overflow ---------------------------- Added IPA location "germany" ---------------------------- Location name: germany
---------------------------- Added IPA location "germany" ---------------------------- Location name: germanyCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Optional: Repeat the step to add further locations.
4.4. Assigning an IdM server to a DNS location using the IdM Web UI Copy linkLink copied to clipboard!
Associate specific Identity Management (IdM) servers with defined locations using the Topology tab in the IdM Web UI. Setting a service weight during this process further refines how clients distribute their connection attempts.
Prerequisites
- Your IdM deployment has integrated DNS.
- You are logged in as a user with a permission to assign a server to a DNS location, for example the IdM admin user.
-
You have
rootaccess to the host that you want to assign a DNS location to. - You have created the IdM DNS locations to which you want to assign servers.
Procedure
-
Open the
IPA Servertab. -
Select the
Topologysubtab. -
Click
IPA Serversin the navigation. - Click on the IdM server name.
Select a DNS location, and optionally set a service weight:
Assigning a server to a DNS location
- Click .
On the command line (CLI) of the host you assigned in the previous steps the DNS location to, restart the
namedservice:systemctl restart named
[root@idmserver-01 ~]# systemctl restart namedCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Optional: Repeat the steps to assign DNS locations to further IdM servers.
4.5. Assigning an IdM server to a DNS location using the IdM CLI Copy linkLink copied to clipboard!
Use the ipa server-mod command to link a server to a specific DNS location. Restarting the named service afterward activates the new routing logic, ensuring the server advertises itself to the correct local clients.
Prerequisites
- Your IdM deployment has integrated DNS.
- You are logged in as a user with a permission to assign a server to a DNS location, for example the IdM admin user.
-
You have
rootaccess to the host that you want to assign a DNS location to. - You have created the IdM DNS locations to which you want to assign servers.
Procedure
Optional: List all configured DNS locations:
ipa location-find
[root@server ~]# ipa location-findCopy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow Assign the server to the DNS location. For example, to assign the location
germanyto the server idmserver-01.idm.example.com, run:ipa server-mod idmserver-01.idm.example.com --location=germany
# ipa server-mod idmserver-01.idm.example.com --location=germanyCopy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow Restart the
namedservice on the host you assigned in the previous steps the DNS location to:systemctl restart named
# systemctl restart namedCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Optional: Repeat the steps to assign DNS locations to further IdM servers.
4.6. Configuring an IdM client to use IdM servers in the same location Copy linkLink copied to clipboard!
Point clients to a local DNS server via DHCP or manual network configuration. When the client’s primary DNS server resides in its assigned Identity Management (IdM) location, the client prioritizes local IdM services for all authentication and lookup tasks.
IdM servers are assigned to DNS locations as described in Assigning an IdM server to a DNS location using the IdM Web UI. Now you can configure the clients to use a DNS server that is in the same location as the IdM servers:
-
If a
DHCPserver assigns the DNS server IP addresses to the clients, configure theDHCPservice. For further details about assigning a DNS server in yourDHCPservice, see theDHCPservice documentation. -
If your clients do not receive the DNS server IP addresses from a
DHCPserver, manually set the IPs in the client’s network configuration. For further details about configuring the network on Red Hat Enterprise Linux, see the Configuring Network Connection Settings section in the Red Hat Enterprise Linux Networking Guide.
If you configure the client to use a DNS server that is assigned to a different location, the client contacts IdM servers in both locations.
Example 4.1. Different name server entries depending on the location of the client
The following example shows different name server entries in the /etc/resolv.conf file for clients in different locations:
Clients in Prague:
nameserver 10.10.0.1 nameserver 10.10.0.2
nameserver 10.10.0.1
nameserver 10.10.0.2
Clients in Paris:
nameserver 10.50.0.1 nameserver 10.50.0.3
nameserver 10.50.0.1
nameserver 10.50.0.3
Clients in Oslo:
nameserver 10.30.0.1
nameserver 10.30.0.1
Clients in Berlin:
nameserver 10.30.0.1
nameserver 10.30.0.1
If each of the DNS servers is assigned to a location in IdM, the clients use the IdM servers in their location.
Chapter 5. Using Ansible to manage DNS locations in IdM Copy linkLink copied to clipboard!
Define DNS locations using Ansible to enable clients to discover and use geographically nearby Identity Management (IdM) servers for faster responses.
For details about variables and example playbooks in the FreeIPA Ansible collection, see the /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/README-location.md file and the /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/location directory on the control node.
5.1. DNS-based service discovery Copy linkLink copied to clipboard!
Understand how clients use DNS to automatically locate nearby IdM servers, reducing network latency and eliminating manual server configuration.
DNS-based service discovery is a process in which a client uses the DNS protocol to locate servers in a network that offer a specific service, such as LDAP or Kerberos. One typical type of operation is to allow clients to locate authentication servers within the closest network infrastructure, because they provide a higher throughput and lower network latency, lowering overall costs.
The major advantages of service discovery are:
- No need for clients to be explicitly configured with names of nearby servers.
- DNS servers are used as central providers of policy. Clients using the same DNS server have access to the same policy about service providers and their preferred order.
In an Identity Management (IdM) domain, DNS service records (SRV records) exist for LDAP, Kerberos, and other services. For example, the following command queries the DNS server for hosts providing a TCP-based Kerberos service in an IdM DNS domain:
Example 5.1. DNS location independent results
dig -t SRV +short _kerberos._tcp.idm.example.com 0 100 88 idmserver-01.idm.example.com. 0 100 88 idmserver-02.idm.example.com.
$ dig -t SRV +short _kerberos._tcp.idm.example.com
0 100 88 idmserver-01.idm.example.com.
0 100 88 idmserver-02.idm.example.com.
The output contains the following information:
-
0(priority): Priority of the target host. A lower value is preferred. -
100(weight). Specifies a relative weight for entries with the same priority. For further information, see RFC 2782, section 3. -
88(port number): Port number of the service. - Canonical name of the host providing the service.
In the example, the two host names returned have the same priority and weight. In this case, the client uses a random entry from the result list.
When the client is, instead, configured to query a DNS server that is configured in a DNS location, the output differs. For IdM servers that are assigned to a location, tailored values are returned. In the example below, the client is configured to query a DNS server in the location germany:
Example 5.2. DNS location-based results
dig -t SRV +short _kerberos._tcp.idm.example.com _kerberos._tcp.germany._locations.idm.example.com. 0 100 88 idmserver-01.idm.example.com. 50 100 88 idmserver-02.idm.example.com.
$ dig -t SRV +short _kerberos._tcp.idm.example.com
_kerberos._tcp.germany._locations.idm.example.com.
0 100 88 idmserver-01.idm.example.com.
50 100 88 idmserver-02.idm.example.com.
The IdM DNS server automatically returns a DNS alias (CNAME) pointing to a DNS location specific SRV record which prefers local servers. This CNAME record is shown in the first line of the output. In the example, the host idmserver-01.idm.example.com has the lowest priority value and is therefore preferred. The idmserver-02.idm.example.com has a higher priority and thus is used only as backup for cases when the preferred host is unavailable.
5.2. Deployment considerations for DNS locations Copy linkLink copied to clipboard!
Plan your DNS location deployment to ensure clients receive location-specific SRV records and connect to nearby IdM servers.
Identity Management (IdM) can generate location-specific service (SRV) records when using the integrated DNS. Because each IdM DNS server generates location-specific SRV records, you have to install at least one IdM DNS server in each DNS location.
The client’s affinity to a DNS location is only defined by the DNS records received by the client. For this reason, you can combine IdM DNS servers with non-IdM DNS consumer servers and recursors if the clients doing DNS service discovery resolve location-specific records from IdM DNS servers.
In the majority of deployments with mixed IdM and non-IdM DNS services, DNS recursors select the closest IdM DNS server automatically by using round-trip time metrics. Typically, this ensures that clients using non-IdM DNS servers are getting records for the nearest DNS location and thus use the optimal set of IdM servers.
5.3. DNS time to live (TTL) Copy linkLink copied to clipboard!
Review how you can use the DNS TTL value to control how long clients cache records, which is especially important for roaming clients that move between locations.
Clients can cache DNS resource records for an amount of time that is set in the zone’s configuration. Because of this caching, a client might not be able to receive the changes until the time to live (TTL) value expires. The default TTL value in Identity Management (IdM) is 1 day.
If your client computers roam between sites, you should adapt the TTL value for your IdM DNS zone. Set the value to a lower value than the time clients need to roam between sites. This ensures that cached DNS entries on the client expire before they reconnect to another site and thus query the DNS server to refresh location-specific SRV records.
5.4. Using Ansible to ensure an IdM location is present Copy linkLink copied to clipboard!
Create a DNS location in Identity Management (IdM) using Ansible so that clients can discover and use nearby servers for faster authentication.
As a system administrator of Identity Management (IdM), you can configure IdM DNS locations to allow clients to locate authentication servers within the closest network infrastructure.
The example below describes how to ensure that the germany DNS location is present in IdM. As a result, you can assign particular IdM servers to this location so that local IdM clients can use them to reduce server response time.
Prerequisites
On the control node:
- You are using Ansible version 2.15 or later.
-
You have installed the
ansible-freeipapackage. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_passwordand that you have access to a file that stores the password protecting the secret.yml file.
-
The target node, that is the node on which the
freeipa.ansible_freeipamodule is executed, is part of the IdM domain as an IdM client, server or replica. - You understand the deployment considerations for DNS locations.
Procedure
Navigate to the ~/MyPlaybooks/ directory:
cd ~/MyPlaybooks/
$ cd ~/MyPlaybooks/Copy to Clipboard Copied! Toggle word wrap Toggle overflow Make a copy of the
location-present.ymlfile located in the/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/location/directory:cp /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/location/location-present.yml location-present-copy.yml
$ cp /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/location/location-present.yml location-present-copy.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Open the
location-present-copy.ymlAnsible playbook file for editing. Adapt the file by setting the following variables in the
freeipa.ansible_freeipa.ipalocationtask section:-
Adapt the
nameof the task to correspond to your use case. -
Indicate that the value of the
ipaadmin_passwordvariable is defined in the secret.yml Ansible vault file. -
Set the
namevariable to the name of the location.
This is the modified Ansible playbook file for the current example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Adapt the
Save the file.
For details about variables and example playbooks in the FreeIPA Ansible collection, see the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/README-location.mdfile and the/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/locationdirectory on the control node.Run the Ansible playbook. Specify the playbook file, the file storing the password protecting the secret.yml file, and the inventory file:
ansible-playbook --vault-password-file=password_file -v -i inventory location-present-copy.yml
$ ansible-playbook --vault-password-file=password_file -v -i inventory location-present-copy.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.5. Using Ansible to ensure an IdM location is absent Copy linkLink copied to clipboard!
Remove a DNS location from Identity Management (IdM) using Ansible when decommissioning a geographic site or restructuring your topology.
As a system administrator of Identity Management (IdM), you can configure IdM DNS locations to allow clients to locate authentication servers within the closest network infrastructure.
The following procedure describes how to use an Ansible playbook to ensure that a DNS location is absent in IdM. The example describes how to ensure that the germany DNS location is absent in IdM. As a result, you cannot assign particular IdM servers to this location and local IdM clients cannot use them.
Prerequisites
- No IdM server is assigned to the germany DNS location.
You have configured your Ansible control node to meet the following requirements:
- You are using Ansible version 2.15 or later.
-
You have installed the
ansible-freeipapackage. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_passwordand that you have access to a file that stores the password protecting the secret.yml file.
-
The target node, that is the node on which the
freeipa.ansible_freeipamodule is executed, is part of the IdM domain as an IdM client, server or replica. - The example assumes that you have created and configured the ~/MyPlaybooks/ directory as a central location to store copies of sample playbooks.
Procedure
Navigate to the ~/MyPlaybooks/ directory:
cd ~/MyPlaybooks/
$ cd ~/MyPlaybooks/Copy to Clipboard Copied! Toggle word wrap Toggle overflow Make a copy of the
location-absent.ymlfile located in the/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/location/directory:cp /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/location/location-absent.yml location-absent-copy.yml
$ cp /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/location/location-absent.yml location-absent-copy.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Open the
location-absent-copy.ymlAnsible playbook file for editing. Adapt the file by setting the following variables in the
freeipa.ansible_freeipa.ipalocationtask section:-
Adapt the
nameof the task to correspond to your use case. -
Indicate that the value of the
ipaadmin_passwordvariable is defined in the secret.yml Ansible vault file. -
Set the
namevariable to the name of the DNS location. -
Make sure that the
statevariable is set toabsent.
This is the modified Ansible playbook file for the current example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Adapt the
Save the file.
For details about variables and example playbooks in the FreeIPA Ansible collection, see the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/README-location.mdfile and the/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/locationdirectory on the control node.Run the Ansible playbook. Specify the playbook file, the file storing the password protecting the secret.yml file, and the inventory file:
ansible-playbook --vault-password-file=password_file -v -i inventory location-absent-copy.yml
$ ansible-playbook --vault-password-file=password_file -v -i inventory location-absent-copy.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Chapter 6. Managing DNS forwarding in IdM Copy linkLink copied to clipboard!
Configure global forwarders and DNS forward zones using the web UI, CLI, or Ansible to resolve names outside your Identity Management (IdM) domain.
6.1. The two roles of an IdM DNS server Copy linkLink copied to clipboard!
Understand how an Identity Management (IdM) DNS server functions as both an authoritative and recursive DNS server, and how forwarding works.
DNS forwarding affects how a DNS service answers DNS queries. By default, the Berkeley Internet Name Domain (BIND) service integrated with IdM acts as both an authoritative and a recursive DNS server:
- Authoritative DNS server
- When a DNS client queries a name belonging to a DNS zone for which the IdM server is authoritative, BIND replies with data contained in the configured zone. Authoritative data always takes precedence over any other data.
- Recursive DNS server
- When a DNS client queries a name for which the IdM server is not authoritative, BIND attempts to resolve the query using other DNS servers. If forwarders are not defined, BIND asks the root servers on the Internet and uses a recursive resolution algorithm to answer the DNS query.
In some cases, it is not desirable to let BIND contact other DNS servers directly and perform the recursion based on data available on the Internet. You can configure BIND to use another DNS server, a forwarder, to resolve the query.
When you configure BIND to use a forwarder, queries and answers are forwarded back and forth between the IdM server and the forwarder, and the IdM server acts as the DNS cache for non-authoritative data.
6.2. Adding a global forwarder in the IdM Web UI Copy linkLink copied to clipboard!
Configure a global DNS forwarder through the web interface to resolve queries for domains outside your Identity Management (IdM) DNS zones.
Prerequisites
- You are logged in to the IdM WebUI as IdM administrator.
- You know the Internet Protocol (IP) address of the DNS server to forward queries to.
Procedure
In the IdM Web UI, select
Network Services→DNS Global Configuration→DNS.
In the
DNS Global Configurationsection, clickAdd.
Specify the IP address of the DNS server that will receive forwarded DNS queries.
Select the
Forward policy.
-
Click
Saveat the top of the window.
Verification
Select
Network Services→DNS Global Configuration→DNS.
Verify that the global forwarder, with the forward policy you specified, is present and enabled in the IdM Web UI.
6.3. Adding a global forwarder in the CLI Copy linkLink copied to clipboard!
Configure a global DNS forwarder from the command line to resolve queries for domains outside your Identity Management (IdM) DNS zones.
Prerequisites
- You are logged in as IdM administrator.
- You know the Internet Protocol (IP) address of the DNS server to forward queries to.
Procedure
Use the
ipa dnsconfig-modcommand to add a new global forwarder. Specify the IP address of the DNS forwarder with the--forwarderoption.ipa dnsconfig-mod --forwarder=10.10.0.1
[user@server ~]$ ipa dnsconfig-mod --forwarder=10.10.0.1Copy to Clipboard Copied! Toggle word wrap Toggle overflow Server will check DNS forwarder(s). This may take some time, please wait ... Global forwarders: 10.10.0.1 IPA DNS servers: server.example.com
Server will check DNS forwarder(s). This may take some time, please wait ... Global forwarders: 10.10.0.1 IPA DNS servers: server.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
Use the
dnsconfig-showcommand to display global forwarders.ipa dnsconfig-show
[user@server ~]$ ipa dnsconfig-showCopy to Clipboard Copied! Toggle word wrap Toggle overflow Global forwarders: 10.10.0.1 IPA DNS servers: server.example.com
Global forwarders: 10.10.0.1 IPA DNS servers: server.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.4. Adding a DNS Forward Zone in the IdM Web UI Copy linkLink copied to clipboard!
Create a DNS forward zone through the Identity Management (IdM) web interface (Web UI) to forward queries for a specific domain to designated external DNS servers.
Do not use forward zones unless absolutely required. Forward zones are not a standard solution, and using them can lead to unexpected and problematic behavior. If you must use forward zones, limit their use to overriding a global forwarding configuration.
When creating a new DNS zone, Red Hat recommends to always use standard DNS delegation using nameserver (NS) records and to avoid forward zones. In most cases, using a global forwarder is sufficient, and forward zones are not necessary.
Prerequisites
- You are logged in to the IdM WebUI as IdM administrator.
- You know the Internet Protocol (IP) address of the DNS server to forward queries to.
Procedure
In the IdM Web UI, select
Network Services→DNS Forward Zones→DNS.
In the
DNS Forward Zonessection, clickAdd.
In the
Add DNS forward zonewindow, specify the forward zone name.
Click the
Addbutton and specify the IP address of a DNS server to receive the forwarding request. You can specify multiple forwarders per forward zone.
Select the
Forward policy.
-
Click
Addat the bottom of the window to add the new forward zone.
Verification
In the IdM Web UI, select
Network Services→DNS Forward Zones→DNS.
Verify that the forward zone you created, with the forwarders and forward policy you specified, is present and enabled in the IdM Web UI.
6.5. Adding a DNS Forward Zone in the CLI Copy linkLink copied to clipboard!
Create a DNS forward zone from the command line (CLI) to forward queries for a specific domain to designated external DNS servers.
Do not use forward zones unless absolutely required. Forward zones are not a standard solution, and using them can lead to unexpected and problematic behavior. If you must use forward zones, limit their use to overriding a global forwarding configuration.
When creating a new DNS zone, Red Hat recommends to always use standard DNS delegation using nameserver (NS) records and to avoid forward zones. In most cases, using a global forwarder is sufficient, and forward zones are not necessary.
Prerequisites
- You are logged in as IdM administrator.
- You know the Internet Protocol (IP) address of the DNS server to forward queries to.
Procedure
Use the
dnsforwardzone-addcommand to add a new forward zone. Specify at least one forwarder with the--forwarderoption if the forward policy is notnone, and specify the forward policy with the--forward-policyoption.ipa dnsforwardzone-add forward.example.com. --forwarder=10.10.0.14 --forwarder=10.10.1.15 --forward-policy=first
[user@server ~]$ ipa dnsforwardzone-add forward.example.com. --forwarder=10.10.0.14 --forwarder=10.10.1.15 --forward-policy=firstCopy to Clipboard Copied! Toggle word wrap Toggle overflow Zone name: forward.example.com. Zone forwarders: 10.10.0.14, 10.10.1.15 Forward policy: first
Zone name: forward.example.com. Zone forwarders: 10.10.0.14, 10.10.1.15 Forward policy: firstCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
Use the
dnsforwardzone-showcommand to display the DNS forward zone you just created.ipa dnsforwardzone-show forward.example.com.
[user@server ~]$ ipa dnsforwardzone-show forward.example.com.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Zone name: forward.example.com. Zone forwarders: 10.10.0.14, 10.10.1.15 Forward policy: first
Zone name: forward.example.com. Zone forwarders: 10.10.0.14, 10.10.1.15 Forward policy: firstCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.6. Establishing a DNS Global Forwarder in IdM using Ansible Copy linkLink copied to clipboard!
Configure the initial global DNS forwarder in Identity Management (IdM) using Ansible to enable resolution of external domain names.
In the example procedure below, the IdM administrator creates a DNS global forwarder to a DNS server with an Internet Protocol (IP) v4 address of 8.8.6.6 and IPv6 address of 2001:4860:4860::8800 on port 53.
Prerequisites
You have configured your Ansible control node to meet the following requirements:
- You are using Ansible version 2.15 or later.
-
You have installed the
ansible-freeipapackage. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_passwordand that you have access to a file that stores the password protecting the secret.yml file.
-
The target node, that is the node on which the
freeipa.ansible_freeipamodule is executed, is part of the IdM domain as an IdM client, server or replica.
Procedure
Navigate to the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfigdirectory:cd /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfig
$ cd /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow Make a copy of the
set-configuration.ymlAnsible playbook file. For example:cp set-configuration.yml establish-global-forwarder.yml
$ cp set-configuration.yml establish-global-forwarder.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Open the
establish-global-forwarder.ymlfile for editing. Adapt the file by setting the following variables:
-
Change the
namevariable for the playbook toPlaybook to establish a global forwarder in IdM DNS. -
In the
taskssection, change thenameof the task toCreate a DNS global forwarder to 8.8.6.6 and 2001:4860:4860::8800. In the
forwarderssection of thefreeipa.ansible_freeipa.ipadnsconfigportion:-
Change the first
ip_addressvalue to the IPv4 address of the global forwarder:8.8.6.6. -
Change the second
ip_addressvalue to the IPv6 address of the global forwarder:2001:4860:4860::8800. -
Verify the
portvalue is set to53.
-
Change the first
Change the
forward_policytofirst.This the modified Ansible playbook file for the current example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Change the
Save the file.
For details about all variables used in the playbook, see the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/README-dnsconfig.mdfile on the control node.Run the playbook:
ansible-playbook --vault-password-file=password_file -v -i inventory.file establish-global-forwarder.yml
$ ansible-playbook --vault-password-file=password_file -v -i inventory.file establish-global-forwarder.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.7. Ensuring DNS Global Forwarders are disabled in IdM using Ansible Copy linkLink copied to clipboard!
Disable global DNS forwarders using Ansible by setting the forward policy to none, forcing Identity Management (IdM) to use recursive resolution instead.
Prerequisites
You have configured your Ansible control node to meet the following requirements:
- You are using Ansible version 2.15 or later.
-
You have installed the
ansible-freeipapackage. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_passwordand that you have access to a file that stores the password protecting the secret.yml file.
-
The target node, that is the node on which the
freeipa.ansible_freeipamodule is executed, is part of the IdM domain as an IdM client, server or replica.
Procedure
Navigate to the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfigdirectory:cd /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfig
$ cd /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow Verify the contents of the
disable-global-forwarders.ymlAnsible playbook file which is already configured to disable all DNS global forwarders. For example:cat disable-global-forwarders.yml
$ cat disable-global-forwarders.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow For details about all variables used in the playbook, see the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/README-dnsconfig.mdfile on the control node.Run the playbook:
ansible-playbook --vault-password-file=password_file -v -i inventory.file disable-global-forwarders.yml
$ ansible-playbook --vault-password-file=password_file -v -i inventory.file disable-global-forwarders.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.8. Ensuring the presence of a DNS Forward Zone in IdM using Ansible Copy linkLink copied to clipboard!
Create a DNS forward zone in Identity Management (IdM) using Ansible to direct queries for a specific domain to designated external DNS servers.
In the example procedure below, the IdM administrator ensures that a DNS forward zone for example.com is configured to forward queries to 8.8.8.8.
Prerequisites
You have configured your Ansible control node to meet the following requirements:
- You are using Ansible version 2.15 or later.
-
You have installed the
ansible-freeipapackage. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_passwordand that you have access to a file that stores the password protecting the secret.yml file.
-
The target node, that is the node on which the
freeipa.ansible_freeipamodule is executed, is part of the IdM domain as an IdM client, server or replica.
Procedure
Navigate to the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfigdirectory:cd /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfig
$ cd /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow Make a copy of the
forwarders-absent.ymlAnsible playbook file. For example:cp forwarders-absent.yml ensure-presence-forwardzone.yml
$ cp forwarders-absent.yml ensure-presence-forwardzone.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Open the
ensure-presence-forwardzone.ymlfile for editing. Adapt the file by setting the following variables:
-
Change the
namevariable for the playbook toPlaybook to ensure the presence of a dnsforwardzone in IdM DNS. -
In the
taskssection, change thenameof the task toEnsure presence of a dnsforwardzone for example.com to 8.8.8.8. -
In the
taskssection, change thefreeipa.ansible_freeipa.ipadnsconfigheading tofreeipa.ansible_freeipa.ipadnsforwardzone. In the
freeipa.ansible_freeipa.ipadnsforwardzonesection:-
Indicate that the value of the
ipaadmin_passwordvariable is defined in the secret.yml Ansible vault file. -
Add the
namevariable and set it toexample.com. In the
forwarderssection:-
Remove the
ip_addressandportlines. Add the IP address of the DNS server to receive forwarded requests by specifying it after a dash:
- 8.8.8.8
- 8.8.8.8Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
Remove the
-
Add the
forwardpolicyvariable and set it tofirst. -
Add the
skip_overlap_checkvariable and set it totrue. -
Change the
statevariable topresent.
This the modified Ansible playbook file for the current example:
-
Indicate that the value of the
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Change the
Save the file.
For details about all variables used in the playbook, see the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/README-dnsforwardzone.mdfile on the control node.Run the playbook:
ansible-playbook --vault-password-file=password_file -v -i inventory ensure-presence-forwardzone.yml
$ ansible-playbook --vault-password-file=password_file -v -i inventory ensure-presence-forwardzone.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.9. Ensuring a DNS Forward Zone has multiple forwarders in IdM using Ansible Copy linkLink copied to clipboard!
Configure multiple forwarders for a DNS forward zone using Ansible to provide redundancy when resolving queries for external domains.
In the example below, you ensure the DNS forward zone for example.com is forwarding to 8.8.8.8 and 4.4.4.4.
Prerequisites
You have configured your Ansible control node to meet the following requirements:
- You are using Ansible version 2.15 or later.
-
You have installed the
ansible-freeipapackage. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_passwordand that you have access to a file that stores the password protecting the secret.yml file.
-
The target node, that is the node on which the
freeipa.ansible_freeipamodule is executed, is part of the IdM domain as an IdM client, server or replica.
Procedure
Navigate to the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfigdirectory:cd /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfig
$ cd /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow Make a copy of the
forwarders-absent.ymlAnsible playbook file. For example:cp forwarders-absent.yml ensure-presence-multiple-forwarders.yml
$ cp forwarders-absent.yml ensure-presence-multiple-forwarders.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Open the
ensure-presence-multiple-forwarders.ymlfile for editing. Adapt the file by setting the following variables:
-
Change the
namevariable for the playbook toPlaybook to ensure the presence of multiple forwarders in a dnsforwardzone in IdM DNS. -
In the
taskssection, change thenameof the task toEnsure presence of 8.8.8.8 and 4.4.4.4 forwarders in dnsforwardzone for example.com. -
In the
taskssection, change thefreeipa.ansible_freeipa.ipadnsconfigheading tofreeipa.ansible_freeipa.ipadnsforwardzone. In the
freeipa.ansible_freeipa.ipadnsforwardzonesection:-
Indicate that the value of the
ipaadmin_passwordvariable is defined in the secret.yml Ansible vault file. -
Add the
namevariable and set it toexample.com. In the
forwarderssection:-
Remove the
ip_addressandportlines. Add the IP address of the DNS servers you want to ensure are present, preceded by a dash:
- 8.8.8.8 - 4.4.4.4
- 8.8.8.8 - 4.4.4.4Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
Remove the
- Change the state variable to present.
This the modified Ansible playbook file for the current example:
-
Indicate that the value of the
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Change the
Save the file.
For details about all variables used in the playbook, see the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/README-dnsforwardzone.mdfile on the control node.Run the playbook:
ansible-playbook --vault-password-file=password_file -v -i inventory.file ensure-presence-multiple-forwarders.yml
$ ansible-playbook --vault-password-file=password_file -v -i inventory.file ensure-presence-multiple-forwarders.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.10. Ensuring a DNS Forward Zone is disabled in IdM using Ansible Copy linkLink copied to clipboard!
Disable a DNS forward zone using Ansible to stop forwarding queries for a specific domain without deleting the zone configuration.
In the example below, you ensure the DNS forward zone for example.com is disabled.
Prerequisites
You have configured your Ansible control node to meet the following requirements:
- You are using Ansible version 2.15 or later.
-
You have installed the
ansible-freeipapackage. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_passwordand that you have access to a file that stores the password protecting the secret.yml file.
-
The target node, that is the node on which the
freeipa.ansible_freeipamodule is executed, is part of the IdM domain as an IdM client, server or replica.
Procedure
Navigate to the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfigdirectory:cd /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfig
$ cd /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow Make a copy of the
forwarders-absent.ymlAnsible playbook file. For example:cp forwarders-absent.yml ensure-disabled-forwardzone.yml
$ cp forwarders-absent.yml ensure-disabled-forwardzone.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Open the
ensure-disabled-forwardzone.ymlfile for editing. Adapt the file by setting the following variables:
-
Change the
namevariable for the playbook toPlaybook to ensure a dnsforwardzone is disabled in IdM DNS. -
In the
taskssection, change thenameof the task toEnsure a dnsforwardzone for example.com is disabled. -
In the
taskssection, change thefreeipa.ansible_freeipa.ipadnsconfigheading tofreeipa.ansible_freeipa.ipadnsforwardzone. In the
freeipa.ansible_freeipa.ipadnsforwardzonesection:-
Indicate that the value of the
ipaadmin_passwordvariable is defined in the secret.yml Ansible vault file. -
Add the
namevariable and set it toexample.com. -
Remove the entire
forwarderssection. -
Change the
statevariable todisabled.
This the modified Ansible playbook file for the current example:
-
Indicate that the value of the
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Change the
Save the file.
For details about all variables used in the playbook, see the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/README-dnsforwardzone.mdfile on the control node.Run the playbook:
ansible-playbook --vault-password-file=password_file -v -i inventory.file ensure-disabled-forwardzone.yml
$ ansible-playbook --vault-password-file=password_file -v -i inventory.file ensure-disabled-forwardzone.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.11. Ensuring the absence of a DNS Forward Zone in IdM using Ansible Copy linkLink copied to clipboard!
Remove a DNS forward zone from Identity Management (IdM) using Ansible when you no longer need to forward queries for a specific domain.
In the example procedure below, the IdM administrator ensures the absence of a DNS forward zone for example.com.
Prerequisites
You have configured your Ansible control node to meet the following requirements:
- You are using Ansible version 2.15 or later.
-
You have installed the
ansible-freeipapackage. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_passwordand that you have access to a file that stores the password protecting the secret.yml file.
-
The target node, that is the node on which the
freeipa.ansible_freeipamodule is executed, is part of the IdM domain as an IdM client, server or replica.
Procedure
Navigate to the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfigdirectory:cd /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfig
$ cd /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow Make a copy of the
forwarders-absent.ymlAnsible playbook file. For example:cp forwarders-absent.yml ensure-absence-forwardzone.yml
$ cp forwarders-absent.yml ensure-absence-forwardzone.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Open the
ensure-absence-forwardzone.ymlfile for editing. Adapt the file by setting the following variables:
-
Change the
namevariable for the playbook toPlaybook to ensure the absence of a dnsforwardzone in IdM DNS. -
In the
taskssection, change thenameof the task toEnsure the absence of a dnsforwardzone for example.com. -
In the
taskssection, change thefreeipa.ansible_freeipa.ipadnsconfigheading tofreeipa.ansible_freeipa.ipadnsforwardzone. In the
freeipa.ansible_freeipa.ipadnsforwardzonesection:-
Indicate that the value of the
ipaadmin_passwordvariable is defined in the secret.yml Ansible vault file. -
Add the
namevariable and set it toexample.com. -
Remove the entire
forwarderssection. -
Leave the
statevariable asabsent.
This the modified Ansible playbook file for the current example:
-
Indicate that the value of the
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Change the
Save the file.
For details about all variables used in the playbook, see the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/README-dnsforwardzone.mdfile on the control node.Run the playbook:
ansible-playbook --vault-password-file=password_file -v -i inventory.file ensure-absence-forwardzone.yml
$ ansible-playbook --vault-password-file=password_file -v -i inventory.file ensure-absence-forwardzone.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Chapter 7. Managing DNS records in IdM Copy linkLink copied to clipboard!
Maintain the accuracy of your network’s name resolution by managing DNS records within Identity Management (IdM). You can add, update, and remove various record types to reflect changes in the infrastructure and ensure seamless service discovery.
7.1. Prerequisites Copy linkLink copied to clipboard!
Your IdM deployment contains an integrated DNS server. For information how to install IdM with integrated DNS, see one of the following links:
- You understand what types of DNS records exist in IdM.
- You understand what options are available when adding, modifying and deleting the most common DNS resource record types in IdM.
7.2. Adding DNS resource records in the IdM Web UI Copy linkLink copied to clipboard!
Expand your DNS zone by adding new resource records through the IdM Web UI. This graphical interface simplifies the process of defining host addresses, service locations, and other critical network data.
Prerequisites
- The DNS zone to which you want to add a DNS record exists and is managed by IdM. For more information about creating a DNS zone in IdM DNS, see Managing DNS zones in IdM.
- You are logged in as IdM administrator.
Procedure
-
In the IdM Web UI, click
Network Services→DNS→DNS Zones. - Click the DNS zone to which you want to add a DNS record.
In the
DNS Resource Recordssection, click to add a new record.Adding a New DNS Resource Record
Select the type of record to create and fill out the other fields as required.
Defining a New DNS Resource Record
- Click to confirm the new record.
7.3. Adding DNS resource records from the IdM CLI Copy linkLink copied to clipboard!
Use the ipa dnsrecord-add command to insert new entries into a specific DNS zone via the command line. This method provides you with the precise control over record parameters and supports automation for bulk updates.
Prerequisites
- The DNS zone to which you want to add a DNS records exists. For more information about creating a DNS zone in IdM DNS, see Managing DNS zones in IdM.
- You are logged in as IdM administrator.
Procedure
To add a DNS resource record, use the
ipa dnsrecord-addcommand. The command follows this syntax:ipa dnsrecord-add zone_name record_name --record_type_option=data
$ ipa dnsrecord-add zone_name record_name --record_type_option=dataCopy to Clipboard Copied! Toggle word wrap Toggle overflow In the command above:
- The zone_name is the name of the DNS zone to which the record is being added.
- The record_name is an identifier for the new DNS resource record.
For example, to add an A type DNS record of host1 to the idm.example.com zone, enter:
ipa dnsrecord-add idm.example.com host1 --a-rec=192.168.122.123
$ ipa dnsrecord-add idm.example.com host1 --a-rec=192.168.122.123Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.4. Deleting DNS records in the IdM Web UI Copy linkLink copied to clipboard!
Remove specific record types from an existing resource entry by using the IdM Web UI. This focused deletion maintains the overall resource identifier while stripping away individual data points that are no longer valid.
Prerequisites
- You are logged in as IdM administrator.
Procedure
-
In the IdM Web UI, click
Network Services→DNS→DNS Zones. - Click the zone from which you want to delete a DNS record, for example example.com..
In the
DNS Resource Recordssection, click the name of the resource record.Selecting a DNS Resource Record
- Select the check box by the name of the record type to delete.
Click
Delete.Deleting a DNS Resource Record
The selected record type is now deleted. The other configuration of the resource record is left intact.
7.5. Deleting an entire DNS record in the IdM Web UI Copy linkLink copied to clipboard!
Purge all data associated with a specific resource by deleting the entire record entry in the IdM Web UI. This action removes the host or service identifier and all its related record types from the DNS zone in one step.
Prerequisites
- You are logged in as IdM administrator.
Procedure
-
In the IdM Web UI, click
Network Services→DNS→DNS Zones. - Click the zone from which you want to delete a DNS record, for example zone.example.com..
-
In the
DNS Resource Recordssection, select the check box of the resource record to delete. Click .
Deleting an Entire Resource Record
The entire resource record is now deleted.
7.6. Deleting DNS records in the IdM CLI Copy linkLink copied to clipboard!
Execute the ipa dnsrecord-del command to remove specific records or use the --del-all option to wipe all entries associated with a name. This command provides an efficient way to clean up stale DNS data directly from the IdM CLI.
Prerequisites
- You are logged in as IdM administrator.
Procedure
To remove records from a zone, use the
ipa dnsrecord-delcommand and add the--recordType-recoption together with the record value. For example, to remove an A type record:ipa dnsrecord-del example.com www --a-rec 192.0.2.1
$ ipa dnsrecord-del example.com www --a-rec 192.0.2.1Copy to Clipboard Copied! Toggle word wrap Toggle overflow If you run
ipa dnsrecord-delwithout any options, the command prompts for information about the record to delete. Note that passing the--del-alloption with the command removes all associated records for the zone.
Chapter 8. Using Ansible to manage DNS records in IdM Copy linkLink copied to clipboard!
Add, modify, and delete DNS records in Identity Management (IdM) zones using Ansible to automate DNS management across your infrastructure.
8.1. DNS records in IdM Copy linkLink copied to clipboard!
Understand the DNS record types supported by IdM, including A, AAAA, SRV, and PTR records commonly used for host resolution and service discovery.
Identity Management (IdM) supports many different DNS record types. The following four are used most frequently:
- A
This is a basic map for a host name and an IPv4 address. The record name of an A record is a host name, such as
www. TheIP Addressvalue of an A record is an IPv4 address, such as192.0.2.1.For more information about A records, see RFC 1035.
- AAAA
This is a basic map for a host name and an IPv6 address. The record name of an AAAA record is a host name, such as
www. TheIP Addressvalue is an IPv6 address, such as2001:DB8::1111.For more information about AAAA records, see RFC 3596.
- SRV
Service (SRV) resource records map service names to the DNS name of the server that is providing that particular service. For example, this record type can map a service like an LDAP directory to the server which manages it.
The record name of an SRV record has the format
_service._protocol, such as_ldap._tcp. The configuration options for SRV records include priority, weight, port number, and host name for the target service.For more information about SRV records, see RFC 2782.
- PTR
A pointer record (PTR) adds a reverse DNS record, which maps an IP address to a domain name.
NoteAll reverse DNS lookups for IPv4 addresses use reverse entries that are defined in the
in-addr.arpa.domain. The reverse address, in human-readable form, is the exact reverse of the regular IP address, with thein-addr.arpa.domain appended to it. For example, for the network address192.0.2.0/24, the reverse zone is2.0.192.in-addr.arpa.The record name of a PTR must be in the standard format specified in RFC 1035, extended in RFC 2317, and RFC 3596. The host name value must be a canonical host name of the host for which you want to create the record.
NoteReverse zones can also be configured for IPv6 addresses, with zones in the
.ip6.arpa.domain. For more information about IPv6 reverse zones, see RFC 3596.
When adding DNS resource records, note that many of the records require different data. For example, a CNAME record requires a host name, while an A record requires an IP address. In the IdM Web UI, the fields in the form for adding a new record are updated automatically to reflect what data is required for the currently selected type of record.
8.2. Common ipa dnsrecord-* options Copy linkLink copied to clipboard!
Review the command-line options available for managing A, AAAA, SRV, and PTR records in IdM DNS zones.
In Bash, you can define multiple entries by listing the values in a comma-separated list inside curly braces, such as --option={val1,val2,val3}.
| Option | Description |
|---|---|
|
| Sets the time to live for the record. |
|
| Parses the raw DNS records and returns them in a structured format. |
| Option | Description | Examples |
|---|---|---|
|
| Passes a single A record or a list of A records. |
|
| Can create a wildcard A record with a given IP address. |
| |
|
|
Gives the IP address for the record. When creating a record, the option to specify the |
|
[a]
The example creates a wildcard A record with the IP address of 192.0.2.123.
| ||
| Option | Description | Example |
|---|---|---|
|
| Passes a single AAAA (IPv6) record or a list of AAAA records. |
|
|
|
Gives the IPv6 address for the record. When creating a record, the option to specify the |
|
| Option | Description | Example |
|---|---|---|
|
|
Passes a single PTR record or a list of PTR records. When adding the reverse DNS record, the zone name used with the |
|
|
| ||
|
| Gives the host name for the record. |
| Option | Description | Example |
|---|---|---|
|
|
Passes a single SRV record or a list of SRV records. In the examples on the right, _ldap._tcp defines the service type and the connection protocol for the SRV record. The |
|
|
| ||
|
| Sets the priority of the record. There can be multiple SRV records for a service type. The priority (0 - 65535) sets the rank of the record; the lower the number, the higher the priority. A service has to use the record with the highest priority first. |
|
|
| Sets the weight of the record. This helps determine the order of SRV records with the same priority. The set weights should add up to 100, representing the probability (in percentages) that a particular record is used. |
|
|
| Gives the port for the service on the target host. |
|
|
| Gives the domain name of the target host. This can be a single period (.) if the service is not available in the domain. |
8.3. Ensuring the presence of A and AAAA DNS records in IdM using Ansible Copy linkLink copied to clipboard!
Create A and AAAA records to map hostnames to IPv4 and IPv6 addresses, enabling name resolution for hosts in your IdM domain.
The example below ensures the presence of A and AAAA records for host1 in the idm.example.com DNS zone.
Prerequisites
You have configured your Ansible control node to meet the following requirements:
- You are using Ansible version 2.15 or later.
-
You have installed the
ansible-freeipapackage. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_passwordand that you have access to a file that stores the password protecting the secret.yml file.
-
The target node, that is the node on which the
freeipa.ansible_freeipamodule is executed, is part of the IdM domain as an IdM client, server or replica. - The idm.example.com zone exists and is managed by IdM DNS. For more information about adding a primary DNS zone in IdM DNS, see Using Ansible playbooks to manage IdM DNS zones.
Procedure
Navigate to the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsrecorddirectory:cd /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsrecord
$ cd /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsrecordCopy to Clipboard Copied! Toggle word wrap Toggle overflow Make a copy of the ensure-A-and-AAAA-records-are-present.yml Ansible playbook file. For example:
cp ensure-A-and-AAAA-records-are-present.yml ensure-A-and-AAAA-records-are-present-copy.yml
$ cp ensure-A-and-AAAA-records-are-present.yml ensure-A-and-AAAA-records-are-present-copy.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Open the ensure-A-and-AAAA-records-are-present-copy.yml file for editing.
Adapt the file by setting the following variables in the
freeipa.ansible_freeipa.ipadnsrecordtask section:-
Indicate that the value of the
ipaadmin_passwordvariable is defined in the secret.yml Ansible vault file. -
Set the
zone_namevariable to idm.example.com. -
In the
recordsvariable, set thenamevariable to host1, and thea_ip_addressvariable to 192.168.122.123. In the
recordsvariable, set thenamevariable to host1, and theaaaa_ip_addressvariable to ::1.This is the modified Ansible playbook file for the current example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Indicate that the value of the
Save the file.
For details about variables and example playbooks in the FreeIPA Ansible collection, see the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/README-dnsrecord.mdfile and the/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsrecorddirectory on the control node.Run the playbook:
ansible-playbook --vault-password-file=password_file -v -i inventory.file ensure-A-and-AAAA-records-are-present-copy.yml
$ ansible-playbook --vault-password-file=password_file -v -i inventory.file ensure-A-and-AAAA-records-are-present-copy.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.4. Ensuring the presence of A and PTR DNS records in IdM using Ansible Copy linkLink copied to clipboard!
Create matching A and PTR records to enable both forward and reverse DNS lookups for a host in a single Ansible task.
The example below ensures the presence of A and PTR records for host1 with an IP address of 192.168.122.45 in the idm.example.com zone.
Prerequisites
You have configured your Ansible control node to meet the following requirements:
- You are using Ansible version 2.15 or later.
-
You have installed the
ansible-freeipapackage. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_passwordand that you have access to a file that stores the password protecting the secret.yml file.
-
The target node, that is the node on which the
freeipa.ansible_freeipamodule is executed, is part of the IdM domain as an IdM client, server or replica. - The idm.example.com DNS zone exists and is managed by IdM DNS. For more information about adding a primary DNS zone in IdM DNS, see Using Ansible playbooks to manage IdM DNS zones.
Procedure
Navigate to the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsrecorddirectory:cd /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsrecord
$ cd /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsrecordCopy to Clipboard Copied! Toggle word wrap Toggle overflow Make a copy of the ensure-dnsrecord-with-reverse-is-present.yml Ansible playbook file. For example:
cp ensure-dnsrecord-with-reverse-is-present.yml ensure-dnsrecord-with-reverse-is-present-copy.yml
$ cp ensure-dnsrecord-with-reverse-is-present.yml ensure-dnsrecord-with-reverse-is-present-copy.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Open the ensure-dnsrecord-with-reverse-is-present-copy.yml file for editing.
Adapt the file by setting the following variables in the
freeipa.ansible_freeipa.ipadnsrecordtask section:-
Indicate that the value of the
ipaadmin_passwordvariable is defined in the secret.yml Ansible vault file. -
Set the
namevariable to host1. -
Set the
zone_namevariable to idm.example.com. -
Set the
ip_addressvariable to 192.168.122.45. Set the
create_reversevariable to true.This is the modified Ansible playbook file for the current example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Indicate that the value of the
Save the file.
For details about variables and example playbooks in the FreeIPA Ansible collection, see the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/README-dnsrecord.mdfile and the/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsrecorddirectory on the control node.Run the playbook:
ansible-playbook --vault-password-file=password_file -v -i inventory.file ensure-dnsrecord-with-reverse-is-present-copy.yml
$ ansible-playbook --vault-password-file=password_file -v -i inventory.file ensure-dnsrecord-with-reverse-is-present-copy.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.5. Ensuring the presence of multiple DNS records in IdM using Ansible Copy linkLink copied to clipboard!
Add multiple IP addresses to a single DNS record for hosts with multiple network interfaces or for load-balancing purposes.
Follow this procedure to use an Ansible playbook to ensure that multiple values are associated with a particular IdM DNS record. In the example used in the procedure below, an IdM administrator ensures the presence of multiple A records for host1 in the idm.example.com DNS zone.
Prerequisites
You have configured your Ansible control node to meet the following requirements:
- You are using Ansible version 2.15 or later.
-
You have installed the
ansible-freeipapackage. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_passwordand that you have access to a file that stores the password protecting the secret.yml file.
-
The target node, that is the node on which the
freeipa.ansible_freeipamodule is executed, is part of the IdM domain as an IdM client, server or replica. - The idm.example.com zone exists and is managed by IdM DNS. For more information about adding a primary DNS zone in IdM DNS, see Using Ansible playbooks to manage IdM DNS zones.
Procedure
Navigate to the ~/MyPlaybooks/ directory:
cd ~/MyPlaybooks/
$ cd ~/MyPlaybooks/Copy to Clipboard Copied! Toggle word wrap Toggle overflow Make a copy of the ensure-presence-multiple-records.yml Ansible playbook file. For example:
cp /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsrecord/ensure-presence-multiple-records.yml ensure-presence-multiple-records-copy.yml
$ cp /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsrecord/ensure-presence-multiple-records.yml ensure-presence-multiple-records-copy.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Open the ensure-presence-multiple-records-copy.yml file for editing.
Adapt the file by setting the following variables in the
freeipa.ansible_freeipa.ipadnsrecordtask section:-
Indicate that the value of the
ipaadmin_passwordvariable is defined in the secret.yml Ansible vault file. -
In the
recordssection, set thenamevariable to host1. -
In the
recordssection, set thezone_namevariable to idm.example.com. -
In the
recordssection, set thea_recvariable to 192.168.122.112 and to 192.168.122.122. Define a second record in the
recordssection:-
Set the
namevariable to host1. -
Set the
zone_namevariable to idm.example.com. -
Set the
aaaa_recvariable to ::1.
This is the modified Ansible playbook file for the current example:
-
Set the
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Indicate that the value of the
Save the file.
For details about variables and example playbooks in the FreeIPA Ansible collection, see the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/README-dnsrecord.mdfile and the/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsrecorddirectory on the control node.Run the playbook:
ansible-playbook --vault-password-file=password_file -v -i inventory ensure-presence-multiple-records-copy.yml
$ ansible-playbook --vault-password-file=password_file -v -i inventory ensure-presence-multiple-records-copy.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.6. Ensuring the presence of multiple CNAME records in IdM using Ansible Copy linkLink copied to clipboard!
Create CNAME alias records to provide multiple names for the same host, useful when a server hosts multiple services.
A Canonical Name record (CNAME record) is a type of resource record in the Domain Name System (DNS) that maps one domain name, an alias, to another name, the canonical name.
You may find CNAME records useful when running multiple services from a single IP address: for example, an FTP service and a web service, each running on a different port.
In the example below, host03 is both an HTTP server and an FTP server. You ensure the presence of the www and ftp CNAME records for the host03 A record in the idm.example.com zone.
Prerequisites
You have configured your Ansible control node to meet the following requirements:
- You are using Ansible version 2.15 or later.
-
You have installed the
ansible-freeipapackage. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_passwordand that you have access to a file that stores the password protecting the secret.yml file.
-
The target node, that is the node on which the
freeipa.ansible_freeipamodule is executed, is part of the IdM domain as an IdM client, server or replica. - The idm.example.com zone exists and is managed by IdM DNS. For more information about adding a primary DNS zone in IdM DNS, see Using Ansible playbooks to manage IdM DNS zones.
- The host03 A record exists in the idm.example.com zone.
Procedure
Navigate to the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsrecorddirectory:cd /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsrecord
$ cd /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsrecordCopy to Clipboard Copied! Toggle word wrap Toggle overflow Make a copy of the ensure-CNAME-record-is-present.yml Ansible playbook file. For example:
cp ensure-CNAME-record-is-present.yml ensure-CNAME-record-is-present-copy.yml
$ cp ensure-CNAME-record-is-present.yml ensure-CNAME-record-is-present-copy.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Open the ensure-CNAME-record-is-present-copy.yml file for editing.
Adapt the file by setting the following variables in the
freeipa.ansible_freeipa.ipadnsrecordtask section:-
Optional: Adapt the description provided by the
nameof the play. -
Indicate that the value of the
ipaadmin_passwordvariable is defined in the secret.yml Ansible vault file. -
Set the
zone_namevariable to idm.example.com. In the
recordsvariable section, set the following variables and values:-
Set the
namevariable to www. -
Set the
cname_hostnamevariable to host03. -
Set the
namevariable to ftp. -
Set the
cname_hostnamevariable to host03.
This is the modified Ansible playbook file for the current example:
-
Set the
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Optional: Adapt the description provided by the
Save the file.
For details about variables and example playbooks in the FreeIPA Ansible collection, see the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/README-dnsrecord.mdfile and the/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsrecorddirectory on the control node.Run the playbook:
ansible-playbook --vault-password-file=password_file -v -i inventory.file ensure-CNAME-record-is-present.yml
$ ansible-playbook --vault-password-file=password_file -v -i inventory.file ensure-CNAME-record-is-present.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.7. Ensuring the presence of an SRV record in IdM using Ansible Copy linkLink copied to clipboard!
Create SRV records to advertise service locations, enabling clients to discover services by querying DNS for hostname, port, and priority.
A DNS service (SRV) record defines the hostname, port number, transport protocol, priority and weight of a service available in a domain. In Identity Management (IdM), you can use SRV records to locate IdM servers and replicas.
The example below ensures the presence of the _kerberos._udp.idm.example.com SRV record with the value of 10 50 88 idm.example.com. This sets the following values:
- It sets the priority of the service to 10.
- It sets the weight of the service to 50.
- It sets the port to be used by the service to 88.
Prerequisites
You have configured your Ansible control node to meet the following requirements:
- You are using Ansible version 2.15 or later.
-
You have installed the
ansible-freeipapackage. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_passwordand that you have access to a file that stores the password protecting the secret.yml file.
-
The target node, that is the node on which the
freeipa.ansible_freeipamodule is executed, is part of the IdM domain as an IdM client, server or replica. - The idm.example.com zone exists and is managed by IdM DNS. For more information about adding a primary DNS zone in IdM DNS, see Using Ansible playbooks to manage IdM DNS zones.
Procedure
Navigate to the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsrecorddirectory:cd /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsrecord
$ cd /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsrecordCopy to Clipboard Copied! Toggle word wrap Toggle overflow Make a copy of the ensure-SRV-record-is-present.yml Ansible playbook file. For example:
cp ensure-SRV-record-is-present.yml ensure-SRV-record-is-present-copy.yml
$ cp ensure-SRV-record-is-present.yml ensure-SRV-record-is-present-copy.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Open the ensure-SRV-record-is-present-copy.yml file for editing.
Adapt the file by setting the following variables in the
freeipa.ansible_freeipa.ipadnsrecordtask section:-
Indicate that the value of the
ipaadmin_passwordvariable is defined in the secret.yml Ansible vault file. -
Set the
namevariable to _kerberos._udp.idm.example.com. -
Set the
srv_recvariable to '10 50 88 idm.example.com'. Set the
zone_namevariable to idm.example.com.This the modified Ansible playbook file for the current example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Indicate that the value of the
Save the file.
For details about variables and example playbooks in the FreeIPA Ansible collection, see the
/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/README-dnsrecord.mdfile and the/usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/dnsrecorddirectory on the control node.Run the playbook:
ansible-playbook --vault-password-file=password_file -v -i inventory.file ensure-SRV-record-is-present.yml
$ ansible-playbook --vault-password-file=password_file -v -i inventory.file ensure-SRV-record-is-present.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Chapter 9. Using canonicalized DNS host names in IdM Copy linkLink copied to clipboard!
Identity Management (IdM) disables DNS canonicalization by default to prevent attackers from redirecting short-name queries to compromised hosts. By enabling this feature, clients can resolve short host names to their canonical forms during Kerberos authentication.
For example, if an attacker controls the DNS server and a host in the domain, the attacker can cause the short host name, such as demo, to resolve to a compromised host, such as malicious.example.com. In this case, the user connects to a different server than expected.
This procedure describes how to use canonicalized host names on IdM clients.
9.1. Adding an alias to a host principal Copy linkLink copied to clipboard!
Manually add service principal aliases to allow users to access hosts using short names. This method provides a secure alternative to global canonicalization by explicitly linking a short name, like demo, to the full host principal in the Kerberos database.
By default, Identity Management (IdM) clients enrolled by using the ipa-client-install command do not allow to use short host names in service principals. For example, users can use only host/demo.example.com@EXAMPLE.COM instead of host/demo@EXAMPLE.COM when accessing a service.
Learn how to add an alias to a Kerberos principal. Note that you can alternatively enable canonicalization of host names in the /etc/krb5.conf file. For details, see Enabling canonicalization of host names in service principals on clients.
Prerequisites
- The IdM client is installed.
- The host name is unique in the network.
Procedure
Authenticate to IdM as the
adminuser:kinit admin
$ kinit adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow Add the alias to the host principal. For example, to add the
demoalias to thedemo.examle.comhost principal:ipa host-add-principal demo.example.com --principal=demo
$ ipa host-add-principal demo.example.com --principal=demoCopy to Clipboard Copied! Toggle word wrap Toggle overflow
9.2. Enabling canonicalization of host names in service principals on clients Copy linkLink copied to clipboard!
Modify the /etc/krb5.conf file to permit the client to resolve host names via DNS before requesting service tickets. Setting the dns_canonicalize_hostname parameter to true automates name resolution but requires a trusted DNS environment.
- NOTE
If you use host principal aliases, as described in Adding an alias to a host principal, you do not need to enable canonicalization.
Prerequisites
- The Identity Management (IdM) client is installed.
-
You are logged in to the IdM client as the
rootuser. - The host name is unique in the network.
Procedure
Set the
dns_canonicalize_hostnameparameter in the[libdefaults]section in the/etc/krb5.conffile tofalse:[libdefaults] ... dns_canonicalize_hostname = true
[libdefaults] ... dns_canonicalize_hostname = trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
9.3. Options for using host names with DNS host name canonicalization enabled Copy linkLink copied to clipboard!
Choose between using fully qualified domain names (FQDN) or relying on Active Directory NetBIOS compatibility when canonicalization is active. These options determine how the client requests service principals across different IdM and AD environments.
If you set dns_canonicalize_hostname = true in the /etc/krb5.conf file as explained in Enabling canonicalization of host names in service principals on clients, you have the following options when you use a host name in a service principal:
-
In Identity Management (IdM) environments, you can use the full host name in a service principal, such as
host/demo.example.com@EXAMPLE.COM. - In environments without IdM, but if the RHEL host as a member of an Active Directory (AD) domain, no further considerations are required, because AD domain controllers (DC) automatically create service principals for NetBIOS names of the machines enrolled into AD.
Chapter 10. Customizing BIND logging Copy linkLink copied to clipboard!
Enhance system visibility and security by tailoring how the BIND service records activity. By customizing logging configurations, you can track DNS queries and updates more effectively across the Identity Management (IdM) environment.
10.1. Customizing the BIND log path Copy linkLink copied to clipboard!
Direct BIND output to a specific location by defining custom logging channels in the ipa-logging-ext.conf file. This configuration controls the log file’s destination, rotation size, and the specific categories of information the server records.
Procedure
Open the
ipa-logging-ext.conffile in the/etc/named/directory and add or modify a logging channel with your file path:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Restart the BIND server:
systemctl restart named
# systemctl restart namedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
10.2. Extending SELinux policy for BIND custom logging Copy linkLink copied to clipboard!
Grant the BIND service permission to write to custom directories by updating the SELinux policy. Assigning the named_log_t context ensures the security framework permits file creation and modification in non-standard paths.
Procedure
Create a log directory:
mkdir -p /var/log/named
# mkdir -p /var/log/namedCopy to Clipboard Copied! Toggle word wrap Toggle overflow chown named:named /var/log/named
# chown named:named /var/log/namedCopy to Clipboard Copied! Toggle word wrap Toggle overflow chmod 750 /var/log/named
# chmod 750 /var/log/namedCopy to Clipboard Copied! Toggle word wrap Toggle overflow Assign the
named_log_tSELinux context to the new directory and the log file:semanage fcontext -a -t named_log_t "/var/log/named(/.*)?"
# semanage fcontext -a -t named_log_t "/var/log/named(/.*)?"Copy to Clipboard Copied! Toggle word wrap Toggle overflow restorecon -Rv /var/log/named
# restorecon -Rv /var/log/namedCopy to Clipboard Copied! Toggle word wrap Toggle overflow Restart the BIND server:
systemctl restart named
# systemctl restart namedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
Display your custom log file:
tail -f /var/log/named/ipa_dns_queries.log
$ tail -f /var/log/named/ipa_dns_queries.logCopy to Clipboard Copied! Toggle word wrap Toggle overflow