This chapter explains how to set the Authoritative DNS server parameters. Before you proceed with the tasks in this chapter, read Managing Zones which explains how to set up the basic properties of a primary and secondary zone.
Access the commands by using the Commands button. Clicking the Commands button opens the DNS Commands dialog box in the local web UI. Each command has its own Run icon (click it, then close the dialog box):
![]() Note | The Synchronize All HA Zones command is an Expert mode command which you can see only if the server is an HA main server. You cannot see this command if it is an HA backup server. You can also, synchronize zones separately, which you can do from the Zone Commands for Zone page (see Synchronizing HA DNS Zones). |
![]() Note | If you find a server error, investigate the server log file for a configuration error, correct the error, return to this page, and refresh the page. |
You can configure the network interfaces for the DNS server from the Manage Servers page in the local web UI.
You can set properties for the DNS server, along with those you already set for its zones. These include:
General server properties—See Setting General DNS Server Properties
Delegation-only zones—See Specifying Delegation-Only Zones
Round-robin server processing—See Enabling Round-Robin
Subnet sorting—See Enabling Subnet Sorting
Enabling incremental zone transfers—See Enabling Incremental Zone Transfers (IXFR)
Enabling NOTIFY packets—See Enabling NOTIFY
![]() Note | To enable GSS-TSIG support, you must set TSIG-Processing to none, and GSS-TSIG processing to 'ddns, query' to support both ddns and query. |
You can display DNS general server properties, such as the name of the server cluster or host machine and the version number of the Cisco Prime IP Express DNS server software. You can change the internal name of the DNS server by deleting the current name and entering a new one. This name is used for notation and does not reflect the official name of the server. Cisco Prime IP Express uses the server IP address for official name lookups and for DNS updates (see the "Managing DNS Update" chapter in Cisco Prime IP Express 8.3 DHCP User Guide).
The following subsections describe some of the more common property settings. They are listed in Setting DNS Server Properties.
Use dns [show] to display the DNS server properties.
You can instruct the server to expect only referrals when querying the specified zone. In other words, you want the zone to contain only NS records, such as for subzone delegation, along with the apex SOA record of the zone. This can filter out “wildcard” or “synthesized” data from authoritative nameservers whose undelegated (in-zone) data is of no interest. Enable the DNS server delegation-only-domains attribute for this purpose.
A query might return multiple A records for a nameserver. To compensate for most DNS clients starting with, and limiting their use to, the first record in the list, you can enable round-robin to share the load. This method ensures that successive clients resolving the same name will connect to different addresses on a revolving basis. The DNS server then rearranges the order of the records each time it is queried. It is a method of load sharing, rather than load balancing, which is based on the actual load on the server.
![]() Tip | Adjust the switchover rate from one round-robin server to another using the TTL property of the server A record. |
On the Manage DNS Authoritative Server page, under the Miscellaneous Options and Settings section, find the Enable round-robin (round-robin) attribute. It is set to enabled by default in Basic mode.
Use cdns get round-robin to see if round-robin is enabled (it is by default). If not, use cdns enable round-robin.
If you enable subnet sorting, as implemented in BIND 4.9.7, the Cisco Prime IP Express DNS server confirms the client network address before responding to a query. If the client, server, and target of the query are on the same subnet, and the target has multiple A records, the server tries to reorder the A records in the response by putting the closest address of the target first in the response packet. DNS servers always return all the addresses of a target, but most clients use the first address and ignore the others.
If the client, DNS server, and target of the query are on the same subnet, Cisco Prime IP Express first applies round-robin sorting and then applies subnet sorting. The result is that if you have a local response, it remains at the top of the list, and if you have multiple local A records, the server cycles through them.
On the Manage DNS Authoritative Server page, in A-Z view, find the Enable subnet sorting (subnet-sorting) attribute, set it to enabled, then click Save.
Use dns enable subnet-sorting or dns disable subnet-sorting (the preset value).
Incremental Zone Transfer (IXFR, described in RFC 1995) allows only changed data to transfer between servers, which is especially useful in dynamic environments. IXFR works together with NOTIFY (see Enabling NOTIFY) to ensure more efficient zone updates. IXFR is enabled by default.
Primary zone servers always provide IXFR. You should explicitly enable IXFR on the server (you cannot set it for the primary zone) only if the server has secondary zones. The DNS server setting applies to the secondary zone if there is no specific secondary zone setting.
On the Manage DNS Authoritative Server page, under the Zone Default Settings section, you can find the Request incremental transfers (IXFR) attribute. It is set it to enabled by default. For a secondary zone, you can also fine-tune the incremental zone transfers by setting the ixfr-expire-interval attribute.
This value is the longest interval the server uses to maintain a secondary zone solely from IXFRs before forcing a full zone transfer (AXFR). The preset value of one week is usually appropriate. Then, click Save.
Use dns enable ixfr-enable. By default, the ixfr-enable attribute is enabled.
You can restrict clients to query only certain zones based on an access control list (ACL). An ACL can contain source IP addresses, network addresses, TSIG keys (see the "Transaction Security" section in Cisco Prime IP Express 8.3 DHCP User Guide), or other ACLs. The restrict-query-acl on the DNS server serves as a default value for zones that do not have the restrict-query-acl specifically set.
The NOTIFY protocol, described in RFC 1996, lets the Cisco Prime IP Express DNS primary server inform its secondaries that zone changes occurred. The NOTIFY packets also include the current SOA record for the zone giving the secondaries a hint as to whether or not changes have occurred. In this case, the serial number would be different. Use NOTIFY in environments where the namespace is relatively dynamic.
Because a zone master server cannot know specifically which secondary server transfers from it, Cisco Prime IP Express notifies all nameservers listed in the zone NS records. The only exception is the server named in the SOA primary master field. You can add additional servers to be notified by adding the IPv4 addresses to the notify-set on the zone configuration.
![]() Note | For NS records that point at names that the DNS server is not authoritative for, those IP addresses need to be explicitly set in the notify-set if the user wants those servers to get notifies. |
You can use IXFR and NOTIFY together, but this is not necessary. You can disable NOTIFY for a quickly changing zone for which immediate updates on all secondaries does not warrant the constant NOTIFY traffic. Such a zone might benefit from having a short refresh time and a disabled NOTIFY.
Step 1 | On the Manage DNS Authoritative Server page, under the Zone Transfer Settings section, find the notify attribute (Expert mode only), then check the Enabled check box to enable it. |
Step 2 | Set any of the other NOTIFY attributes (notify-defer-cnt , notify-min-inverval , notify-rcv-interval , notify-send-stagger , notify-source-address , notify-source-port , and notify-wait ). |
Step 3 | Click Save. |
Step 4 | To add nameservers in addition to those specified in NS records, from the Design menu, choose Forward Zones under the Auth DNS submenu. |
Step 5 | Click the zone in the Forward Zones pane to open the Edit Zone page. |
Step 6 | Add a comma-separated list of IP addresses of the servers using the notify-set attribute on the Edit Zone page. |
Step 7 | Set the notify attribute to true. |
Step 8 | Click Save on that page. |
Use dns enable notify. NOTIFY is enabled by default. You can also enable NOTIFY at the zone level, where you can use zone name set notify-set to specify an additional comma-separated list of servers to notify beyond those specified in NS records.
You can set these advanced server properties:
SOA time-to-live—See Setting SOA Time to Live
Secondary server attributes—See Setting Secondary Refresh Times
Port numbers—See Setting Local and External Port Numbers
Handle Malicious DNS Clients—See Handling Malicious DNS Clients
The SOA record time to live (TTL) is usually determined by the zone default TTL. However, you can explicitly set the SOA TTL, which sets the maximum number of seconds a server can cache the SOA record data. For example, if the SOA TTL is set for 3600 seconds (one hour), an external server must remove the SOA record from its cache after an hour and then query your nameserver again.
Cisco Prime IP Express responds to authoritative queries with an explicit TTL value. If there is no explicit TTL value, it uses the default TTL for the zone, as set by the value of the defttl zone attribute.
Normally, Cisco Prime IP Express assumes the default TTL when responding with a zone transfer with RRs that do not have explicit TTL values. If the default TTL value for the zone is administratively altered, Cisco Prime IP Express automatically forces a full zone transfer to any secondary DNS server requesting a zone transfer.
Step 1 | On the List/Add Zone page, set the Zone Default TTL, which defaults to 24 hours. |
Step 2 | If you want, set the SOA TTL, which is the TTL for the SOA records only. It defaults to the Zone Default TTL value. |
Step 3 | You can also set a TTL value specifically for the NS records of the zone. Set the NS TTL value under Nameservers. This value also defaults to the Zone Default TTL value. |
Step 4 | Click Save. |
Use zone name set defttl.
The secondary refresh time is how often a secondary server communicates with its primary about the potential need for a zone transfer. A good range is from an hour to a day, depending on how often you expect to change zone data.
If you use NOTIFY, you can set the refresh time to a larger value without causing long delays between transfers, because NOTIFY forces the secondary servers to notice when the primary data changes. For details about NOTIFY, see Enabling NOTIFY.
On the List/Add Zone page, set the Secondary Refresh field to the refresh time, which defaults to three hours. Make any other changes, then click Save
Use zone name set refresh. The preset value is 10800 seconds (three hours).
The DNS server uses the secondary retry time between successive failures of a zone transfer. If the refresh interval expires and an attempt to poll for a zone transfer fails, the server continues to retry until it succeeds. A good value is between one-third and one-tenth of the refresh time. The preset value is one hour.
On the List/Add Zone page, set the Secondary Retry field to the retry time, which defaults to one hour. Make any other changes, then click Save.
Use zone name set retry.
The secondary expiration time is the longest time a secondary server can claim authority for zone data when responding to queries after it cannot receive zone updates during a zone transfer. Set this to a large number that provides enough time to survive extended primary server failure. The preset value is seven days.
On the List/Add Zone page, set the Secondary Expire field to the expiration time, which defaults to seven days. Make any other changes, then click Save.
Use zone name set expire.
If you are experimenting with a new group of nameservers, you might want to use nonstandard ports for answering requests and asking for remote data. The local port and external port settings control the TCP and UDP ports on which the server listens for name resolution requests, and to which port it connects when making requests to other nameservers. The standard value for both is port 53. If you change these values during normal operation, the server will appear to be unavailable.
The full list of default ports is included in the "Default Ports for Cisco Prime IP Express Services" section in Cisco Prime IP Express 8.3 Administrator Guide.
On the Manage DNS Authoritative Server page, in A-Z view, find the Listening Port (local-port-num) and Remote DNS servers port (remote-port-num) attributes, set them to the desired values (they are both preset to 53), then click Save.
When trying to resolve query requests, DNS servers may encounter malicious DNS clients. A client may flood the network with suspicious DNS requests. This affects the performance of the local DNS server and remote nameservers.
Using Cisco Prime IP Express, you can resolve this problem by barring malicious clients. You can configure a global ACL of malicious clients that are to be barred, using the blackhole-acl attribute.
On the Manage DNS Authoritative Server page, expand Miscellaneous Options and Settings to view various attributes and their values. For the blackhole-acl attribute value, enter, for example, 10.77.240.73. Then click Save.
Here are some tips to tune some of the DNS server properties:
When Cisco Prime IP Express is deployed in small-sized LANs, you can run both the Caching DNS and Authoritative DNS servers on the same operating system, without the need for two separate virtual or physical machines.
This configuration is feasible only for smaller networks where it may be difficult to add and maintain a standalone Caching DNS server. To enable this configuration, you must have:
At least two interfaces-one each for the Caching DNS and the Authoritative DNS servers.
Hybrid-mode configuration enabled on the Authoritative DNS server.
![]() Note |
|
When the hybrid-mode configuration is enabled, the Caching DNS server detects the Authoritative DNS server on the same operating system and configures the in-memory exceptions for the Authoritative DNS server zones. Hybrid-mode configuration entails the following:
The Caching DNS server reloads whenever the Authoritative DNS server is reloaded.
![]() Note | When both the Caching DNS and the Authoritative DNS servers are run on a single operating system, the required memory needs to be doubled to support both servers. In addition, there should enough, dedicated, disk space for the Authoritative DNS zones, RRs, and the additional log files. For more information, see the Installation Requirements section in Cisco Prime IP Express Installation Guide. |
Step 1 | To configure
the network interfaces on the Authoritative and the Caching DNS servers, do the
following:
| ||||
Step 2 | To enable the hybrid-mode configuration on the Authoritative server, do the following: | ||||
Step 3 | Reload the Authoritative DNS server to enable the hybrid-mode configuration. |
Use dns set hybrid-mode=enabled to enable the hybrid-mode configuration on the Authoritative DNS server.
DNS firewall controls the domain names, IP addresses, and name servers that are allowed to function on the network. This enables Internet Service Providers (ISP), enterprises, or organizations to define lists of FQDNs, IP addresses, subnets and prefixes of end nodes, and configure rules to secure the network by redirecting the resolution of DNS name away from known bad domains or non-existing domains (NXDOMAIN).
Every query to a Caching DNS server is first verified against the list of DNS firewall rules in the order of priority. To ensure that the caching DNS server redirects queries for non-existing or known bad domains, you can create DNS firewall rules. The DNS firewall rule comprises of a priority, an ACL, an action, and a list of domains and takes precedence over exceptions and forwarders. You can configure the following actions for these queries:
Drop - Drops the resource record query.
Refuse - Responds with no data and the REFUSED status.
Redirect - Redirects A or AAAA queries to the specified IP address.
Redirect-nxdomain - Redirect to a specific A or AAAA address if the queried domain does not exist.
RPZ - Use Response Policy Zones (RPZ) rules.
When a resource record query matches the criteria of rule, the specified action is taken. If the resource record query action results for redirect-nxdomain, the query is performed in the normal process and if it results in an NXDOMAIN status, then it is redirected to the specified destination.
![]() Note | The firewall rules such as Drop, Refuse, Redirect, and the RPZ query-name trigger take place before regular query processing and therefore take precedence over forwarders and exceptions. The other actions and triggers are applied during or after regular query processing. |
The DNS firewall rules can be set up for specially designated zones on the Authoritative DNS server. The RPZ and RR data combined with DNS resolver effectively creates a DNS Firewall to prevent misuse of the DNS server. The RPZ firewall rule comprises of a trigger (query-name, ip-answers, ns-name, and ns-ip) and a corresponding action.
The RPZ firewall rules utilize both the Authoritative DNS and the Caching DNS servers to provide the RPZ functionality. The Authoritative DNS server stores the data for RPZ and the rules whereas the Caching DNS server takes the client queries and applies these rules.
![]() Note | If the RPZ comes via zone transfer it must be named the same as at the source. If using a commercial RPZ provider, the name is specified by the provider. |
RPZ Trigger |
RR Name |
Example |
Example RR Name |
Domain being queried |
<domain>.rpz. <customer-domain> |
Domain www.baddomain.com |
www.baddomain.com.rpz.cisco.com |
Name Server to query |
<ns-domain-name>.rpz- nsdname.rpz.<customer-domain> |
Name Server ns.baddomain.com |
ns.baddomain.com.rpz-nsdname.rpz. cisco.com |
Name Server IP to query |
32.<reversed-ip>.rpz-nsip.rpz. <customer-domain> |
Name Server Address 192.168.2.10 |
32.10.2.168.192.rpz-nsip.rpz.cisco.com |
Name Server IP to query |
32.<reversed-ip>.rpz-nsip.rpz. customer-domain> |
Name Server Address 2001:db8:0:1::57 |
128.57.zz.1.0.db8.2001.rpz-nsip.rpz.cisco.com |
A Records in Answer Section of Response |
32.<reversed-ip>.rpz-ip.rpz. <customer-domain> |
A answer record 192.168.2.10 |
32.10.2.168.192.rpz-ip.rpz.cisco.com |
A Records in Answer Section of Response |
<subnet-mask>.<reversed-ip>. rpz-ip.rpz.<customer-domain> |
A answer record in subnet 192.168.2.0/24 |
24.0.2.168.192.rpz-ip.rpz.cisco.com |
AAAA Records in Answer Section of Response |
128.<reversed-ip>.rpz-ip.rpz. <customer-domain> |
AAAA answer record 2001:db8:0:1::57 |
128.57.zz.1.0.db8.2001.rpz-ip.rpz.cisco.com |
AAAA Records in Answer Section of Response |
<prefix-length>.<reversed-ip>. rpz-ip.rpz.customer-domain> |
AAAA answer record in prefix 2001:db8.0.1::/48 |
27.zz.1.0.db8.2001.rpz-ip.rpz.cisco.com |
![]() Note | rpz-ip, rpz-nsdname, and rpz-nsip are just another label and is not a real subdomain or separate zone. No delegation points will exist at this level and CDNS relies on finding all the data within the referenced zone. |
![]() Note | When using rpz-nsdname and rpz-nsip, the corresponding rule is applied to the original query and will therefore change the answer section. In cases when the final answer is determined from the RPZ rule(s), the rpz zone SOA will be included in the authority section. |
When the Caching DNS server is configured to use RPZ, it queries the Authoritative DNS server to lookup the RPZ rules. The Caching DNS server formulates the correct query name, interprets the query response as an RPZ rule, and applies the rule to the client query. If the RPZ rule causes Caching DNS server to rewrite the client response, this data is cached to make future lookups faster. The Caching DNS server RPZ configuration determines which RPZ trigger should be used. If no RPZ rule is found, the query proceeds normally.
In addition, RPZ overrides can be configured on the Caching DNS server. This enables the Caching DNS server to override the RPZ action returned by the Authoritative DNS server. This is useful when you do not have control over the Authoritative DNS data as is the case when the data is pulled from a third party. When the Caching DNS server gets a match from the Authoritative DNS server for the RPZ query, it performs the override action rather than the rule action specified in the RR data.
RPZ rules are created using standard DNS RRs, mostly CNAME RRs. However, for redirecting you can use any type of RR. The RR name follows the format based on the RPZ trigger as described in the DNS RPZ Zones section. The rdata defines the rule action to be taken. The following table describes the RPZ actions.
RPZ Rule Action |
RPZ RR RData |
RPZ RR Example |
NXDOMAIN |
CNAME . |
www.baddomain.com.rpz.cisco.com. 300 CNAME . |
NODATA |
CNAME *. |
www.baddomain.com.rpz.cisco.com. 300 CNAME *. |
NO-OP (whitelist) |
CNAME rpz-passthru. CNAME FQDN |
www.gooddomain.com.rpz.cisco.com. 300 CNAME rpz-passthru. www.gooddomain.com.rpz.cisco.com. 300 CNAME www.gooddomain.com. |
DROP |
CNAME rpz-drop. |
www.baddomain.com.rpz.cisco.com. 300 CNAME rpz-drop. |
Redirect |
<any RR type> <redirect-data> |
www.wrongdomain.com.rpz.cisco.com. 300 CNAME walledgarden.cisco.com. www.baddomain.com.rpz.cisco.com. 300 A 192.168.2.10 www.baddomain.com.rpz.cisco.com. 300 AAAA 2001:db8:0:1::57 |
Step 1 | From the Design menu, choose DNS Firewall under the Cache DNS submenu to open the List/Add DNS Firewall Rules page. | ||
Step 2 | Click the Add DNS Firewall Rule icon in the DNS Firewall pane to open the Add DNS Firewall dialog box. | ||
Step 3 | Enter a rule
name in the Rule Name field and specify the action type.
| ||
Step 4 | Click
Add DNS
Firewall to save the firewall rule. The List/Add DNS Firewall Rules page
appears with the newly added firewall rule.
| ||
Step 5 | If you
selected the
drop or
redirect
action:
| ||
Step 6 | If you
selected the
rpz
action:
| ||
Step 7 | Click
Save to
save your settings, or click Revert to cancel the changes .
|
Use the following CLI commands to:
When you create a set of DNS firewall rules, you can specify the priority in which order the rules will apply. To set the priority or reorder the rules:
Step 1 | From the Design menu, choose DNS Firewall under the Cache DNS submenu to open the List/Add DNS Firewall Rules page. |
Step 2 | Click the Reorder DNS Firewall Rules icon in the DNS Firewall pane to open the Reorder dialog box. |
Step 3 | Set the priority for the DNS Firewall rules by either of the following methods: |
Step 4 | Click Save to save the reordered list. |
Useful troubleshooting hints and tools to diagnose the DNS server and ways to increase performance include:
DNS Attribute |
7.0 Preset Value |
7.1 Preset Value |
Recommended Setting |
---|---|---|---|
axfr-multirec-default |
on |
on |
on |
mem-cache-size |
10000 (KB) |
50000 (KB) |
50000 (KB) |
For many of these attributes, you must enter Expert mode in the web UI or use set session visibility=3 in the CLI. To change the preset value to the current one, unset the attribute. To change to the recommended setting, change the attribute value.
Be sure to reload the DNS server after saving the settings.
Log Setting |
Description |
---|---|
config |
Server configuration and deinitialization. |
ddns |
High level dynamic update messages. |
xfr-in |
Inbound full and incremental zone transfers. |
xfr-out |
Outbound full and incremental zone transfers. |
notify |
NOTIFY transactions. |
datastore |
Data store processing that provides insight into various events in the server embedded databases. |
scavenge |
Scavenging of dynamic RRs (see the Scavenging Dynamic Records section in Cisco Prime IP Express 8.3 DHCP User Guide). |
scavenge-details |
More detailed scavenging output (disabled by default). |
server-operations |
General high-level server events, such as those pertaining to sockets and interfaces. |
ddns-refreshes |
DNS update refreshes for Windows clients (disabled by default). |
ddns-refreshes-details |
RRs refreshed during DNS updates for Windows clients (disabled by default). |
ddns-details |
RRs added or deleted due to DNS updates. |
tsig |
Logs events associated with Transaction Signature (TSIG) DNS updates (see the Transaction Security section in Cisco Prime IP Express 8.3 DHCP User Guide). |
tsig-details |
More detailed logging of TSIG DNS updates (disabled by default). |
activity-summary |
Summary of activities in the server. You can adjust the interval at which these summaries are taken using the activity-summary-interval attribute, which defaults to five-minute intervals (you can adjust this interval using dns set activity-summary-interval). |
query-errors |
Logs errors encountered while processing DNS queries. |
config-details |
Generates detailed information during server configuration by displaying all configured and assumed server attributes (disabled by default). |
incoming-packets |
Incoming data packets. |
outgoing-packets |
Outgoing data packets. |
xfer-in-packets |
Incoming full zone transfer (XFR) packets. |
query-packets |
Incoming query packets. |
notify-packets |
NOTIFY packets. |
ddns-packets |
DNS Update packets. |
xfer-out-packets |
Outgoing XFR packets. |
ha-details |
Generates detailed logging of High-Availability (HA) DNS information. |
scp |
Allows log messages associated with SCP message handling. |
optRR |
Causes logging related to OPT RR processing. |
ha-messages |
Enables detailed logging of HA messages. |
Although dig is normally used with command-line arguments, it also has a batch mode of operation for reading lookup requests from a file. Unlike earlier versions, the BIND9 implementation of dig allows multiple lookups to be issued from the command line. Unless you specifically query a specific name server, dig tries each of the servers listed in /etc/resolv.conf. When no command line arguments or options are given, dig performs an NS query for the root ".". A typical invocation of dig looks like: dig @server name type where server is the name or IP address of the name server to query.