Cisco CNS Network Registrar User's Guide, 6.1
Setting DNS Attributes
Downloads: This chapterpdf (PDF - 246.0KB) The complete bookPDF (PDF - 6.99MB) | Feedback

Setting DNS Attributes

Table Of Contents

Setting DNS Attributes

Setting DNS Server Properties

Setting General Server Properties

Defining Forwarders for Servers

Configuring Caching-Only Servers

Specifying Delegation-Only Zones

Defining Root Nameservers

Specifying Exception Lists

Setting Subzone Forwarding

Enabling Recursive Queries

Enabling Round-Robin

Enabling Subnet Sorting

Enabling Incremental Zone Transfers (IXFR)

Restricting Zone Queries

Enabling NOTIFY

Setting Advanced Server Properties

Setting SOA Time to Live

Setting Secondary Refresh Times

Setting Secondary Retry Times

Setting Secondary Expiration Times

Fetching Glue Records

Reporting Lame Delegation

Setting Maximum Negative Cache Times

Setting Maximum Cache TTLs

Setting Maximum Memory Cache Sizes

Flushing DNS Cache

Handling Rogue Address Records and Other Cache Attributes

Setting Query Source Addresses and Port Numbers

Setting Local and External Port Numbers

Managing DNS Servers

Tuning DNS Properties

Troubleshooting DNS Servers


Setting DNS Attributes


This chapter explains how to set the 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.

Setting DNS Server Properties

You can set properties for the DNS server itself, along with those you already set for its zones.

Setting General Server Properties

You can display DNS general server properties, such as the name of the server's cluster or host machine and the version number of the Network Registrar 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 server's official name. Network Registrar uses the server's IP address for official name lookups and for dynamic DNS (RFC 2136) updates.

In the local cluster Web UI:


Step 1 On the Primary Navigation bar, click Zone.

Step 2 On the Secondary Navigation bar, click DNS Server.

Step 3 Click the name of the server to open the Edit DNS Server page. The page displays all the DNS server attributes.

Step 4 Click Modify Server to modify the attribute.


In the CLI, use the dns [show] command to display the DNS server's properties.

Defining Forwarders for Servers

Sites that must limit their network traffic for security reasons can designate one or more servers to be forwarders that handle all off-site requests before the local server goes out to the Internet. Over time, the forwarders build up a rich data cache that can satisfy most requests.

Forwarders are useful in that they:

Reduce the load on the Internet connection—Forwarders build up a cache and thus reduce the number of requests sent to external nameservers and improve DNS performance.

Improve the DNS response to repeated queries—The forwarder's cache can answer most queries.

Handle firewalls—Hosts that do not have access to root nameservers can send requests to the forwarder that does.


Tip You can restrict the nameserver even more by stopping it from even attempting to contact an off-site server. This kind of server uses forwarders exclusively. It answers queries from its authoritative and cached data, but it relies completely on the forwarders for data not in its cache. If the forwarder does not provide an answer, then the slave mode server does not try to contact other servers.


You can have multiple forwarders. If the first forwarder does not respond after eight seconds, Network Registrar asks each remaining forwarder in sequence until one answers or it gets to the end of the list. If the DNS server does not get an answer, the next step depends on whether you have slave mode on or off:

If slave mode is on, the DNS server stops searching and responds that it cannot find the answer.

If slave mode is off, the DNS server sends the query to the domain's designated nameservers as if there were no forwarders listed.

In the local cluster Web UI, on the Edit DNS Server page, under the Forwarders category, enter the IP addresses of the forwarding servers, click whether you want slave mode enabled or disabled, then click Modify Server.

In the CLI:

To specify the address (or space-separated addresses) of nameservers to use as forwarders, use the dns addForwarder command.

To designate the server as a slave, use the dns enable slave-mode command.

To list the current forwarders, use the dns listForwarders command.

To edit your forwarder list, you must remove any offending forwarder and re-enter another one.

To remove a forwarder or list of forwarders, use the dns removeForwarder command.

Configuring Caching-Only Servers

