Configuring DNS

You can configure the Network Registrar DNS server and zones by accepting the system defaults or changing them through the Network Registrar graphical user interface or command-line tool.

This chapter assumes that you have already installed your software by following the instructions in Getting Started with Network Registrar. This chapter describes the Network Registrar DNS server and zone configuration in more detail.

This chapter discusses the following topics:

Creating DNS Zones
Configuring DNS Servers
Configuring DNS Zones

Creating DNS Zones

A zone is a point of delegation in the DNS tree. It contains all the names from a certain point downward, except those that have been further delegated to other zones. A zone delegation point has one or more Name Server (NS) records in the parent zone that should be matched by equivalent NS records at the root of the delegated zone.

The sample company, QuickExample, has registered the domain example.com. Because its parent zone is com., there is an NS record for example.com in the com zone as well as in the example.com zone (Figure 3-1).

Figure 3-1: Registered in Parent Domain

Each zone has one primary server, which loads the zone's contents from a local configuration database. Each zone can also have any number of secondary servers, which load the zone contents by retrieving the data from the primary server (Figure 3-2).

Figure 3-2: Primary and Secondary Name Servers

You can add a zone for which you configure primary or secondary servers. When you configure a name server as the primary server for the zone, you can enter zone data at that time or you can choose to import zone data from an existing BIND data file.

Note If the domain name you specify in the resource records does not have a trailing dot, Network Registrar considers the data to be relative to the current domain. Because Network Registrar stores all names as fully qualified domain names, it will append the current domain name to this name. Remember to specify a trailing dot if you specify the Fully Qualified Domain Name.

Configuring a Zone's Primary Name Server

Programs that store information about the domain name space are called name servers. Name servers usually have complete information about some part of the domain name space, called the zone.

You must configure two types of primary name servers: a primary zone name server and a reverse zone name server. You do not need to create a loopback zone because Network Registrar automatically creates one. 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.

The procedure is the same for all primary name servers; they just differ in the zone name. For example, if your primary zone name server is example.com with the address of 192.168.1.1, then your reverse zone is 1.168.192.in-addr.arpa, and your loopback zone is 127.in-addr.arpa.

Manually Configuring a Primary Name Server

Step 1 Use the zone command to create a primary zone.

The following example adds the zone, example.com, specifying that it is a primary zone and the name server is nameserver and the hostmaster is hostmaster.

nrcmd> zone example.com create primary nameserver hostmaster

Step 2 Use the zone command set to set the values of the zone.

You can accept the defaults or set the remaining values: expiration time, minimum TTL, refresh time, retry time, and serial number. The following are the default values.

nrcmd> zone example.com set expire=604800
nrcmd> zone example.com set minttl=86400
nrcmd> zone example.com set refresh=10800
nrcmd> zone example.com set retry=3600
nrcmd> zone example.com set serial=1

Step 3 Use the zone command addRR to add the Address (A) resource record.

Although the zone command automatically creates the NS and SOA record for you, use the addRR command to create an A record for the name server named in the ns field.

nrcmd> zone example.com addRR nameserver A 192.168.1.1

Step 4 Use the zone command addHost to add hosts.

The following example adds the host bethpc with an IP address of 192.168.1.68.

nrcmd> zone example.com addHost bethpc 192.168.1.68

Importing a Zone Data

The easiest and quickest way to create a primary zone is to import an existing BIND format zone file.

Use the zone command to create a primary zone by importing an existing file that is in BIND format. The following example adds the zone, example.com, specifying that it is a primary zone and to import the BIND file, hosts.local.

nrcmd> zone example.com create primary file=hosts.local

To import your entire named.boot configuration, use the import command.

Configuring a Zone's Secondary Name Server

DNS servers play two roles: they supply name-to-address mapping information for computers on the Internet, and they answer queries for names within their own domain. When you decide to configure a server as a secondary name server, consider whether it will play one or both roles.

When you initially configure a domain, you should choose a primary name server, and at least one secondary server. The secondary server should be geographically removed from the primary server. It should not be on the same network as the primary server. If it is important that the outside world can always reach you, then you should configure several secondary servers to ensure that at least one of them will be able to supply information about the domain at all times.

