SupportConsoleDéveloppeursCommencer un essaiContact

Ce contenu n'est pas disponible dans la langue sélectionnée.

33.9. DNS Locations

33.9.1. DNS-based Service Discovery
Copier lien

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 IdM domain, DNS service records (SRV records) exists 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 33.10. 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.
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 previous 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 instead queries a DNS server 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 queries a DNS server in the location germany:

Example 33.11. 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.
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 previous 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.

33.9.2. Deployment Considerations for DNS Locations
Copier lien

For IdM DNS servers that are authoritative to the primary IdM DNS domain, IdM can generate location-specific SRV records. 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 slave 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 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.

33.9.2.1. DNS Time to Live (TTL)
Copier lien

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 is expired. The default TTL value in 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.
For further information how to modify the default TTL of a DNS zone, see Section 33.4.2, “Adding Additional Configuration for Master DNS Zones”.

33.9.3. Creating DNS Locations
Copier lien

Creating DNS Locations from the Web UI

  1. Open the IPA Server tab, and select Topology subtab.
  2. Click IPA Locations in the navigation bar.
  3. Click Add at the top of the locations list.
  4. Fill in the location name.
  5. Click the Add button to save the location.
Repeat the steps for further locations to add.

Creating DNS Locations from the Command Line

For example, to create a new location germany, enter: 
[root@server ~]# ipa location-add germany
----------------------------
Added IPA location "germany"
----------------------------
  Location name: germany
Repeat the step for all locations to add.

33.9.4. Assigning an IdM Server to a DNS Location
Copier lien

Assigning an IdM Server to a DNS Location from the Web UI

  1. Open the IPA Server tab, and select Topology subtab.
  2. Click IPA Servers in the navigation.
  3. Click on the IdM server name.
  4. Select a DNS location, and optionally set a service weight:

    Figure 33.34. Assigning a Server to a DNS Location

    Assigning a Server to a DNS Location
  5. Click Save.
  6. Restart the named-pkcs11 service on the host you assigned in the previous steps the DNS location to: 
    [root@idmserver-01 ~]# systemctl restart named-pkcs11
Repeat the steps for further IdM servers you want to assign a DNS location to.

Assigning an IdM Server to a DNS Location from the Command Line

  1. Optional: List all configured DNS locations: 
    [root@server ~]# ipa location-find
-----------------------
2 IPA locations matched
-----------------------
Location name: australia
Location name: germany
-----------------------------
Number of entries returned: 2
-----------------------------
  2. Assign the server to the DNS location. For example, to assign the location germany to the server idmserver-01.idm.example.com, run: 
    [root@server ~]# ipa server-mod idmserver-01.idm.example.com --location=germany
ipa: WARNING: Service named-pkcs11.service requires restart on IPA server
idmserver-01.idm.example.com to apply configuration changes.
--------------------------------------------------
Modified IPA server "idmserver-01.idm.example.com"
--------------------------------------------------
Servername: idmserver-01.idm.example.com
Min domain level: 0
Max domain level: 1
Location: germany
Enabled server roles: DNS server, NTP server
  3. Restart the named-pkcs11 service on the host you assigned in the previous steps the DNS location to: 
    [root@idmserver-01 ~]# systemctl restart named-pkcs11
Repeat the steps for further IdM servers you want to assign a DNS location to.
IdM servers are assigned to DNS locations as described in Section 33.9.4, “Assigning an IdM Server to a DNS Location”. Now you can configure the clients to use a DNS server that is in the same location as the IdM servers:
  • If a DHCP server assigns the DNS server IP addresses to the clients, configure the DHCP service. For further details about assigning a DNS server in your DHCP service, see the documentation of the DHCP service.
  • If your clients do not receive the DNS server IP addresses from a DHCP server, 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.
Note
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 33.12. 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
Clients in Paris: 
nameserver 10.50.0.1
nameserver 10.50.0.3
Clients in Oslo: 
nameserver 10.30.0.1
Clients in Berlin: 
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.
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Legal Notice

Theme

© 2026 Red HatRetour au début