By definition, all servers are caching servers, because they save the data that they receive until it expires. However, you can create a caching-only server that is not authoritative for any zone. This type of server's only function is to answer queries by storing in its memory data from authoritative servers. The caching-only server can then learn or cache the data to answer subsequent queries. Caching query responses considerably reduces the overhead (and latency) of subsequent queries to these cached records

When you first install Network Registrar, the DNS server automatically becomes a nonauthoritative, caching-only server until you configure zones for it. If you keep the DNS server as a caching-only server, you must have another primary or secondary DNS server somewhere that is authoritative and to which the caching-only server can refer. The caching-only server should never be listed as an authoritative server for a zone.

You must set up a caching-only server to respond to recursive queries, where a server keeps trying to get to an authoritative server so that it can update its cache with the address resolution data. Because Network Registrar servers are recursive by default, you should just verify that this property is set.

In the local cluster Web UI, on the Primary Navigation bar, click Zone. On the Secondary Navigation bar, click DNS Server and the name of the server to open the Edit DNS Server page. Under the Forwarders category, ensure that Recursive queries is set to enabled, then click Modify Server.

In the CLI, use the dns get no-recurse command to find out if nonrecursion is disabled. If not, use the dns disable no-recurse command and reload the server.

Specifying Delegation-Only Zones

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 zone's apex SOA record. This can filter out "wildcard" or "synthesized" data from authoritative nameservers whose undelegated (in-zone) data is of no interest. Enable the DNS server's delegation-only-domains attribute for this purpose.

Defining Root Nameservers

Root nameservers know the addresses of the authoritative nameservers for all the top-level domains. When you first start a newly installed Network Registrar DNS server, it uses a set of preconfigured root servers, called root hints, as authorities to ask for the current root nameservers.

When Network Registrar gets a response to a root server query, it caches it and refers to the root hint list. When the cache expires, the server repeats the process. Because Network Registrar has a persistent cache, it does not need to requery this data when it restarts. The time to live (TTL) on the official root server records is currently six days, so Network Registrar requeries every six days, unless you specify a lower maximum cache TTL value (see the "Setting Maximum Cache TTLs" section).

Because the configured servers are only hints, they do not need to be a complete set. You should periodically (every month to six months) look up the root servers to see if the information needs to be altered or augmented.

In the local cluster Web UI, on the Edit DNS Server page, under the Root Nameservers category, enter the domain name and IP address of each additional root nameserver, then click Modify Server.

In the CLI, use the dns addRootHint command (see the Usage Guidelines for the dns command in the Network Registrar CLI Reference).

Specifying Exception Lists

If you do not want the DNS servers to use the standard resolution method to query the root nameserver for certain names outside its domain, use resolution exception. This bypasses the root nameservers and targets a specific server to handle name resolution.

For example, example.com has four subsidiaries—Red, Blue, Yellow, and Green. Each has its own domain under the .com domain. When users at Red want to access resources at Blue, their DNS server knows that it is not authoritative for Blue and appeals to the root nameservers. These queries cause unnecessary traffic, and in some cases fail because internal resources are often barred from external queries or sites that use unreachable private networks without unique addresses.

Resolution exception solves these problems. Red's administrator lists all the other example.com domains that users might want to reach and at least one corresponding nameserver. When a Red user wants to reach a Blue server, the Red server asks the Blue server instead of querying the root.


Note When resolution exception is configured for a subzone, the resolution exception server is not queried; the subzone NS records are used instead. With no resolution exception defined, when global forwarding is set (see the "Setting Subzone Forwarding" section), any query for the subzone delegation goes to the forwarder, and not to the server that is authoritative for that subzone. However, if you set the subzone-forward attribute to no-forward for a zone, the zone's server is set as the implicit resolution exception server for all the subzones, and any forwarding and explicitly set resolution exceptions are ignored for that zone. Even though defining a resolution exception at a subzone name is a useful way to prevent queries to a specific subzone from being forwarded to the global forwarder, to do this for all subzones of a zone, use the subzone-forward attribute instead.


