| Identity Management GuideChapter 10. Identity: Managing DNSIf the IdM server was installed with DNS configured, then all of the DNS entries for the domain - host entries, locations, records - can be managed using the IdM tools. DNS is one of the services that can be configured and maintained by the IdM domain. DNS is critical to the performance of the IdM domain; DNS is used for the Kerberos services and SSL connections for all servers and clients and for connections to domain services like LDAP. While IdM can use an external DNS service, there is a lot more flexibility and control over IdM - DNS interactions when the DNS service is configured within the domain. For example, DNS records and zones can be managed within the domain using IdM tools, and clients can update their own DNS records dynamically. When a host is added to IdM, a DNS record is automatically created in IdM's DNS service for that host machine. IdM stores all DNS information as LDAP entries. Every resource record for each machine is stored for the domain. For example, the client1 resource has three IPv4 (A) records and one IPv6 (AAAA) record: dn: idnsname=client1,idnsname=example.com,cn=dns,dc=example,dc=comidnsname: client1arecord: 10.0.0.1arecord: 10.0.0.2arecord: 10.0.0.3aaaarecord: fc00::1objectclass: topobjectclass: idnsrecord The schema used to define the DNS entries is in the /usr/share/ipa/60basev2.ldif schema file . The BIND service communicates with the Directory Server using the system bind-dyndb-ldap plug-in. When Identity Management is configured to manage DNS ( Section 10.3, "Setting up DNS After IdM Server Installation"), IdM creates a dynamic-db configuration section in the /etc/named.conf file for the BIND service. This configures the bind-dyndb-ldap plug-in for the BIND ( named) service. When this plug-in is properly configured, it delivers the DNS records from the Directory Server to the named service. The configuration can be changed to adapt the behavior of the plug-in and, therefore, the LDAP-BIND interactions. 10.2. The IdM-Generated DNS FileTo help create and configure a suitable DNS setup, the IdM installation script creates a sample zone file. During the installation, IdM displays a message similar to the following: Sample zone file for bind has been created in /tmp/sample.zone.F_uMf4.db If a DNS server is already configured in the network, then the configuration in the IdM-generated file can be added to the existing DNS zone file. This allows IdM clients to find LDAP and Kerberos servers that are required for them to participate in the IdM domain. For example, this DNS zone configuration is created for an IdM server with the KDC and DNS servers all on the same machine in the EXAMPLE.COM realm: ; ldap servers_ldap._tcp IN SRV 0 100 389 ipaserver.example.com.;kerberos realm_kerberos IN TXT EXAMPLE.COM; kerberos servers_kerberos._tcp IN SRV 0 100 88 ipaserver.example.com._kerberos._udp IN SRV 0 100 88 ipaserver.example.com._kerberos-master._tcp IN SRV 0 100 88 ipaserver.example.com._kerberos-master._udp IN SRV 0 100 88 ipaserver.example.com._kpasswd._tcp IN SRV 0 100 464 ipaserver.example.com._kpasswd._udp IN SRV 0 100 464 ipaserver.example.com. 10.3. Setting up DNS After IdM Server InstallationDNS can be configured as part of the IdM server installation, simply by using the --setup-dns option. If DNS is not configured then, it can be configured later using the ipa-dns-install command. For example: ipa-dns-install -p secret --ip-address=1.2.34.56 --no-forwarders [--zone-refresh=60 | --zone-notif] -p gives the password for the Directory Manager user in the 389 Directory Server. All of the DNS entries are stored in the LDAP directory, so this directory must be accessed to add the DNS configuration.
--ip-address gives the IP address for the master DNS server.
--no-forwarders means that there are no forwarders used with the DNS service, only root servers. Alternatively, use the --forwarder option to define a forward to use; to specify multiple forwarders, use the --forwarder option multiple times.
Reverse DNS is configured automatically. It is possible to disable reverse DNS by using the --no-reverse option. If an existing reverse DNS zone is already configured, using the --no-reverse option uses the existing reverse zone rather than creating a new reverse zone. The IdM server can actively check to see when new DNS zones are added and to update its DNS server accordingly. If no value is explicitly given, the zone refresh period is 30 seconds. The refresh interval can be set to another value using the --zone-refresh option, which sets the polling interval in seconds. Similar to refreshing the zones, the IdM server can leave a persistent search open with its Directory Server and capture any new zone changes immediately. This is enabled with the --zone-notif option. If the --zone-notif option is used to configure DNS, then the automatic zone refresh is disabled.
10.4. Managing DNS Zone Entries10.4.1.1. Adding DNS Zones from the Web UIOpen the Identity tab, and select the DNS subtab. Click the Add link at the top of the list of DNS zones. Fill in the information about the new DNS zone. The Zone Name is required; this is the actual domain name. The other information about the administrator email and the authoritative name server are optional.
10.4.1.2. Adding DNS Zones from the Command LineThe ipa dnszone-add command adds a new zone to the DNS domain. At a minimum, this requires the name of the new subdomain: $ ipa dnszone-add domainName If the name is not given, the script prompts for it. Other command-line options can also be passed with the ipa dnszone-add command. To add a zone entry: Add the new zone. For example: $ ipa dnszone-add newserver.example.com [email protected] --minimum=3000 --dynamic-update=TRUE Reload the name service. # rndc reload
10.4.2. Modifying DNS ZonesA zone is created with a certain amount of configuration, set to default values. Example 10.1. Default DNS Zone Entry Settings dn: idnsname=example.com,cn=dns,dc=example,dc=com idnsname: example.com idnssoamname: server.example.com. idnssoarname: root.server.example.com. idnssoaserial: 2011130701 idnssoarefresh: 3600 idnssoaretry: 900 idnssoaexpire: 1209600 idnssoaminimum: 3600 idnsupdatepolicy: grant EXAMPLE.COM krb5-self * A; grant EXAMPLE.COM krb5-self * AAAA; idnszoneactive: TRUE idnsallowdynupdate: TRUE nsrecord: server.example.com. objectclass: top objectclass: idnsrecord objectclass: idnszone All of the possible zone settings are listed in Table 10.1, "Zone Attributes". 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. Table 10.1. Zone Attributes | Attribute | Command-Line Option | Description |
|---|
| Zone name | --name | Sets the name of the zone. | | Authoritative nameserver | --name-server | Sets the fully-qualified domain name of the DNS name server. | | Administrator e-mail address | --admin-email | Sets the email address to use for the zone administrator. This defaults to the root account on the host. | | SOA serial | --serial | Sets a version number for the SOA record file. | | SOA refresh | --refresh | Sets the interval, in seconds, for a secondary DNS server to wait before requesting updates from the primary DNS server. | | SOA retry | --retry | Sets the time, in seconds, to wait before retrying a failed refresh operation. | | SOA expire | --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 | --minimum | Sets the minimum amount of time, in seconds, that data are kept in cache. | | SOA time to live | --ttl | Sets the maximum time, in seconds, that information is kept in the data cache. | | SOA class | --class | Sets the type of record. This is almost always IN, which stands for Internet. | | BIND update policy | --update-policy | Sets the permissions allowed to clients in the DNS zone. | | Dynamic update | --dynamic-update=TRUE|FALSE | Enables dynamic updates to DNS records for clients. | | Name server | --ip-address | Adds the DNS name server by its IP address. | | Allow transfer | --allow-transfer=string | Gives a semi-colon-separated listed of IP addresses or network names which are allowed to transfer the given zone. | | Allow query | --allow-query | Gives a semi-colon-separated listed of IP addresses or network names which are allowed to issue DNS queries. | | Allow PTR sync | --allow-sync-ptr=TRUE|FALSE | Sets whether A or AAAA records (forward records) for the zone will be automatically synchronized with the PTR (reverse) records. | | Zone forwarders | --forwarder=string | Specifies a forwarder specifically configured for the DNS zone. This is separate from any global forwarders used in the IdM domain. To specificy multiple forwarders, use the option multiple times. | | Forward policy | --forward-policy=only|first | Sets whether the zone will only forward requests to configured the DNS name servers (a forward-only zone) or whether it will check the forwarders first for DNS records and then check its own local records. |
10.4.2.1. Editing the Zone Configuration in the Web UIOpen the Identity tab, and select the DNS subtab. Click the name of the DNS zone to edit. Open the Settings tab. Change any of the DNS zone settings. The full list of attributes is described in Table 10.1, "Zone Attributes". There are some common attributes to change: Authoritative name server, the fully-qualified domain name of the DNS name server. Dynamic update, to enable dynamic updates to DNS records for clients. SOA refresh, the interval, in seconds, for a secondary DNS server to wait before requesting updates from the primary DNS server.
Click the Update link at the top of the settings page.
10.4.2.2. Editing the Zone Configuration in the Command LineThe zone can be created with additional attributes and values different from the default by passing additional options with the dnszone-add command. Likewise, attributes can be added or modified in the zone entry by passing the same attribute options with the dnszone-mod command. These are listed in Table 10.1, "Zone Attributes". If an attribute does not exist in the DNS zone entry, than the dnszone-mod command adds the attribute. If the attribute exists, then it overwrites the current value with the specified value. For example, to set a time to live for SOA records: $ ipa dnszone-mod server.example.com --ttl=1800 This adds a new attribute to the DNS zone entry: dn: idnsname=example.com,cn=dns,dc=example,dc=com idnsname: example.com idnssoamname: server.example.com. idnssoarname: root.server.example.com. idnssoaserial: 2011130701 idnssoarefresh: 3600 idnssoaretry: 900 idnssoaexpire: 1209600 idnssoaminimum: 3600 dnsttl: 1800 idnsupdatepolicy: grant EXAMPLE.COM krb5-self * A; grant EXAMPLE.COM krb5-self * AAAA; idnszoneactive: TRUE idnsallowdynupdate: TRUE nsrecord: server.example.com. objectclass: top objectclass: idnsrecord objectclass: idnszone 10.4.3. Enabling and Disabling ZonesActive zones can have clients added to them, are available for lookups, and are used by IdM services like Kerberos. Deleting a DNS zone removes the zone entry and all the associated configuration. There can be situations when it is necessary to remove a zone from activity without permanently removing the zone. This is done by disabling the zone. 10.4.3.1. Disabling Zones in the Web UIOpen the Identity tab, and select the DNS subtab. Click the name of the DNS zone to edit. Open the Settings tab. Scroll down to the Active zone field. To disable the zone, set the value to Disabled. Click the Update link at the top of the settings page.
10.4.3.2. Disabling Zones in the Command LineDisabling a zone is done by using the dnszone-disable command. For example: $ ipa dnszone-disable server.example.com When the zone needs to be brought back online, it can be re-enabled using the dnszone-enable command. 10.5. Managing DNS Record Entries10.5.1. Adding Records to DNS ZonesTable 10.2. DNS Record Types | A | CERT | KX | NS | SIG | | AAAA | CNAME | LOC | NSEC | SRV | | A6 | DNAME | MX | PTR | SSHFP | | AFSDB | DS | NAPTR | RRSIG | TXT |
10.5.1.1. Adding DNS Resource Records from the Web UIOpen the Identity tab, and select the DNS subtab. Click the name of the DNS zone to which to add records. In the DNS Resource Records tab, click the Add link. Select the type of record to create in the Record Type drop-down menu. The required data is different, depending on the record type. For example, a CNAME record requires a hostname. The data field name updates automatically to indicate what kind of information to supply. Although IdM supports many different record types, there are four frequent record types that are used: A. This is a basic map for a hostname and an ordinary IPv4 address. The Record Name is a hostname, such as www. The IP Address value is a standard IPv4 address, such as 192.168.1.2. More information about A records is in RFC 1035. AAAA. This is a basic map for a hostname and an IPv6 address. The Record Name is a hostname, such as www. The IP Address value is a standard hexadecimal IPv6 address, such as fe80::20c:29ff:fe02:a1b3. More information about AAAA records is in RFC 3596. SRV. Service (SRV) resource records map service names to the DNS name of the server that is providing that particular service. The Record Name has the format _service._protocol, such as _ldap._tcp. There are individual fields to set the priority, weight, port number, and hostname for the target service. More information about SRV records is in RFC 2782. PTR. A pointer record type (PTR) record adds a reverse DNS record, which maps an IP address to a domain name. In this case, the Record Name is the record ID number for the DNS entry of the resource and the Hostname value is the hostname with a terminal period, such as server.example.com.. More information about PTR records is in RFC 1035.
Click the Add button to save the new resource record.
10.5.1.2. Adding DNS Resource Records from the Command LineThe same script, ipa dnsrecord-add, is used to add resource records of any type, but the options for the script and the required data are different, based on the resource record type. 10.5.1.2.1. About the Commands to Add DNS RecordsThe ipa dnsrecord-add command adds records to DNS zones, based on the type. Adding a record has the same basic command format: $ ipa dnsrecord-add zoneName recordName --recordType-option=data The zoneName is the name of the DNS zone to which the record is being added. The recordName is an identifier for the new DNS resource record. Table 10.3, "Common dnsrecord-add Options" lists options for the most common resource record types: A (IPv4), AAAA (IPv6), SRV, and PTR. Options for other supported record types are listed in the ipa dnsrecord-add help and manpages. The ipa dnsrecord-add command only creates forward entries, not reverse entries. Table 10.3. Common dnsrecord-add Options | General Record Options |
|---|
| Option | Description | | --ttl=number | Sets the time to live for the record. | | --class=IN | CS | CH | HS | Sets the class of the record. This is usually IN, for Internet protocol. | | --structured | Parses the raw DNS records and returns them in a structured format. |
| "A" Record Options |
|---|
| Option | Description | | --a-rec=ARECORD | Passes a comma-separated list of A records. | | --a-ip-address=string | Gives the IP address for the record. |
| "AAAA" Record Options |
|---|
| Option | Description | | --aaaa-rec=AAAARECORD | Passes a comma-separated list of AAAA (IPv6) records. | | --aaaa-ip-address=string | Gives the IPv6 address for the record. |
| "PTR" Record Options |
|---|
| Option | Description | | --ptr-rec=PTRRECORD | Passes a comma-separated list of PTR records. | | --ptr-hostname=string | Gives the hostname for the record. |
| "SRV" Record Options |
|---|
| Option | Description | | --srv-rec=SRVRECORD | Passes a comma-separated list of SRV records. | | --srv-priority=number | 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. | | --srv-weight=number | Sets the weight of the record. This helps determine the order of SRV records with the same priority. | | --srv-port=number | Gives the port for the service on the target host. | | --srv-target=string | Gives the domain name of the target host. This can be a single period (.) if the service is not available in the domain. |
10.5.1.2.2. Examples of Adding DNS Resource RecordsExample 10.2. IPv4 Record Type A resource records map hostnames to IPv4 addresses. The record value for these commands, then, is a standard IPv4 address. The URL label is usually www. $ ipa dnsrecord-add example.com www --a-rec 10.64.14.165 This creates the record www.example.com with the IP address 10.64.14.165. More information about A records is in RFC 1035. Example 10.3. IPv6 Record Type AAAA resource records ( quad-A records) map hostnames to IPv6 addresses. The record value for these commands is an IPv6 address. As with Type A records, the URL label is usually www. $ ipa dnsrecord-add example.com www --aaaa-rec fe80::20c:29ff:fe02:a1b3 This creates the record www.example.com with the IP address fe80::20c:29ff:fe02:a1b3. More information about AAAA records is in RFC 3596. Example 10.4. SRV Record 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 DNS server which manages it. As with Type A and Type AAAA records, SRV records specify a way to connect to and identify the service, but the record format is different. The recordName identifies the service type and the connection protocol, in the format _service._protocol. The record information has the format "priority weight port target". $ ipa dnsrecord-add server.example.com _ldap._tcp --srv-rec="0 100 389 server1.example.com." $ ipa dnsrecord-add server.example.com _ldap._tcp --srv-rec="1 100 389 server2.example.com." More information about SRV records is in RFC 2782. Example 10.5. PTR Record A pointer record type (PTR) record adds a reverse DNS record, which maps an IP address to a domain name, rather than the other way around. All 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 the in-addr.arpa. domain appended to it. For example, for the IP address 192.0.1.2, the reverse address is 2.1.0.192.in-addr.arpa. When adding the reverse DNS record, the format of the dnsrecord-add command is also reverse, compared to the usage for adding regular DNS entries: $ ipa dnsrecord-add reverseIpAddress recordId --ptr-rec FQDN The recordId is the numeric identifier to use for the entry in the zone. For example, this adds a record with an ID of 4 for server2.example.com: $ ipa dnsrecord-add 2.1.0.192.in-addr.arpa 4 --ptr-rec server2.example.com. More information about PTR records is in RFC 1035. Reverse 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. 10.5.2. Deleting Records from DNS Zones10.5.2.1. Deleting Records with the Web UITo delete only a specific record from the resource record: Open the Identity tab, and select the DNS subtab. Click the name of the DNS zone. In the DNS Resource Records tab, click the name of the resource record. Click the checkbox by the name of the record type to delete, and then click the active Delete link at the top of the list. This deletes only that record type while leaving the other configuration intact.
Alternatively, delete all of the records for the resource in the zone: Open the Identity tab, and select the DNS subtab. Click the name of the DNS zone. In the DNS Resource Records tab, select the checkbox by the name of the resource record to delete. This deletes the entire record. Click the Delete link at the top of the zone records page.
10.5.2.2. Deleting Records with the Command LineRecords are removed from the zone using the ipa dnsrecord-del command. As with adding records, records are deleted using an option that specifies the type of record (--recordType-rec) and the record value. For example, to remove the A type record: $ ipa dnsrecord-del example.com www --a-rec 10.64.14.213 If you run the ipa dnsrecord-del command without any options, the command prompts for information about the record to delete. Alternatively, using the --del-all option removes all associated records for the zone. 10.6. Configuring the bind-dyndb-ldap Plug-inThe bind-dyndb-ldap system plug-in contains a DNS record cache for zones and a history of successful DNS resolutions. Maintaining the cache improves lookup performance in the Directory Server because it is not necessary to query the directory services every time there is a new DNS request. When this plug-in is installed and IdM is configured to manage DNS, then a new configuration section is added to the plug-in configuration. Example 10.6. Default dynamic-db Configuration dynamic-db "ipa" { library "ldap.so"; arg "uri ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket"; arg "base cn=dns, dc=example,dc=com"; arg "fake_mname server.example.com."; arg "auth_method sasl"; arg "sasl_mech GSSAPI"; arg "sasl_user DNS/server.example.com";};This configuration uses implied default values for other plug-in behaviors, like how long it maintains the cache. The assumed, default configuration can be changed by adding arguments to the dynamic-db "ipa" entry. arg "argument value"; Both cache updates and new zone detection can be forced by reloading the name server: # rndc reload Table 10.4. Additional bind-dyndb-ldap Configuration Parameters | Parameter | Description | Default Value |
|---|
| cache_ttl | Checks the DNS configuration in the Directory Server for new zones. | 120 (seconds); this is defined in the bind-dyndb-ldap plug-in. | | zone_refresh | Checks frequency, in seconds, that the server checks the DNS configuration in the Directory Server for new zones. | 60 (seconds); this is configured by ipa-dns-install. If this is not set in the /etc/named.conf file, the bind-dyndb-ldap plug-in sets this value to zero (0), which disables zone refresh. | | psearch | Enables persistent searches for the Directory Server so the BIND service immediately receives an update notification when a new DNS zone is added. | no |
10.6.1. Changing the DNS Cache SettingTo improve DNS performance, it may be necessary to change the cache setting. By default, DNS records are kept in cache and considered valid for 120 seconds. This means that if a DNS record changes, it will not (necessarily) be propagated to the name server for up to 120 seconds. If the Directory Server has a high traffic volume or if records do not change frequently, then the cache time can be increased to improve performance by adding the cache_ttl parameter. dynamic-db "ipa" { ... arg "cache_ttl 1800"; };10.6.2. Enabling Zone Refreshes and Persistent SearchesThe DNS service receives its information through the bind-dyndb-ldap plug-in. The plug-in resolves only zones which were configured and enabled in the Directory Server when the name server started. When the name service restarts, the plug-in reloads its configuration and identifies any new zones or any new resource records. However, the bind-dyndb-ldap plug-in pulls zone and resource record information from the IdM LDAP directory, and it is possible to pull information from that directory apart from simply restarting the plug-in. The bind-dyndb-ldap plug-in search for zone changes actively either by refreshing the zone data or by keeping a persistent connection open to the Directory Server and immediately catching any changes. Periodically checking for new zones is the same as refreshing the zone configuration. This is set in the zone_refresh argument. dynamic-db "ipa" { ... arg "zone_refresh 30"; };Alternatively, the plug-in can maintain an open connection to the server through a persistent search. Persistent searches provide immediate notification of changes, unlike polling, and maintain a local cache of the configuration data. A persistent search catches updates both to zones and to zone resource records. Persistent searches are disabled by default but can be enabled in the psearch argument: dynamic-db "ipa" { ... arg "psearch yes"; };10.7. Changing Recursive Queries Against ForwardersThe ipa-client-install script sets a configuration statement in the /etc/named.conf file that allows name resolution against hosts that are outside the IdM DNS domain. (This requires that the IdM server be set up with DNS configured and with forwarders configured.) What this means is that any host is permitted to issue recursive queries against configured forwarders. By default, any host is permitted to issue recursive queries against configured forwarders. The IdM installation script automatically adds a line to the /etc/named.conf file to allow these recursive queries. forward first; forwarders { 10.16.36.29; }; allow-recursion { any; };This behavior can be changed in the allow-recursion statement. Open the /etc/named.conf file. Reset the allow-recursion statement. This is set to any by default, which allows all hosts to resolve names against all forwarders. forward first; forwarders { 10.16.36.29; }; allow-recursion { any; };Restart the named service. service named restart
The name server documentation has more details on editing configuration statements. 10.8. Enabling Dynamic DNS UpdatesDynamic DNS updates are not enabled by default for new DNS zones in IdM. If dynamic updates are not allowed, then it may not be possible for the ipa-client-install script to join a client to the domain because it cannot add a DNS record pointing to the new client. 10.8.1. Enabling Dynamic DNS Updates in the Web UIOpen the Identity tab, and select the DNS subtab. Click the name of the DNS zone to edit. Open the Settings tab. Scroll down to the Dynamic update field, and set the value to True. Click the Update link at the top of the settings page.
10.8.2. Enabling Dynamic DNS Updates in the Command LineTo allow dynamic updates to the DNS zones, set the --dynamic-update option. $ ipa dnszone-mod server.example.com --dynamic-update=TRUE 10.9. Configuring Forwarders and Forward PolicyA DNS forwarder is a server which passes DNS queries on to another, external DNS name server for resolution. Within the IdM DNS domain, there are three configuration properties that define how forwarders are used: A list of global forwarders which are used by all zones in IdM A list of forwarders which are used by a single, specific zone (as part of the zone configuration) A policy which defines how the zone sends requests to the forwarders
10.9.1. Configuring Global ForwardersGlobal forwarders are configured as part of the IdM server configuration itself. Forwarders are (optionally) set up when the server is installed with the setup-dns option or when the ipa-dns-install script is used. After server configuration, the list of global forwarders can be edited using the dnsconfig-mod command. For example: [jsmith@server ~]$ ipa dnsconfig-mod --forwarder=0.9.8.7 Global forwarders: 0.9.8.7 10.9.2. Configuring Zone ForwardersForwarders can be configured to be used with a specific DNS zone as part of the zone configuration. The --forwarder option sets a semi-colon-separated list of forwarders to use with the zone. For example: [jsmith@server ~]$ ipa dnszone-mod --forwarder=1.2.3.4;255.255.255.255 example.com Zone name: example.com... Zone forwarders: 1.2.3.4;255.255.255.255 DNS forwarders must be specified as IP addresses, not as hostnames. 10.9.3. Configuring Forwarder Policy for a ZoneOnce forwarders are configured, there are different ways that the zone can use them to service requests. The zone can use the forwarders only for servicing name resolution requests; this is called a forward-only zone. A forward-only zone does not check its own name records. Only the forwarder server records are checked. If the record does not exist on the configured forwarders, then the zone returns a negative response to the client. Alternatively, the zone can check the forwarder records first, and then fallback on its own resource records. This has a first policy. This configuration is set in the --forward-policy option, using a policy of either only or first. For example: [jsmith@server ~]$ ipa dnszone-mod --forward-policy=only example.com Zone name: example.com... Zone forwarders: 1.2.3.4;255.255.255.255 Forward policy: only 10.10. Enabling Zone TransfersName servers maintain authoritative data for the zones; as changes are made to the zones, those changes must be sent to and distributed among the name servers for the DNS domain. A zone transfer moves resource records from one name server to another. An authoritative transfer (AXFR) is a zone transfer which includes that authoritative data for the zone (as opposed to an incremental transfer, which only delivers the most immediate zone change). Zone transfers can be enabled when the zone is created or when it is modified by using the --allow-transfer option to set a list of name servers to which the zone records can be transferred. For example: [jsmith@server ~]$ ipa dnszone-mod --allow-transfer=255.255.255.255;0.0.0.0;1.2.3.4 example-zone The default is any, which the zone to be transferred anywhere in the DNS domain. Once it is enabled in the bind service, IdM DNS zones can be transferred, by name, by clients like dig: [root@server ~]# dig @ipa-server zone_name AXFR 10.11. Defining DNS QueriesTo resolve hostnames within the DNS domain, a DNS client issues a query to the DNS name server. For some security contexts or for performance, it may be advisable to restrict what clients can query DNS records in the zone. DNS queries can be configured when the zone is created or when it is modified by using the --allow-query option to set a list of clients which are allowed to issue queries. For example: [jsmith@server ~]$ ipa dnszone-mod --allow-query=255.255.255.255;0.0.0.0;1.2.3.4 example-zone The default is any, which allows the zone to be queried by any client. 10.12. Synchronizing Forward and Reverse Zone EntriesForward entries (A and AAAA) are configured separately from reverse entries (PTR). Because these entries are configured independently, it is possible for forward entries to exist without corresponding reverse entries, and vice versa. A DNS zone can be configured to allow its forward and reverse entries to be synchronized automatically, by setting the --allow-sync-ptr option to true. This can be done when the zone is created or when it is edited. For example, for editing an existing entry: [jsmith@server ~]$ ipa dnszone-mod --allow-sync-ptr example-zone The default is false, which disables synchronization and has better server performance. 10.13. Setting DNS Access PoliciesThe IdM DNS domain can define access controls, based on grant/deny rules, for zones. This creates an update-policy statement in the /etc/named.conf file, which defines the DNS access rule. --update-policy "grant|deny zoneName policyName recordName recordType" zoneName is the IdM DNS zone to which to apply the rule. policyName is the name to use for the BIND rule. recordName sets the resource records to which to apply the rule. Using an asterisk (*) is used for self rules. recordType is the record type the rule applies to. Update access rules are applied individually for each record type, even within the same DNS zone entry.
For example, to grant the EXAMPLE.COM zone the ability to edit its own A and AAAA resource record entries: $ ipa dnszone-mod example.com --update-policy="grant EXAMPLE.COM krb5-self * A; grant EXAMPLE.COM krb5-self * AAAA;" 10.14. Resolving Hostnames in the IdM DomainIt is possible to check the DNS entries for IdM domain members using the dns-resolve command. If the record exists and is properly formatted in the DNS configuration, then the command returns the DNS record. If not, the command returns an error, that the hostname is not recognized within the DNS service. $ipa dns-resolve server1.example.com This can be helpful with troubleshooting connection problems between servers, clients, and services. 10.15. Changing Load Balancing for IdM Servers and ReplicasAs Section 1.3.1, "About IdM Servers and Replicas" touches on, IdM servers and replicas in the domain automatically share the load among instances to maintain performance. The load balancing is defined first by the priority set for the server or replica in its SRV entry, and then by the weight of that instance for servers/replicas with the same priority. Clients contact servers/replicas with the highest priority and then work their way down. Load balancing is done automatically by servers, replicas, and clients. The configuration used for load balancing can be altered by changing the priority and the weight given to a server or replica. (All replicas are initially created with the same priority.) For example, this gives server1 a higher priority than server 2, meaning it will be contacted first: $ ipa dnsrecord-add server.example.com _ldap._tcp --srv-rec="0 100 389 server1.example.com." $ ipa dnsrecord-add server.example.com _ldap._tcp --srv-rec="1 100 389 server2.example.com." More information about SRV records is in RFC 2782. |
| |