If you want to reduce the load on the primary server as it answers queries from machines within its domain, you should configure another secondary server. Because the secondary server is preloaded with all the same zone data that the primary server has, it contains all the local data. The local queries are usually for local data.

If you want the secondary server to be authoritative for the zone, create a zone NS record referring to it. Then inform the administrator of the parent domain of the new NS record. If you want the secondary server just to off-load queries from the clients of the primary server, you do not need to make it authoritative for the zone.

Configuring a Secondary Zone

While it is customary to restrict zone transfers for secondary zones, you can also enable or restrict zone transfers for primary zones.

Step 1 Use the zone command to create a secondary zone.

The following example adds the zone, ns1.example.com, whose primary zone's address is 192.168.1.5.

nrcmd> zone ns1.example.com create secondary 192.168.1.5

Step 2 Optionally, use the zone command enable to restrict zone transfers for this particular zone.

nrcmd> zone ns1.example.com enable restrict-xfer

Step 3 Optionally, use the zone command set to indicate which servers are allowed to request a zone transfer from this secondary server.

nrcmd> zone ns1.example.com set
restricted-set=192.168.1.1,192.168.1.20

Adding Additional Name Servers

Use the zone command addRR method to add the NS record with the FQDN (Fully Qualified Domain Name). The following example adds an NS record to the zone for the name server with the name ns4.example.com.

nrcmd> zone example.com addRR example.com ns ns4.example.com

Configuring a Caching-Only Server

Although all servers are caching servers because they save the information received until the data expires, a caching-only server is a server that is not authoritative for any zone. This server answers queries and asks other servers, who have the authority, for the information needed.

When you first install Network Registrar on a system connected to the Internet, it automatically is a caching-only server. It can pose and answer DNS queries about information that it has cached, but is not authoritative, because you have not yet configured any zones.

Creating a Caching-Only Server

Use the dns get command to check that the no-recurse feature is disabled.

nrcmd> dns get no-recurse

Note Because you can have only one DNS server per physical host, if you make this DNS server a caching-only server, you must install another DNS server on another system to be able to create any primary or secondary zones.

Reloading the DNS Server

After you have configured the DNS server, save the data by executing the save command. To make the data live, reload the DNS server.

Saving and Reloading the Server

Step 1 Use the save command to save your changes to Network Registrar's configuration database.

nrcmd> save

Step 2 Use the server command to reload the server.

nrcmd> server DNS reload

Configuring DNS Servers

The dns command lets you enable or disable the DNS server features. Since there is only one DNS server per cluster, you do not need to reference the server by name.

Displaying General Properties

Use the show command to display the DNS server's properties.

nrcmd> dns show

Defining DNS Forwarding Servers

Sites that must limit their network traffic for security reasons, because they pay by the packet, or because the network connection is a slow link, can designate one or more servers to be forwarders for the current server. These servers handle all off-site requests before the local server searches for the answer through the Internet. Over time the forwarders build up a rich cache of data that can satisfy most requests.

Forwarders are useful in the following situations:

To reduce the load on the Internet connection---Forwarders build up a cache and thus reduce the number of requests sent to external name servers and improve DNS performance.
To improve DNS response to repeated queries---Most queries can be answered through the forwarder's cache.
To handle firewalls---Hosts that do not have access to root name servers can send requests to the forwarder that does.

The dns command addForwarder method lets you specify the addresses of any name servers that you want your Network Registrar DNS server to use as forwarders. For example, to add the forwarder server 192.168.1.4, type:

nrcmd> dns addForwarder 192.168.1.4

You may want to restrict the name server even more by stopping it from even attempting to contact an off-site server. Use the dns command slave-mode feature to designate this server as a slave server. For example, to enable slave mode, type:

nrcmd> dns enable slave-mode

Note A slave server is a type of server that uses forwarders exclusively. It answers queries from its authoritative and cache data, but it relies completely on the forwarders for data not in its cache. If the forwarders do not provide an answer, it does not try to contact other servers to find information.

Viewing Current Forwarders