In the local cluster Web UI, on the Edit DNS Server page, under the Resolution Exceptions category, enter the domain name and IP address or addresses of each excepted nameserver, then click Modify Server. To delete an exception list, click the Delete icon () next to the domain name and IP address or addresses of the nameserver you want to remove, then click Modify Server.

In the CLI:

To add the exception domains and servers, separated by spaces, use the dns listExceptions command and the dns addException command. Use this command only if you do not want your DNS server to use the standard name resolution for names outside the local authoritative zone.

To remove a resolution exception, use the dns removeException command.

To replace a resolution exception, use the dns addException command with the new values. You must also flush the cache so that the server does not refer to the old resolution values in cache.

Setting Subzone Forwarding

For zones with forwarders set (see the "Defining Forwarders for Servers" section), the normal Network Registrar behavior is to ignore delegation to subzone nameservers and forward queries to these forwarding servers instead. You would normally need to set a resolution exception (see the "Specifying Exception Lists" section) to the subzone server. This might be impractical for large numbers of subzones. With the zone's subzone-forward attribute set to no-forward, when the server receives a query for any of its subzones, it tries to find relevant subzone NS records, resolve their corresponding IP addresses, and delegate the query to those IP addresses. The default is normal, for normal subzone forwarding.

Enabling Recursive Queries

There are two types of queries—recursive and iterative (nonrecursive). DNS clients typically generate recursive queries, where the nameserver asks other DNS servers for any nonauthoritative data not in its own cache. With an iterative query, the nameserver answers the query if it is authoritative for the zone, has the answer in its cache, or tells the client which nameserver to ask next. You often want to make a root server iterative instead of recursive. Recursion is like saying, "Let me talk to Bob and get back to you." Iteration is like saying, "Let me direct you to Bob for the information."

In the Web UI, on the Edit DNS Server page, under the Forwarders category, set Recursive queries to enabled, then click Modify Server.

In the CLI, recursion is set by default. To set iterative queries, enable the no-recurse attribute.

Enabling Round-Robin

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 ensures that successive clients resolving the same name will connect to different addresses on a revolving basis. The DNS server then re-arranges 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's A record.


In the local cluster Web UI, on the Edit DNS Server page, under the Miscellaneous Options and Settings category, set the Enable round-robin attribute to enabled, then click Modify Server.

In the CLI, use the dns get round-robin command to see if round-robin is enabled (it is by default). If not, use the dns enable round-robin command.

Enabling Subnet Sorting

If you enable subnet sorting, as implemented in BIND 4.9.7, the Network Registrar DNS server confirms the client's 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 re-order the A records in the response by putting the target's closest address first in the response packet. DNS servers always return all of a target's addresses, 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, Network Registrar first applies round-robin sorting and then applies subnet sorting. The result is that if you have a local answer, it remains at the top of the list, and if you have multiple local A records, the server cycles through them.

In the local cluster Web UI, on the Edit DNS Server page, under the Advanced Options and Settings category, set the Enable subnet sorting attribute to enabled, then click Modify Server.

In the CLI, use the dns enable subnet-sorting or dns disable subnet-sorting (the default) command.

Enabling Incremental Zone Transfers (IXFR)

Incremental Zone Transfer (IXFR, described in RFC 1995) is a protocol that allows only changed data to be transferred between servers. This is especially useful in dynamic environments. IXFR works together with NOTIFY (see the "Enabling NOTIFY" section) to ensure more efficient zone updates.

Primary zone servers always provide IXFR. Explicitly enabling IXFR then provides this function for secondary zone servers, so that it is meaningless to enable it unless a server has no secondary zones. The difference between this global setting and that for the secondary zone is that the global setting is the default value if a secondary zone has no specific setting.

In the local cluster Web UI:


Step 1 On the Edit DNS Server page, under the Zone Defaults category, set the Request incremental transfers (IXFR) attribute to enabled.

Step 2 For a secondary zone, you can also fine tune the incremental zone transfers by setting the Maximum IXFR-only interval (secondary zones) attribute. This is the longest interval to run on IXFRs alone before forcing a full zone transfer (AXFR), usually set to a period such 24 hours or a few days.

Step 3 Click Modify Server.


