이 콘텐츠는 선택한 언어로 제공되지 않습니다.
17.6. Managing DNS Zone Entries
17.6.1. Adding Forward DNS Zones
17.6.1.1. From the Web UI
- Open 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.
Note
If an email is given for the administrator, then replace the at symbol (@) with a period (.) to maintain compatibility with the zone file. - Click the Add and Edit button to go directly to the DNS zone page. In the Settings tab, it is possible to reset the default zone configuration to enable dynamic binds (Section 17.6.5.1, “Enabling Dynamic DNS Updates in the Web UI”) or change other default records information (Section 17.6.2.2, “Editing the Zone Configuration in the Web UI”). It is also possible to begin adding new DNS resource records (Section 17.7.1.1, “Adding DNS Resource Records from the Web UI”) in the DNS Resource Records tab.
17.6.1.2. From the Command Line
The
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:
[root@server ~]# ipa dnszone-add newserver.example.com --admin-email=admin@example.com --minimum=3000 --dynamic-update
- Reload the name service.
[root@server ~]# rndc reload
Note
To make new resource records immediately resolvable without restarting the name service, enable persistent searches with thenamed
service or configure the BIND service to poll the Directory Server automatically for zone changes. See Section 17.8.2, “Disabling Persistent Searches”.
17.6.2. Adding Additional Configuration for DNS Zones
A zone is created with a certain amount of configuration for things like its refresh periods, transfer settings, and cache settings, set to default values.
Example 17.2. Default DNS Zone Entry Settings
[root@server ~]# ipa dnszone-show server.example.com Zone name: server.example.com Authoritative nameserver: dns.example.com Administrator e-mail address: admin.example.com. SOA serial: 1377691702 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3000 Active zone: TRUE Allow query: any; Allow transfer: none;
17.6.2.1. DNS Zone Configuration Attributes
All of the possible zone settings are listed in Table 17.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.
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.
Important
If this is set to false, IdM client machines will not be able to add or update their IP address. See Section 17.6.5, “Enabling Dynamic DNS Updates” for more information.
|
Name server | --ip-address | Adds the DNS name server by its IP address. |
Allow transfer | --allow-transfer=string | Gives a semi-colon-separated list of IP addresses or network names which are allowed to transfer the given zone. |
Allow query | --allow-query | Gives a semi-colon-separated list of IP addresses or network names which are allowed to issue DNS queries. |
Allow PTR sync | --allow-sync-ptr=1|0 | 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. |
17.6.2.2. Editing the Zone Configuration in the Web UI
- Open 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 17.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.
17.6.2.3. Editing the Zone Configuration in the Command Line
The 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 17.1, “Zone Attributes”.
If an attribute does not exist in the DNS zone entry, then the
dnszone-mod
command adds the attribute. If the attribute exists, then it overwrites the current value with the specified value.
For example, setting a time to live for SOA records, adds a new attribute to the DNS zone entry (since there was no previous default value):
[jsmith@server ~]$ kinit admin [jsmith@server ~]$ ipa dnszone-mod server.example.com --ttl=1800 Zone name: server.example.com Authoritative nameserver: dns.example.com Administrator e-mail address: admin.example.com. SOA serial: 1377691702 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3000 SOA time to live: 1800 Active zone: TRUE Allow query: any; Allow transfer: none;
17.6.3. Adding Reverse DNS Zones
The process to add a reverse zone is the same as for a forward zone, as described in Section 17.6.1, “Adding Forward DNS Zones”. However, the required information is different.
There are two ways to identify a reverse DNS zone:
- By zone name, in the format reverse_ip_address
.in-addr.arpa.
- By network address, in the format network_ip_address/subnet_mask_bit_count
When creating a reverse zone by the zone name, set it up exactly as creating a forward zone, only reverse the order of the components of the IP address. For example, if the IP address is 1.2.3.4, then the reverse zone name is 3.2.1.in-addr.arpa. (with the trailing period).
In the web UI, this is set in the Zone name field.
Figure 17.1. Creating a Reverse Zone by Name
With the command-line tools, the zone is created by name like this:
[bjensen@server ~]$ kinit [bjensen@server]$ ipa dnszone-add 206.65.10.in-addr.arpa.
To create the reverse zone by its IP network, set the network information to the (forward-style) IP address, with the subnet mask bit count. The bit count must be a multiple of eight for IPv4 addresses or a multiple of four for IPv6 addresses.
In the web UI, this is set in the Reverse zone IP network field.
Figure 17.2. Creating a Reverse Zone by IP Network
With the command-line tools, the zone is created by IP network like this:
[bjensen@server ~]$ kinit [bjensen@server]$ ipa dnszone-add 10.65.206.0/24
17.6.4. Enabling and Disabling Zones
Active 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.
17.6.4.1. Disabling Zones in the Web UI
- Open 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.
17.6.4.2. Disabling Zones in the Command Line
Disabling a zone is done by using the
dnszone-disable
command.
For example:
[jsmith@server ~]$ kinit admin [jsmith@server ~]$ ipa dnszone-disable server.example.com ----------------------------------------- Disabled DNS zone "server.example.com" -----------------------------------------
When the zone needs to be brought back online, it can be re-enabled using the
dnszone-enable
command.
17.6.5. Enabling Dynamic DNS Updates
Dynamic 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.
17.6.5.1. Enabling Dynamic DNS Updates in the Web UI
- Open 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.
17.6.5.2. Enabling Dynamic DNS Updates in the Command Line
To allow dynamic updates to the DNS zones, set the
--dynamic-update
option.
$ ipa dnszone-mod server.example.com --dynamic-update=TRUE
17.6.6. Configuring Forwarders and Forward Policy
A 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
17.6.6.1. Configuring Forwarders in the UI
As with the other DNS zone settings (Section 17.6.2.2, “Editing the Zone Configuration in the Web UI”), the forwarder configuration is in the Settings tab for the given DNS zone.
There are two areas to edit:
- To add a forwarder, fill in the field or click Add to add a new IP address to the forwarder list.
- By default, the zone uses 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.
Figure 17.3. Forwarders in the DNS Zone Configuration
17.6.6.2. Configuring Forwarders in the Command Line
The forwarder settings can be edited by using the
dnszone-mod
command to update the zone settings. This can be used to set the list of DNS forwarders and the forwarding policy, as in the UI.
Additionally, the
dnsconfig
command can be used to set a global list of forwarders for all zones by editing the DNS configuration files.
Example 17.3. Configuring Global Forwarders
Global 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
Example 17.4. Configuring Zone Forwarders
Forwarders can be configured to be used with a specific DNS zone as part of the zone configuration. The
--forwarder
option can be used multiple times to create a list of forwarders to use with the zone.
For example:
[jsmith@server ~]$ ipa dnszone-mod --forwarder=192.0.2.0 --forwarder=198.51.100.0 example.com Zone name: example.com ... Zone forwarders: 192.0.2.0, 198.51.100.0
Note
DNS forwarders must be specified as IP addresses, not as hostnames.
Example 17.5. Configuring Forwarder Policy for a Zone
Once 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;5.6.7.8 Forward policy: only
17.6.7. Enabling Zone Transfers
Name 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).
17.6.7.1. Enabling Zone Transfers in the UI
As with the other DNS zone settings (Section 17.6.2.2, “Editing the Zone Configuration in the Web UI”), the zone transfer configuration is in the Settings tab for the given DNS zone.
Set a list of name servers to which the zone records can be transferred. Fill in the field or click Add to add a new IP address to the name server list.
Figure 17.4. DNS Zone Transfer Settings
17.6.7.2. Enabling Zone Transfers in the Command Line
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="0.0.0.0;1.2.3.4;5.6.7.8" 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
17.6.8. Defining DNS Queries
To 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=0.0.0.0;1.2.3.4;5.6.7.8 example-zone
The default is
any
, which allows the zone to be queried by any client.
17.6.9. Synchronizing Forward and Reverse Zone Entries
Forward 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.
There are some DNS setting requirements for PTR synchronization to work:
- Both forward and reverse zones must be managed by the IdM server.
- Both zones must have dynamic updates enabled.Enabling dynamic updates is covered in Section 17.6.5, “Enabling Dynamic DNS Updates”.
- The PTR record will be updated only if the name of the requesting client matches the name in the PTR record.
Important
Changes made through the IdM web UI, through the IdM command-line tools, or by editing the LDAP entry directly do not update the PTR record. Only changes made by the DNS service itself trigger PTR record synchronization.
Warning
A client system can update its own IP address. This means that a compromised client can be used to overwrite PTR records by changing its IP address.
17.6.9.1. Configuring Zone Entry Sync in the UI
Note
This is set on the forward zone server, not the reverse DNS server.
As with the other DNS zone settings (Section 17.6.2.2, “Editing the Zone Configuration in the Web UI”), the zone transfer configuration is in the Settings tab for the given DNS zone.
The PTR synchronization is enabled by selecting the Allow PTR Sync checkbox.
Figure 17.5. DNS Zone Sync Settings
17.6.9.2. Configuring Zone Entry Sync in the Command Line
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 1
. This can be done when the zone is created or when it is edited.
Note
This is set on the forward zone server, not the reverse DNS server.
For example, for editing an existing entry:
[jsmith@server ~]$ ipa dnszone-mod --allow-sync-ptr=1 example-zone
The default is
0
, which disables synchronization and has better server performance.
17.6.10. Setting DNS Access Policies
The 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.
Important
If the update policy is set to false, IdM client machines will not be able to add or update their IP address. See Section 17.6.5, “Enabling Dynamic DNS Updates” for more information.
17.6.10.1. Setting DNS Access Policies in the UI
A zone access policy is an access control instruction which sets a general grant or deny rule over a very specific part of the DNS zone. The full statement covers the zone name and how clients are allowed to edit specific records and record types within the zone.
grant|deny zoneName policyName recordName recordType
As with the other DNS zone settings (Section 17.6.2.2, “Editing the Zone Configuration in the Web UI”), the zone transfer configuration is in the Settings tab for the given DNS zone.
The access policies are set in a semi-colon separated list in the BIND update policy text box.
Figure 17.6. DNS Update Policy Settings
The full list of supported record types is in Table 17.2, “DNS Record Types”.
17.6.10.2. Setting DNS Access Policies in the Command Line
When using the command-line tools, the policy is set using the
--update-policy
option, with the access control rule in a statement after it.
--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.The full list of supported record types is in Table 17.2, “DNS Record Types”.
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;"