Use the dns command listForwarders method to list all the forwarders for this server.

nrcmd> dns listForwarders

Adding New Forwarders

You can specify multiple forwarders. If the first forwarder does not respond after eight seconds, Network Registrar asks each remaining forwarder in sequence until it receives an answer or until it exhausts the list.

If the DNS server receives no answer, the next step depends on whether you have slave mode on or off.

If you have slave mode on, the DNS server stops searching and responds that the answer cannot be found.
If you have slave mode off, the DNS server sends the query to the domain's designated name servers as if there were no forwarder listed.

You can use the dns command addForwarder method to specify or add a forwarder server. The following example adds the forwarder 192.168.1.4.

nrcmd> dns addForwarder 192.168.1.4

Removing Forwarders

You can use the dns command removeForwarder method to remove forwarders. The following example removes the forwarder 192.168.1.4.

nrcmd> dns removeForwarder 192.168.1.4

Editing Forwarders

To change the IP address of a forwarder, remove the forwarder and add a new one.

Step 1 Use the dns command removeForwarder method to delete the forwarder.

nrcmd> dns removeForwarder 192.168.1.4

Step 2 Use the dns command addForwarder method to add the new forwarder.

nrcmd> dns addForwarder 192.168.1.10

Defining Root Name Servers

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

When Network Registrar gets a response to this root-server query, it caches it just like other response records. Network Registrar uses these cached records as its root-server list. When the cached records expire, Network Registrar 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 are currently six days, so Network Registrar will requery every six days, unless you have specified a lower max. cache TTL value. For more information about TTLs, see the Glossary.

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. The best way to look up the root servers is to ask one of them directly. You can do this by running either the nslookup or the dig command.

Adding a Root Name Server

You can use the dns command addRootHint method to add root name servers. Specify both the name and address of the server.

nrcmd> dns addRootHint a.root-servers.net 198.41.0.4

Note You can add as many names and addresses as you want. It is important to configure only valid root name servers for proper operation. Network Registrar checks that you are entering a valid name and address, and displays an error message if the information is incorrect.

Viewing Root Name Servers

You can use the dns command listRootHint method to view the root name servers.

nrcmd> dns listRootHint

Removing a Root Name Server

Use the dns command removeRootHint method to delete the server.

nrcmd> dns removeRootHint a.root-servers.net

Editing a Root Name Server

To change the name or address of a root server, remove the server and add a new one.

Step 1 Use the dns removeRootHint command to delete the server.

nrcmd> dns removeRootHint a.root-servers.net

Step 2 Use the dns addRootHint command to add the new server.

nrcmd> dns addRootHint b.root-servers.net 198.41.0.4

Specifying the Exception List

You only need to use the exception method to handle your corporation's internal name resolution if you do not want the DNS servers to use the standard resolution method of querying the root name server for certain particular names outside its domain.

Note This facility is also known as Resolution Exception or Intranet Builder.

By specifying the name servers you want DNS to use, Network Registrar can resolve names without resorting to querying the standard root name servers.

For example, the sample company, QuickExample, has four subsidiaries: red, blue, yellow, and green. Each of them has its own domain under the .com domain. When users at red.com want to use resources at blue.com, their DNS server knows that it is not authoritative for blue.com, and attempts to locate blue.com by asking the root name servers.

These queries cause unnecessary traffic, and in some cases fail because internal resources are often barred from external queries or sites that use private networks that cannot be located because their network addresses are not unique. The Network Registrar exception handling solves these problems.

To use exception handling, the administrator at red.com. lists all the domains that users might want to access, and at least one corresponding name server. In this case, the administrator would list the three other domains for the QuickExample company.

Now when a user at red.com wants to access a server at blue.com, the red DNS server queries the specified blue.com's name server instead of querying the root name server.

Adding a Domain Name

Use the dns command addException method to add the exception server.

nrcmd> dns addException blue.com. 192.168.1.4

Viewing Exception Domains

You can use the dns command listExceptions method to view the exception domains.

nrcmd> dns listExceptions

Removing a Domain

Use the dns command removeException method to remove the exception server.