In the CLI, use the dns enable ixfr-enable command. By default, the ixfr-enable attribute is enabled (see the dns command in the Network Registrar CLI Reference).

Restricting Zone Queries

You can also restrict clients to querying only certain servers based on the source IP address, source network address, or access control list (ACL). The ACL can contain another ACL or a TSIG key (see the "Transaction Security and Access Control Lists" section). The ACL set on the DNS level restrict-query-acl serves as a filter for nonauthoritative queries. If a query is targeted at an authoritative zone, the zone's restrict-query-acl applies. However, if the query targets no authoritative zone, the DNS restrict-query-acl applies.

Enabling NOTIFY

The NOTIFY protocol, described in RFC 1996, lets the Network Registrar DNS primary server inform its secondaries that zone changes occurred. The NOTIFY packet does not indicate the changes themselves, just that they occurred, and this triggers a zone transfer request. Use NOTIFY in environments where the namespace is relatively dynamic.

Because a zone's master server cannot know specifically which secondary server transfers from it, Network Registrar notifies all nameservers listed in the zone's NS records. The only exception is the server named in the SOA primary master field.

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.

In the local cluster Web UI:


Step 1 On the Edit DNS Server page, under the Zone Defaults category, set the Send zone change notification (NOTIFY) attribute to enabled.

Step 2 Set any of the other NOTIFY attributes.

Step 3 Click Modify Server.

Step 4 To add nameservers in addition to those specified in NS records, click Zones on the Secondary Navigation bar.

Step 5 Click the zone name.

Step 6 Add a comma-separated list of servers using the notify-set attribute on the Edit Zone page.

Step 7 Set the notify attribute to true.

Step 8 Click Modify Zone on that page.


In the CLI, use the dns enable notify command. NOTIFY is enabled by default. You can also enable NOTIFY at the zone level, where you can also use the zone name set notify-set command to specify an additional comma-separated list of servers to notify beyond those specified in NS records.

Setting Advanced Server Properties

You can set these advanced server properties:

SOA and secondary server attributes

Prefetch glue records

Report lame delegation

Enable relaxed dynamic update

Set cache time limits and size

Set local and external port numbers

Handle rogue A record queries

Set debug

All of the steps in the following subsections require you to be on the Advanced tab of the DNS Server Properties dialog box.

Setting SOA Time to Live

The SOA record's time to live (TTL) is usually determined by the zone's 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.

Network Registrar 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. Databases originating from versions of Network Registrar earlier than Release 3.5 do not have the defttl zone attribute, and use the minimum TTL in the zone's SOA record for the default TTL.

Normally, Network Registrar assumes the default TTL when responding with a zone transfer with resource records that do not have explicit TTL values. If the default TTL value for the zone is administratively altered, Network Registrar automatically forces a full zone transfer to any secondary DNS server requesting a zone transfer.

In the local cluster Web UI:


Step 1 On the Add Zone or Edit Zone page, set the Zone Default TTL, which defaults to 24 hours.

Step 2 If you wish, 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 nsttl value listed under the attributes. This value also defaults to the Zone Default TTL value.

Step 4 Click Modify Zone.


In the CLI, use the zone name set defttl command, then reload the server.

Setting Secondary Refresh Times

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 the "Enabling NOTIFY" section.

In the local cluster Web UI, on the Add Zone or Edit Zone page, set the Secondary Refresh field to the refresh time, which defaults to three hours. Make any other changes, then click Modify Zone.

In the CLI, use the zone name set refresh command. The default is 10800 seconds (three hours).

Setting Secondary Retry Times

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 default is one hour.

In the local cluster Web UI, on the Add Zone or Edit Zone page, set the Secondary Retry field to the retry time, which defaults to one hour. Make any other changes, then click Modify Zone.

In the CLI, use the zone name set retry command.

Setting Secondary Expiration Times

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 default is seven days.

In the local cluster Web UI, on the Add Zone or Edit Zone page, set the Secondary Expire field to the expiration time, which defaults to seven days. Make any other changes, then click Modify Zone.

In the CLI, use the zone name set expire command.

Fetching Glue Records

