Questo contenuto non è disponibile nella lingua selezionata.

Chapter 4. Planning your DNS services and host names


Identity Management (IdM) provides different types of DNS configurations in the IdM server. The following sections describe them and provide advice on how to determine which is the best for your use case.

4.1. DNS services available in an IdM server

You can install an Identity Management (IdM) server with or without integrated DNS.

Table 4.1. Comparing IdM with integrated DNS and without integrated DNS
 With integrated DNSWithout integrated DNS

Overview:

IdM runs its own DNS service for the IdM domain.

IdM uses DNS services provided by an external DNS server.

Limitations:

The integrated DNS server provided by IdM only supports features related to IdM deployment and maintenance. It does not support some of the advanced features of a general-purpose DNS server. Specific limitations are as follows:

  • IdM DNS nameserver must be authoritative for its zones.
  • The supported record types are A, AAAA, A6, AFSDB, CERT, CNAME, DLV, DNAME, DS, KX, LOC, MX, NAPTR, NS, PTR, SRV, SSHFP, TLSA, TXT, and URI.
  • Split DNS, also known as split-view, split-horizon, split-brain DNS, is not supported.
  • There are known issues if the DNS nameserver restarts in a multi-core environment. For example, if log rotation causes a nameserver to restart, the nameserver might crash. If you must use a multi-core setup, allow systemd to restart the nameserver after a failure occurs.

DNS is not integrated with native IdM tools. For example, IdM does not update the DNS records automatically after a change in the topology.

Works best for:

Basic usage within the IdM deployment.

When the IdM server manages DNS, DNS is tightly integrated with native IdM tools, which enables automating some of the DNS record management tasks.

Environments where advanced DNS features beyond the scope of the IdM DNS are needed.

Environments with a well-established DNS infrastructure where you want to keep using an external DNS server.

Even if an Identity Management server is used as a primary DNS server, other external DNS servers can still be used as secondary servers. For example, if your environment is already using another DNS server, such as a DNS server integrated with Active Directory (AD), you can delegate only the IdM primary domain to the DNS integrated with IdM. It is not necessary to migrate DNS zones to the IdM DNS.

Note

If you need to issue certificates for IdM clients with an IP address in the Subject Alternative Name (SAN) extension, you must use the IdM integrated DNS service.

4.2. Guidelines for planning the DNS domain name and Kerberos realm name

When installing the first Identity Management (IdM) server, the installation prompts for a primary DNS name of the IdM domain and Kerberos realm name. These guidelines can help you set the names correctly.

Warning

You will not be able to change the IdM primary domain name and Kerberos realm name after the server is already installed. Do not expect to be able to move from a testing environment to a production environment by changing the names, for example from lab.example.com to production.example.com.

A separate DNS domain for service records
Ensure that the primary DNS domain used for IdM is not shared with any other system. This helps avoid conflicts on the DNS level.
Proper DNS domain name delegation
Ensure you have valid delegation in the public DNS tree for the DNS domain. Do not use a domain name that is not delegated to you, not even on a private network.
Multi-label DNS domain
Do not use single-label domain names, for example .company. The IdM domain must be composed of one or more subdomains and a top level domain, for example example.com or company.example.com.
A unique Kerberos realm name
Ensure the realm name is not in conflict with any other existing Kerberos realm name, such as a name used by Active Directory (AD).
Kerberos realm name as an upper-case version of the primary DNS name

Consider setting the realm name to an upper-case (EXAMPLE.COM) version of the primary DNS domain name (example.com).

Warning

If you do not set the Kerberos realm name to be the upper-case version of the primary DNS name, you will not be able to use AD trusts.

Additional notes on planning the DNS domain name and Kerberos realm name

  • One IdM deployment always represents one Kerberos realm.
  • You can join IdM clients from multiple distinct DNS domains (example.com, example.net, example.org) to a single Kerberos realm (EXAMPLE.COM).
  • IdM clients do not need to be in the primary DNS domain. For example, if the IdM domain is idm.example.com, the clients can be in the clients.example.com domain, but clear mapping must be configured between the DNS domain and the Kerberos realm.

    Note

    The standard method to create the mapping is using the _kerberos TXT DNS records. The IdM integrated DNS adds these records automatically.

Planning DNS forwarding

  • If you want to use only one forwarder for your entire IdM deployment, configure a global forwarder.
  • If your company is spread over multiple sites in geographically distant regions, global forwarders might be impractical. Configure per-server forwarders.
  • If your company has an internal DNS network that is not resolvable from the public internet, configure a forward zone and zone forwarders so that the hosts in the IdM domain can resolve hosts from this other internal DNS network.
Red Hat logoGithubRedditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita ilBlog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

© 2024 Red Hat, Inc.