nrcmd> dns removeException blue.com.

Editing a Domain

To change the name or address of a exception server, remove the server and add a new one.

Step 1 Use the dns command removeException method to delete the server.

nrcmd> dns removeException blue.com

Step 2 Use the dns command addException method to add the new server.

nrcmd> dns addException red.com. 192.168.1.4

Setting Options

You can use the dns command to enable or disable DNS server options.

Enabling Recursive Queries

There are two types of queries: recursive and iterative or nonrecursive. DNS clients typically generate recursive queries. When the query is recursive, the name server asks other DNS servers for any nonauthoritative data not in its own cache. When the query is nonrecursive, the name server either answers the query if it is authoritative for the zone, or has the answer in its cache, or tells the client which name server to ask next.

To enable recursive queries, you must disable the no-recurse property.

Use the dns disable command to set the no-recurse property. By default, no-recurse is disabled.

nrcmd> dns disable no-recurse

Enabling Round-Robin

A query may result in multiple resource records of the same name and type being returned. In order to compensate for the fact that most DNS clients start with (and most limit their use to) the first record in the list, you can enable round-robin. This operation causes the Network Registrar DNS server to rearrange the order of the records each time it is queried.

Use the dns enable command to set the round-robin property. By default, round-robin is enabled.

nrcmd> dns enable round-robin

Enabling Subnet Sorting

If you enable subnet sorting (as implemented in BIND 4.9.7), Network Registrar's DNS server checks the network address of the client before responding to a query. If the client, the DNS server, and the target of the query are on the same subnet, and the target has multiple addresses (multiple A records), the server attempts to reorder the address records within the answer by putting the target's closest address first in the response packet. DNS servers always return all a target's addresses, but most clients use the first address and ignore the others.

If you enable both round-robin and subnet sorting, Network Registrar first applies round-robin sorting and then applies subnet sorting. The result is that if you have a local answer it will remain at the top of the list, and if you have multiple local A records, Network Registrar will cycle through them.

Use the dns command to enable or disable the subnet-sorting feature. By default, subnet-sorting is disabled.

nrcmd> dns enable subnet-sorting

Enabling Incremental Transfer (IXFR)

IXFR controls whether or not secondary zones can request incremental transfer from their primary zone.

NOTIFY, which enables the primary zone to inform its secondary zones when changes have been made, can be used in conjunction with IXFR. They they work well together and ensure more efficient zone updates. For more information about IXFR, see RFC 1995.

Use the dns command to enable incremental transfer for all zones for which you have not configured specific behavior. By default, ixfr-enable is enabled.

nrcmd> dns enable ixfr-enable

Use the zone command to disable incremental transfer for a single zone. The value for ixfr is inherited from the dns command ixfr-enable, unless you override it.

nrcmd> zone example.com disable ixfr

Enabling NOTIFY

NOTIFY enables the Network Registrar DNS master (primary zone) to inform its slaves (secondary zones) that changes have been made to its zone. The changes are not communicated in the NOTIFY packet, instead the slaves initiate a zone transfer in response.

Because a master server for a zone does not know specifically which slaves transfer from it, Network Registrar notifies all registered name servers for the zone (name servers listed in the name server Resource Records) when the zone changes. The sole exception to this policy is that Network Registrar does not notify the server named in the SOA mname field (the primary master). For more information about NOTIFY, see RFC 1996.

Use the dns command to send notification for all zones for which you have not configured specific behavior. By default, notify is enabled.

nrcmd> dns enable notify

NOTIFY also notifies the servers you have specified in the notify-set list.

Use the zone command to specify an optional comma-separated list of servers to notify.

nrcmd> zone example.com set notify-set=1.1.1.1,2.2.2.2

Setting Advanced Options

You can use the dns command to set the following advanced options.

Prefetching Glue Records