A glue record is a DNS A record that specifies the address of a zone's or subzone's authoritative nameserver. It is an informational record in a query response. For example, most answers include NS records, which then cause the inclusion of A records to resolve the NS record name into an address. These A records are the glue records. Disabling the no-fetch-glue attribute tells the server to find records that it would not normally find, so that it can include them in answers to subsequent queries.

In the local cluster Web UI, on the Edit DNS Server page, ensure that Don't fetch missing glue records is set to disabled.

In the CLI, use the dns disable no-fetch-glue command (the default).

Reporting Lame Delegation

Lame delegation occurs when a DNS server listed in the parent's delegation of a zone does not know that it is authoritative for the zone. The server can detect and report this when, in the process of tracking down an answer, it is referred to a server that in turn refers to another server for a domain closer to the root (actually farther from the answer). Lame delegation does not indicate a problem with the DNS configuration, but with the configuration at the DNS server you are querying. You cannot do anything to correct lame delegation at other domains, unless you happen to be authoritative for the domain as well.

Note that setting the Report lame delegations (lame-deleg-notify) attribute has the same effect as setting the DNS log setting lame-delegation.

In the local cluster Web UI, on the Edit DNS Server page, ensure that Report lame delegations is set to enabled.

In the CLI, use the dns enable lame-deleg-notify command (the default).

Setting Maximum Negative Cache Times

To ensure a quick response to repeated requests for the same information, the DNS server maintains a cache of data it learns from other servers on behalf of its clients. This includes negative information, such as "no such name" or "no such data," as specified by RFC 2308. It is important to discard this information at some point to accommodate namespace changes at the authoritative source.

The maximum negative cache time establishes an upper bound on the time a negative cache entry can be valid. This value should be obtained from the SOA record in the negative response. If the originating zone has an abnormally large TTL value, the maximum negative cache time value reduces that value, limiting the time that the entry remains negatively cached. Choose this value carefully to balance the need to eliminate long negative cache entries with the desire to cache negative answers meaningfully.

Note that you can effectively reduce the maximum negative cache time through the maximum cache TTL value, because this value applies to all cache entries, positive and negative. See the "Setting Maximum Cache TTLs" section.

In the local cluster Web UI, on the Edit DNS Server page, set the Max. negative answer caching TTL value; the default is one hour.

In the CLI, use the dns set max-negcache-ttl command (the default is 60 minutes).

Setting Maximum Cache TTLs

The Maximum Cache TTL property specifies the maximum time that you want Network Registrar to retain cached information. TTL is the amount of time that any nameserver is allowed to cache data learned from other nameservers. Each record added to the cache arrives with some TTL value. When the TTL period expires, the server must discard the cached data and get new data from the authoritative nameservers the next time it sends a query. This parameter limits the lifetime of records in the cache whose TTL values are very large. The default value is seven days (604800 seconds).

In the Web UI, on the Edit DNS Server page, set the Max. resource record caching TTL value; the default is one week.

In the CLI, use the dns set max-cache-ttl command.

Setting Maximum Memory Cache Sizes

The maximum memory cache size property specifies how much memory space you want to reserve for the DNS in-memory cache. The more memory that you allocate for the cache, the less frequently the server uses disk cache. The default is 200 KB. One entry is approximately 100 bytes.

In the local cluster Web UI, on the Edit DNS Server page, set the Max. memory cache size value; the default is 200 KB.

In the CLI, use the dns set mem-cache-size command.

Flushing DNS Cache

The Network Registrar cache flushing function lets you stop the disk cache file from growing. However, the actual behavior depends on whether the DNS server is running or stopped. If you flush the cache:

While the server is running, Network Registrar clears all expendable entries from the cache database file. Flushing the cache does not shrink the file because of the nature of the database, but does create free space in it. Because the memory cache is unaffected by this operation, recently used cache entries are not lost, and performance is not significantly affected.

With the server stopped, Network Registrar interprets the request to flush all entries and removes the cache file. It then re-initializes the database when you restart the server.

To clear a cache that grew too large, or when changing a resolution exception, stop the server, enter the command, then restart the server. Stopping the server does not terminate the server process, but stops it from handling further requests. For details on resolution exception, see the "Specifying Exception Lists" section.