You can control whether the DNS server, when composing a response to a query, fetches missing glue records. Glue records are informational records that are included in a response to a query. For example, most answers include Name Server (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. Enabling the no-fetch-glue feature tells the server to not query for glue records as it normally would.

Note A glue record is a DNS A (address) record that specifies the address of a subdomain's authoritative name server.

Use the dns command to enable or disable the no-fetch-glue feature. By default, no-fetch-glue is disabled.

nrcmd> dns enable no-fetch-glue

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, the server is referred to a server that in turn refers it to another server for a domain closer to the root (actually farther from the answer).

Note This 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.

Use the dns command to enable or disable the lame-deleg-notify feature. By default, lame-deleg-notify is disabled.

nrcmd> dns enable lame-deleg-notify

Enabling Relaxed Dynamic Update

You can choose to enable relaxation of the RFC 2136 restriction on the dynamic update zone name record. This feature allows the name to be any name within an authoritative zone.

Use the dns command to enable or disable the update-relax-zone-name feature. By default, update-relax-zone-name is disabled.

nrcmd> dns enable update-relax-zone-name

Setting Negative Cache Time

To ensure a quick response to repeated requests for the same information, the DNS server maintains a cache of information it has learned from other DNS servers on behalf of its DNS clients. It also remembers negative information, such as "no such name" or "no such data," that it has learned in the same way. It is important to discard this information at some point to accommodate changes that may occur at the authoritative source. The positive information the server learns is always accompanied by a time-to-live parameter indicating how long it may be considered valid; negative information is not.

The negative cache-time parameter represents the length of time negative information will be considered valid. It should be a relatively short period in order to be responsive to the creation of new data at the authoritative source, yet long enough to serve some value to other clients looking for the same non-existent information, or retries from a single client. The default value is 600 seconds or 10 minutes.

Use the dns command to set the neg-cache-ttl property. You can specify the time in minutes. The default is 10 minutes.

nrcmd> dns set neg-cache-ttl=5m

Setting Maximum Cache TTL

The dns command's max-cache-ttl property enables you to specify the maximum amount of time you want Network Registrar to retain cached information.

Time To Live (TTL) is the amount of time that any name server is allowed to cache data learned from other name servers. Each record that is added to the cache arrives with some TTL value. When the time-to-live period expires, the name server must discard the cached data and get new data from the authoritative name servers the next time information is queried. This parameter limits the lifetime of records in the cache whose TTL values are very large.

Use the dns command to set the max-cache-ttl property. You can specify the time in days. The default is 7 days.

nrcmd> dns set max-cache-ttl=5d

Setting Maximum Memory Cache Size

The mem-cache-size property allows you to specify how much memory space you want to reserve for the DNS name cache. The more memory allocated for the cache, the less frequently the server will access the disk cache. The default is 200 KB. One entry is approximately 100 bytes.

Use the dns command to set the mem-cache-size property. Specify the size in kilobytes. The default is 200 kilobytes.

nrcmd> dns set mem-cache-size=100

Flushing the DNS Cache

You can use the dns flushCache command to stop the disk cache file from growing, but the actual behavior depends on whether your DNS server is running or stopped.

If the DNS server is running, Network Registrar clears all expendable entries from the cache database file. Flushing the cache does not cause the file to shrink in size, due to the nature of the database, but does create free space within it. Because the memory cache is unaffected by this operation, recently in-use cache entries are not lost and performance is not significantly affected.

If the DNS server is stopped, Network Registrar interprets the request to flush all entries and thus removes the cache database file. Network Registrar reinitializes the database when you restart the server.

To completely clear a cache that has grown too large, stop the server, type the command, and restart the server.

Use the dns flushCache command to stop the disk cache file from growing.

nrcmd> dns flushCache

Note If you have added a host and want to look for it by using a query tool, such as nslookup, you may need to flush the cache on the other servers (but not on the server where it was added or on a secondary for the zone) to clear previously cached negative information.

Setting Local and External Port Numbers

If you were experimenting with a new group of name servers, you might want to use nonstandard ports for answering requests and for asking for remote information. The local port and external port settings control which TCP and UDP port the server listens to for name resolution requests, and which port it connects to when making requests to other name servers. The standard values are 53.

Use the dns command to set the local-port-num property. The default is 53.

nrcmd> dns set local-port-num=45

Use the dns command to set the remote-port-num property. The default is 53.

nrcmd> dns set remote-port-num=40

In normal operation, if you change these values, the server will appear to be unavailable.

Setting Debug

You should only need to set debug settings if you have been instructed by Technical Support.

Use the server command to specify the debugging level. The following example provides extensive DNS logging.

nrcmd> server DNS setDebug D=5

To turn off debugging without reloading your server, use the server unsetDebug command.

nrcmd> server DNS unsetDebug

Note If you reboot the DNS server after enabling the debug settings, Network Registrar disables debug. You must enable the debug settings again.

Rebuilding Resource Records Indexes

You may need to rebuild the resource records indexes if you observe resource or host list data that appears inconsistent or if data appears to be missing.

Rebuilding the resource records should correct any inconsistencies.

Use the dns command to rebuild the Resource Record Indexes.

nrcmd> dns rebuildRR-Indexes

Configuring DNS Zones

The zone command lets you add or delete hosts from a zone, specify the authoritative servers for the zone, configure zones for dynamic DNS update, and even edit individual resource records.

Note Remember to reload the DNS server after you have made any changes to the configuration.

Setting Start of Authority

The Start of Authority (SOA) record designates the top of the zone in the DNS inverted-tree namespace. There must be only one SOA record per zone.

When you use the zone command to create a zone, it automatically creates the NS and SOA resource records for you. Use the addRR command to create an A record for the name server named in the ns field.

Setting the Domain Name

Use the zone command to create a primary zone. Specify the zone type (primary or secondary), the values for the name server (ns), and a responsible person.

nrcmd> zone example.com create primary ns andy

Setting the Administrator's E-mail Address

You can use an actual person's e-mail name or use an alias such as hostmaster. In either case, it must be a valid e-mail address for someone who can handle potential problems.

Use the zone command to specify the responsible person. When you create the zone, you must supply this name. You can use the set command to change the name.

nrcmd> zone example.com set person=hostmaster

Setting the Name of the Primary Server

You can specify the relative name and Network Registrar will add the rest of the domain specification, or you can use the fully qualified domain name that ends with a period.

Note You cannot specify an IP address.

Use the zone command to specify the domain name (such as ns.example.com) or just the prefix (such as ns) of the primary name server for this zone.

nrcmd> zone example.com set ns=ns

Setting the Serial Number

A Primary server uses a serial number to indicate when its database has changed. Secondary servers check this serial number to determine whether they must update their zone data. You can only enter a serial number the first time you configure a zone. Thereafter, Network Registrar increments the serial number every time it makes a change to the database.

Use the zone command to specify the serial number of the zone.

nrcmd> zone example.com set serial=100

Note Serial numbers cannot go backwards. Secondary servers assume that a serial number that is greater than the last serial number is newer. You can use any whole number or the current date (but without any punctuation).

Setting the Secondary Refresh Time

The Secondary refresh time is how often a secondary name server checks the primary server for an update. A good value is from one hour to one day, depending on how often you expect to change zone data, and how quickly the secondary servers must notice.

Use the zone command to specify the secondary refresh time. The default is 10800 seconds.

nrcmd> zone example.com set refresh=3600

If you are using 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.

Setting the Secondary Retry Time

The Network Registrar DNS server uses the retry interval between successive failures to check for an update. If the refresh interval expires and an attempt to poll for an update fails, the server will continue attempting to retry until it succeeds. A good value is one-third to one-tenth of the refresh time.

Use the zone command to specify the secondary retry time. The default is 3600 seconds.

nrcmd> zone example.com set retry=4800

Setting the Secondary Expire Time

The Secondary expire time is the longest amount of time that a secondary name server can claim authority for zone data when responding to queries when it has failed to update a zone. The expire interval is the longest amount of time that a secondary name server can claim authority for zone data in responding to queries when it has failed to update a zone. Set this to a large number that provides enough time to survive extended failure of the primary server, such as a week or more.

Use the zone command to specify the expire interval. The default is 604800 seconds.

nrcmd> zone example.com set expire=500000

Setting the Minimum Time To Live

The minttl property is the minimum Time To Live for this zone. Whenever a Resource Record is sent in a response to a query (for which this server is authoritative), the TTL field is set to the maximum of the TTL field from the Resource Record and the minimum field specified here. Thus, the minimum value is a lower bound on the TTL field for all Resource Records in this zone.

Use the zone command to specify the minimum TTL. The default is 86400 seconds.

nrcmd> zone example.com set minttl=3600

Specifying Authoritative Name Servers

Authoritative name servers are responsible for the validity of the data in their zones. Both primary and secondary servers can be authoritative. The crucial difference between them is the location from which they get their zone data. A primary server reads its data from local configuration information, and a secondary server loads its data over the network from another name server.

A zone must have at least one name server. The name servers that you enter must match those specified in the parent domain's delegation for this zone. You can configure the servers to be authoritative for the zone as either primary or secondary servers.

The name servers you list here should be the name servers that you want people outside your organization to query when requesting resolution of names within your zone.

Adding Authoritative Name Servers

Use the zone command addRR to specify an additional authoritative server for this zone. You can optionally specify the TTL.

nrcmd> zone example.com addRR @ 86400 ns ns1.example.com

Viewing Authoritative Name Servers

Use the zone command listRR to display the list of servers for this zone.

nrcmd> zone example.com listRR

Removing Authoritative Name Servers

Use the zone command removeRR to clear the list of servers so that you can specify new servers.

nrcmd> zone example.com removeRR @ ns

Configuring Hosts

You can use the zone command addHost, zone removeHost, and zone listHosts methods to add, remove, and display hosts in a zone.

Adding a Host

Use the zone command addHost method to add hosts to a zone. Specify the hostname and address, and optionally, any aliases.

nrcmd> zone example.com addHost bethpc 192.169.1.15

Removing a Host

Use the zone command removeHost method to remove a host from a zone.

nrcmd> zone example.com removeHost bethpc

Note Removing a host removes all records associated with the host; these include aliases (CNAME), MX records.

Editing a Host

To change host information, remove the host and add a new one.

Step 1 Use the dns removeHost command to delete the host.

nrcmd> dns example.com removeHost bethpc

Step 2 Use the dns addHost command to add the new host information.

nrcmd> dns example.com addHost bethpc 192.169.1.20

Enabling Zone Transfers

There are two types of DNS servers: Primary name servers and secondary servers.

A primary name server gets its authoritative data from its local configuration database.
A secondary server gets its zone data from another name server that is authoritative for the zone, usually the primary name server. A secondary server periodically contacts the name server from which it gets updates and obtains the zone data, if it has changed. This action is called a zone transfer. The interval is defined in the server's SOA record as the secondary refresh time.

You can allow zone transfers to any server that requests zone data, restrict the servers you will allow to perform zone transfers, or prevent all zone transfers.

Note You might want to turn off zone transfers temporarily while you are reconfiguring the site, or if you have no secondary servers.

Restricting Zone Transfers

Use the restrict zone transfers feature either for security reasons or to reduce the load on the primary name server by restricting the servers you will allow to request a copy of the zone data.

Use the zone restrict-xfer feature to restrict zone transfers to a specific set of hosts. The restrict-xfer is disabled by default.

nrcmd> zone example.com enable restrict-xfer

Use the zone restricted-set property to specify the zones that may request zone transfers.

nrcmd> zone example.com set
restricted-set=198.162.1.30,192.168.1.20

Disabling Zone Transfers

Use the disable zone transfers feature either for security reasons or to reduce the load on your primary name server by preventing servers from requesting a copy of your zone data.

Use the zone command disable method to disable zone transfers.

nrcmd> zone example.com disable restrict-xfer

Enabling Dynamic DNS Updates

Dynamic DNS allows the integration of DNS and DHCP. The two protocols are complementary: DHCP centralizes and automates the configuration of IP hosts, including IP addresses, and dynamic DNS update automatically records the association between the IP hosts and their DHCP-assigned addresses.

Using DHCP and dynamic DNS update, a host is automatically configured for network access whenever it attaches to the IP network. The host can be located and accessed using its permanent, unique DNS host name. Mobile hosts, for example, can move freely around on a network without end-user or administrator intervention.

Allowing Updates From DHCP Servers

Use the zone command dynamic feature to enable dynamic updates to the zone. dynamic is enabled by default.

nrcmd> zone example.com enable dynamic

Use the zone dynupdate-set property to specify the list of IP addresses from which dynamic updates will be accepted.

nrcmd> zone example.com set
dynupdate-set=192.168.1.1,127.0.0.1

Note In order for dynamic DNS update to function properly, you must configure the corresponding DHCP scope. For more information, see the "Configuring Dynamic DNS Update" section in the "Configuring DHCP" chapter.

Delegating Subzones

As the zone grows, you might want to divide it into smaller pieces called subzones. You might want to delegate administrative authority for these subzones, and have them managed by people within those zones or served by separate servers. This partitioning is called subzone delegation.

Establish subzone delegation by performing the following tasks:

Choosing a subzone name
Specifying a name server name
Specifying a name server address

Choosing a Subzone Name

After you have decided to divide the zone into subzones, you must create names for them. You should involve the people responsible for the subzone in the naming, and you should try to maintain a consistent naming scheme that makes sense to people outside your organization.

The following are some suggestions for how to avoid naming problems:

Consider not naming a subzone based on its organizational name, because in a changing business environment, organizations are merged and renamed. Naming a subzone after an organization could result in a name that over time is no longer meaningful.
Consider not using geographical names that indicate where the subzone is located. Names based on geographical location are meaningless to people outside your organization and can be difficult to spell.
Do not use cryptic names. Do not choose two-letter names for convenience. Make names obvious.
Do not use existing or reserved top-level domain names as subzones. Using existing names can possibly result in incorrect routing problems.
In choosing a name, keep in mind how often people must remember the name, and how often they will use it. Select a name that is easy to remember and easy to spell.

Specifying a Name Server Name

After you have chosen a name for the subzone, you must specify the hosts that will serve as the subzone's name servers. The information you specify here is what the parent domain's name servers will use when they are queried about the subzone. If you want to ensure that the subzone is always reachable, you should specify two name servers.

These name servers must be configured to be authoritative for this zone as either primary or secondary, otherwise you will have lame delegation.

Note Lame delegation occurs when DNS servers listed in the parent's delegation of a zone do not know that they are authoritative for the zone.

Specifying a Name Server Address

The addresses that are required are ones that could not be learned without knowing the address, for example, any subzone's name servers whose names are in or below the subzone.

Whenever a name server for a subzone changes its name or IP address, its administrator must inform its parent domain so that the parent can change the name server and glue records for the subzone. If the subzone's administrator neglects to inform its parent, the glue records will be invalid.

Note A glue record is the DNS A (address) record that specifies the address of a subdomain's authoritative name server.

The common symptom of an invalid glue record is the inability of a host to access a host in a different domain by its domain name while being able to access that host by its IP address.

Delegating a Subzone

If the name server is in the parent domain or some other domain, add a Name Server (NS) record. If the name server is within the subzone being delegated, you must add a name server.

Use the zone command addRR method to delegate a subzone and add NS and A records.

nrcmd> zone example.com addRR eng NS ns.eng.example.com
nrcmd> zone example.com addRR ns.eng A 192.168.1.5

Removing a Delegated Subzone

After you have removed a subzone, do not forget to remove any glue records that you have added.

Step 1 Use the zone command removeRR method to remove the subzone's NS record.

nrcmd> zone example.com removeRR eng NS

Step 2 Use the zone removeRR method to remove the subzone's A record.

nrcmd> zone example.com removeRR ns.eng A

Editing a Delegated Subzone

To change subzone information, remove the subzone and add a new one.

Step 1 Use the zone removeRR command to delete the subzone.

nrcmd> zone example.com removeRR eng NS
nrcmd> zone example.com removeRR ns.eng A

Step 2 Use the zone addRR command to add the new subzone information.

nrcmd> zone example.com addRR ns.cs-eng ns
cs-eng.example.com.
nrcmd> zone example.com addRR ns.cs-eng A
5.6.7.8

Table of Contents

Configuring DNS