This function is not available in the Web UI. In the CLI, use the dns flushCache command.

Handling Rogue Address Records and Other Cache Attributes

You may become victim of a suspicious denial-of-service attack where a rogue host targets Address (A) resource record queries to a caching DNS server. These A record queries contain names that resemble IP addresses. To avoid overloading the DNS server's cache.db file with negative responses from the root, the server no longer tries to resolve these queries. The fake-ip-name-response DNS attribute (Fake Responses for IP address-like names in the Web UI) is enabled by default to effect this. When the server receives a query for a nonauthoritative name, it consults its cached data. If the server cannot answer from cached data, it examines the queried name to see if it resembles an IP address (four decimals each separated by a dot with no trailing or preceding characters). If so, it does not forward the query. Instead, the server sends a response with a NAME ERROR (NXDOMAIN) return code, and does not cache this synthesized negative response.

The server acts on the save-negative-cache-entries (Save negative cache entries to disk in the Web UI) and cache-write-ttl-threshold attributes when it evicts entries from its memory cache to the cache.db file. It typically evicts positive and negative query responses from in-memory cache when the in-memory cache is full and the server needs to inserts a new entry. The server evicts the least-recently-used entry. If you disable save-negative-cache-entries, the server does not store evicted negative entries in the cache.db file, but simply discards them from the in-memory server cache. If the cache-write-ttl-threshold value is non-zero (it is zero by default), the server only persists entries from the in-memory cache to the cache.db file if the entry's TTLs are greater than this value. Otherwise, the server discards the (soon to be, but not yet expired) resource record. A zero value causes the server to always persist unexpired resource records.

In the local cluster Web UI, on the Edit DNS Server page, set Fake responses for IP address-like names to enabled (the default) and Save negative cache entries to disk to disabled (it is enabled by default).

In the CLI, enable the fake-ip-name-response and save-negative-cache-entries attributes, respectively.

Setting Query Source Addresses and Port Numbers

The query source address is the source IP address from which the DNS server should send queries to other servers when resolving names for clients. A value of 0.0.0.0 indicates that the best local address is used based on the destination.

The query source port is the UDP port number from which the DNS server should send queries to other servers when resolving names for clients. A value of zero indicates a random port, which is often used when the server is behind a firewall, and an unset value causes it to be sent from the local port (see the "Setting Local and External Port Numbers" section).

In the local cluster Web UI, on the Edit DNS Server page, set Query source IP address and Query source UDP port attributes.

In the CLI, use the dns set query-source-address and dns set query-source-port commands.

Setting Local and External Port Numbers

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.

In the local cluster Web UI, on the Edit DNS Server page, set Listening port and Remote DNS servers port to different ports than the default value of 53.

In the CLI, use the dns set local-port-num and dns set remote-port-num commands.

Managing DNS Servers

You can manage the DNS server, including viewing its health, statistics, and logs; starting, stopping, and reloading it; and editing the server attributes.

You can view the server status and health, and stop, start, and reload the server. In the local cluster Web UI, on the Primary Navigation bar, click Zone. On the Secondary Navigation bar, click DNS Server. This opens the Manage DNS Server page.


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.


Tuning DNS Properties

Here are some suggestions to tune some of the DNS server properties:

The Notify send min. interval DNS server attribute (notify-min-interval in the CLI)—Minimum interval required before sending notification of consecutive changes on the same zone to a server. The default is two seconds. For very large zones, you might want to increase this value to exceed the maximum time to send an outbound full zone transfer. This is recommended for secondary servers that receive inbound incremental zone transfers and send out full transfers to other secondaries. These include older BIND servers that do not support incremental zone transfers. Inbound incremental transfers may abort outbound full transfers.

The Notify delay between servers DNS server attribute (notify-send-stagger in the CLI)—Interval to stagger notification of multiple servers of a change. The default is one second, but you may want to raise it to up to five seconds if you need to support a large number of zone transfers distributed to multiple servers.

The Notify wait for more changes DNS server attribute (notify-wait in the CLI)—Time to delay, after an initial zone change, before sending change notification to other nameservers. The default is five seconds, but you may want to raise it to 15, for the same reason as given for the notify-min-interval attribute.

The Max. memory cache size DNS server attribute (mem-cache-size in the CLI)—Size of the in-memory record cache, in kilobytes. The default is 200 KB, but you may want to raise it to 1000 KB for larger networks.

The Report lame delegations DNS server attribute (lame-deleg-notify in the CLI)—Network Registrar should notice and log when a DNS server listed in a parent-zone's delegation of subzones does not know that it is authoritative for the zone. This is normally disabled, but you may want to enable it. This attribute has the same effect as setting the log settings to lame-delegation.

The IXFR check box in the Foreign Servers section of the Edit DNS Server page, or the remote-dns address/mask create ixfr command in the CLI—Adding an entry for a server or group of servers allows controlling whether or not IXFR should occur when doing zone transfers from those servers.

Troubleshooting DNS Servers

Useful troubleshooting hints tools to diagnose the DNS server include:

Restoring a loopback zone—A loopback zone is a reverse zone that enables a host to resolve the loopback address (127.0.0.1) to the name localhost. The loopback address is used by the host to enable it to direct network traffic to itself. You can configure a loopback zone manually or you can import it from an existing BIND zone file. (See the Usage Guidelines for the zone command in the Network Registrar CLI Reference.)

Listing the values of the DNS server properties—In the Web UI, on the Primary Navigation bar, click the Zone tab, then on the Secondary Navigation bar, click the DNS Server tab to open the Edit DNS Server page. In the CLI, use the dns show command.

Choosing from the DNS log settings to give you greater control over existing log messages—Use the Log settings attribute on the Edit DNS Server page in the Web UI, or the dns set log-settings command in the CLI with one or more of these keyword or numeric values, separated by commas (see Table 10-1). Restart the server if you make any changes to the log settings.

Table 10-1 DNS Log Settings 

Log Setting
(Numeric Equivalent)
Description

config (1)

Server configuration and de-initialization.

ddns (2)

High level dynamic update messages.

xfr-in (3)

Inbound full and incremental zone transfers.

xfr-out (4)

Outbound full and incremental zone transfers.

notify (5)

NOTIFY transactions.

datastore (8)

Data store processing that provides insight into various events in the server's embedded databases.

scavenge (9)

Scavenging of dynamic resource records (see the "Scavenging Dynamic Records" section).

scavenge-details (10)

More detailed scavenging output (disabled by default).

server-operations (11)

General high-level server events, such as those pertaining to sockets and interfaces.

lame-delegation (13)

Lame delegation events; although enabled by default, disabling this flag could prevent the log from getting filled with frequent lame delegation encounters.

root-query (14)

Queries and responses from root servers.

ddns-refreshes (15)

Dynamic DNS update refreshes for Windows 2000 clients (disabled by default).

ddns-refreshes-details (16)

Resource records refreshed during dynamic DNS updates for Windows 2000 clients (disabled by default).

ddns-details (17)

Resource records added or deleted due to dynamic DNS updates.

tsig (18)

Logs events associated Transaction Signature (TSIG) dynamic DNS updates (see the "Transaction Security and Access Control Lists" section).

tsig-details (19)

More detailed logging of TSIG dynamic DNS updates (disabled by default).

activity-summary (20)

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 the dns set-activity-summary-interval command).

query-errors (21)

Logs errors encountered while processing DNS queries.

config-details (22)

Generates detailed information during server configuration by displaying all configured and assumed server attributes (disabled by default).


Using the nslookup utility to test and confirm the DNS configuration—This utility is a simple resolver that sends queries to Internet nameservers. To obtain help for the nslookup utility, enter help at the prompt after you invoke the command. Use only fully qualified names with a trailing dot to ensure that the lookup is the intended one. An nslookup begins with a reverse query for the nameserver itself, which may fail if the server cannot resolve this due to its configuration. Use the server command, or specify the server on the command line, to ensure that you query the proper server. Use the -debug, or better yet, the -d2, flag to dump the responses and (with -d2) the queries being sent.