DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 
Configuring Domain Name System (DNS) servers

Configuring Domain Name System (DNS) servers

You can use the Berkeley Internet Name Domain (BIND) service to create and maintain a distributed host name and address database for computers on your network. BIND Version 9 is currently supported.

If you use BIND, you need not update every computer's /etc/hosts file each time you add a computer to the network. Instead, a Domain Name System (DNS) server adds the new computer to its host name database and answers queries from DNS clients on the local network and (if connected) outside networks or the Internet.

Your system is configured by default to use the network hosts file /etc/hosts found on each computer. You may want to configure and use DNS instead if:

In previous releases, configuring a DNS name server required you to edit the DNS configuration and other database files. This required you to have a thorough knowledge of the format of these files and how they interact with one another. UnixWare includes the DNS Manager which provides a graphical administrative interface that you can use to create and maintain the DNS configuration files.

The complementary Client Manager allows you to configure a system as a client of DNS name service.

For more information about administering name servers, see ``BIND 9 Administrator's Guide'' and the references in ``For more about DNS''.

How DNS works

DNS uses a client/server architecture to maintain and distribute host names and IP addresses on networks ranging from small local area networks to the entire Internet. Under DNS, the Internet consists of a hierarchy of domains. This hierarchy, referred to as the ``domain name space'', is organized as an inverted tree radiating from a single root, much like a UNIX filesystem:

Domain name space

The ``root domain'', ``.'', is the base of the tree. Final attempts to resolve names to IP addresses take place here if lower-level servers do not have the requested data. The root domain is usually omitted from domain names. For example, ``volga.rivers.mynet.com.'' is usually written as ``volga.rivers.mynet.com'', that is, without the trailing ``.''. Usually this doesn't affect looking up IP addresses, however the ``.'' is usually vital when configuring DNS data.

A ``domain'' is a subset of the domain name space. The mynet.com and acme.com domains share the com portion of their domain name because they both lie within the com domain. Thus all domains are effectively part of the root domain.

A ``subdomain'' or ``child domain'' is a domain that branches off another. For example, in the diagram rivers.mynet.com, seas.mynet.com and lakes.mynet.com are subdomains of mynet.com. All domains except the root domain are therefore subdomains of another domain.

A DNS ``master name server'' is a computer that maintains host name and address databases for one or more zones. Zones usually also have ``slave'' name servers which act as backup servers should the master name server be unreachable or down.

A ``zone'' is a portion of the domain name space that is served by a master name server and one or more slave name servers. Depending on how the person responsible for administering a zone has configured it, a zone may correspond to an entire domain, a domain with all of its subdomains, or a portion of a domain. In the diagram, the zones in mynet.com correspond to the subdomains rivers.mynet.com, seas.mynet.com, and lakes.mynet.com plus the portion of the mynet.com domain that excludes these subdomains. Each of these zones is assigned its own master name server which maintains zone information for its assigned portion of mynet.com. Compare this with acme.com where a single master name server maintains the zone information for the entire domain including its subdomains rumba.acme.com, samba.acme.com, and tango.acme.com.

A ``client'' is a networking program running on any machine which needs to find information about a host. The ping, rlogin, and telnet utilities are examples of clients. Usually, a client wants to discover the IP address associated with a given host name. How a client actually obtains the information depends on how its host machine is configured to obtain (or ``resolve'') host names to IP addresses. One way to resolve host names is to use DNS but it is also possible to obtain IP addresses from the /etc/hosts file or from an NIS map. The latter methods are only really suitable for a small-scale LAN or WAN.

The Internet domain structure

The Internet domain name space is divided into several organizational and geographical top-level domains. Top-level non-geographic domains include:


COM
commercial organizations

EDU
educational organizations

GOV
government organizations

INT
international organizations

MIL
military departments

NET
networking organizations

ORG
miscellaneous organizations
The top-level domains are shown here in upper case. In fact, domain names are case-insensitive. That is, the COM domain is equivalent to the com domain and is usually written in lower case.

Although the three-letter top-level domains are primarily intended for use by companies and organizations in the United States, domain names in COM, EDU, INT, NET, and ORG are often allocated to companies and organizations in other countries.

Geographical top-level domains generally follow the ISO 3166 standard, which contains abbreviations for each country (for example, ca for Canada, ch for Switzerland, and it for Italy). An exception is the domain uk (United Kingdom) which is used for Great Britain rather than the value gb defined by the standard.

DNS domain names and host names

DNS domain names are structured as a listing, from left to right, of the domain name space traced from the host to the root. For example, in the DNS name volga.mynet.com., the host, volga, appears in the domain mynet.com., which is a subdomain of com., which is a domain under the root ``.''.


NOTE: The root domain is indicated by a trailing period or ``dot'' in a domain name. Its specification is usually unnecessary. For example, you never hear ``dot com'' referred to as ``dot com dot''. However, when configuring DNS, it is necessary to specify the root domain to prevent the current domain origin being appended.

The diagram below compares the domain naming scheme to UNIX pathnames.

The domain naming scheme and UNIX pathnames are similar in the following ways:

However, note that the domain naming scheme differs from UNIX pathnames in the following ways:

DNS resolution

Resolution occurs when a client queries a name server to obtain the IP address with which it wants to connect. If a name server in the local domain cannot resolve a client's request, it queries other servers to locate a server that can.

There are two types of resolution:

Iterative queries

By default, a name server queries ``iteratively'' (or non-recursively). This means that it queries several name servers in turn until it finds an answer. It starts by consulting a known name server within the domain hierarchy that contains the destination machine. If it does not already know of a suitable server to ask, it first asks a server in the root domain. Each server responds by referring to a name server in the domain name hierarchy that is closer to the one containing the destination machine. The local server then repeats its query to the name server whose name and IP address it has just been given. In this way, the local server traverses the domain name space until it reaches a name server for the domain that contains the destination machine. This name server should be able to provide the IP address of the destination machine. ``Obtaining an IP address by iterative query'' illustrates how a client in the domain reseau.co.fr might obtain the IP address of the remote host missouri.rivers.mynet.com.

Obtaining an IP address by iterative query

The steps taken to resolve missouri.rivers.mynet.com to its IP address are:

  1. The local client asks the local name server for the IP address of missouri.rivers.mynet.com.

  2. The local name server does not know the IP address of missouri.rivers.mynet.com. It also does not know the IP address of the name servers for rivers.mynet.com or mynet.com so it asks a root name server for the IP address of missouri.rivers.mynet.com.

  3. The root name server does not know the IP address of missouri.rivers.mynet.com, but it does know the IP address of the name server for mynet.com so it tells this to the local name server.

  4. The local name server asks mynet.com's name server for the IP address of missouri.rivers.mynet.com.

  5. mynet.com's name server does not know the IP address of missouri.rivers.mynet.com, but it does know the IP address of the name server for rivers.mynet.com so it tells this to the local name server.

  6. The local name server asks rivers.mynet.com's name server for the IP address of missouri.rivers.mynet.com.

  7. rivers.mynet.com's name server is authoritative for its zone so it can supply the IP address of missouri.rivers.mynet.com

  8. The local name server passes the IP address of missouri.rivers.mynet.com to the local client.
The first time that the local client asks for the IP address of missouri.rivers.mynet.com, it receives the ``authoritative'' answer that the local name server discovered from the name server for rivers.mynet.com. Local clients that subsequently ask for the missouri's IP address will probably receive the ``non-authoritative'' answer stored in the cache of the local name server. This will disappear from the cache when it has been there at least as long as the time-to-live value that was returned along with the data, or when the named daemon is next stopped.

Recursive queries

In a recursive query, a name server behaves like a client and asks another name server to either provide it with the answer to its query, or to return an error because it cannot supply an answer. Unlike an iterative query, the name server that is queried will not reply with a referral to a different name server.

A name server that specifies one or more ``forwarders'' will forward recursive queries to these before trying to find the answer itself by iterative query to other name servers including those in the root domain. You would normally specify forwarders if you want to reduce the cost of access to an off-site network such as the Internet. The forwarder machines would build up a significant cache of information that, over time, would reduce the need to access an external name server.

Forwarders can also be used by name server hosts that are not permitted to have direct access to off-site networks or the Internet. Such hosts are usually on local networks that are isolated from the outside world by a ``firewall'' router. A firewall prevents potentially dangerous packets from having access to an organization's networks. In such a situation, the firewall should be configured to allow only the name servers that are named as forwarders to query external name servers.

If a name server is also configured in ``forward-only'' or ``slave'' mode, it is only allowed to use its forwarders to resolve queries.


NOTE: Some name servers, such as those for the root domain, are configured only to respond iteratively to queries. This prevents their caches becoming polluted with data for which they are not authoritative. For this reason, such servers cannot act as forwarders, nor can they answer queries by DNS clients.

DNS name server types

The SCO implementation of DNS supports the following server configuration types:


NOTE: You will probably need to configure all systems on your network as name service clients regardless of whether you also configure them as name servers.

Master name servers

A master name server is authoritative for one or more DNS zones. Each server maintains its data in database files, and may transfer this data periodically to a slave server if one exists in the zone.

When a server answers a client request, it attaches an expiration (specified by the time-to-live variable) for the data after which the data is considered invalid. The time-to-live variable is specified in the SOA (Start of Authority) resource record contained in the zone's database file.

Master name servers should be machines that are reliable and have excess memory and disk storage space.

A server may serve as a master server for one or more zones and as a slave server for other zones. ``An example of a master name server'' shows an example of a name server that is master for mynet.com but slave for its children rivers.mynet.com and seas.mynet.com.

An example of a master name server

The master server reads the configuration file, /etc/named.conf, to determine which zones are served and in which zone files the data is stored.

See ``Configuring a host as a name server'' for instructions on how to configure a master name server using the DNS Manager.


NOTE: In previous releases of BIND, master name servers were termed ``primary name servers''.

Slave name servers

A slave name server functions as a backup to the master server, should the master be unreachable or down. It maintains a copy of the zone file (the host database for the zone) and, at a specified interval defined by the refresh variable, retrieves the contents of the master's file. If it cannot reach the master for a refresh, it tries again at intervals defined by the retry variable and, if it cannot reach the master within the time specified by the expire variable, the data is flushed. ``An example of a slave name server'' shows an example of a master name server supported by a single slave name server.

An example of a slave name server

When a slave server answers a client request, it attaches an expiration for the data (specified by the time-to-live variable) after which the data is considered invalid. The time-to-live value is specified in the SOA (Start of Authority) resource record contained in the zone's database file.

A server may serve as a slave for one or more zones and a master for others.

See ``Configuring a host as a name server'' for instructions on how to configure a slave name server using the DNS Manager.


NOTE: In previous releases of BIND, slave name servers were termed ``secondary name servers''.

Stub servers

If a master name server delegates a portion of the domain name space, such as a child zone (subzone), it needs to maintain information about the servers in that child zone. For example, the master server in the domain mynet.com needs to be aware of the name servers in rivers.mynet.com and seas.mynet.com. It can do so in two ways: by either serving rivers.mynet.com and seas.mynet.com as a slave name server, or by serving them as a ``stub name server'' as shown in ``An example of a stub name server''.

An example of a stub name server

A stub server only maintains records needed to locate name servers of a delegated child zone. It does not maintain a full database of address (and other) records for the subzone. This allows the administrators of the child zone to move or alter their name servers without altering the parent zone's configuration files, provided the address listed in the stub line is still valid. Configuring the master server for a zone as stub server for its child zones prevents it incurring the overhead of having to perform regular zone transfers with them.

See ``Configuring a host as a name server'' for instructions on how to configure a stub name server using the DNS Manager.

Caching-only name servers

A caching-only name server saves data in a cache file until the data expires. Expiration occurs based on a ``time-to-live'' field attached to data received from another server. The server answers data from its cache if it has the information, or requests it from authoritative servers if it does not.

Caching-only servers may make use of forwarders, servers with connections to outside networks that build up a large database of data. In this case, the caching-only server first queries a forwarder (rather than following its default resolution process), which in turn queries other servers, if necessary, to find the desired data. This limits traffic outside the zone to traffic to and from the forwarders. If the forwarder does not answer, the caching-only server tries the master server for its zone.

If not configured to only use forwarders, a caching-only server may ask name servers outside its zone (including root domain servers) to help answer queries.

If a caching-only server is configured only to use its forwarders, it will not query any other servers. The resolver running on the same machine may be configured to query other servers but any replies will not be added to the local cache.

See ``Configuring a host as a name server'' for instructions on how to configure a caching-only name server using the DNS Manager.


NOTE: From version 8 of BIND onward, caching-only name servers are also referred to as ``hint name servers''.

Setting up new domains

If you intend to create a new domain and you want to attach it below a domain server on the Internet outside your local network, you must register the domain with the appropriate organization to avoid giving it a name that already exists (``name space collision''). For information on registering a new domain name, see ``Obtaining a domain name and an IP network number''

If the domain you are creating is a subdomain of an existing local domain, contact the responsible person listed in the SOA (Start of Authority) record for the existing domain. You can use commands such as nslookup and dig to obtain SOA records.

Once you have established the name of the domain(s) that you will administer, configure a master name server for each zone within the domain(s). Additionally, you should configure slave name servers for each zone to provide name service in the event that the master name server fails. Note that a machine can be a master name server for more than one zone but there can be only one master name server for each zone.

Virtual domains

A ``virtual domain'' is a domain that partially or wholly encompasses one or more systems within another domain, but which appears to be a separately existing domain as seen by other domains. In this way, e-mail, FTP and Web services for different virtual domains (corresponding to separate departments, organizations, or companies) can be hosted and administered on the same system. To users in one of these domains, it appears that these services available within their domain are provided independently of those in the other domains.


NOTE: As for any domain, you must register a virtual domain if it will be a direct subdomain of a top-level Internet domain such as com.

``A host server for several domains'' shows an example where a host with IP address 192.168.10.1 on the network 192.168.10/24 (that is, a network address of 192.168.10.0 with subnet mask 255.255.255.0) is required to provide e-mail, FTP and Web services for two domains: alpha.com and bravo.com.

A host server for several domains

The host's IP address is already listed in the zone files for the mynet.com domain. It would be an error for it also to be listed in the zone files for alpha.com and bravo.com because these have different network addresses (192.168.12/24 and 192.168.33/24).

A host which is present in multiple domains needs to have unique IP addresses in each domain. To achieve this, use the ifconfig(1Mtcp) command to create ``alias'' addresses for one or more existing network interfaces as described in step 1 of the procedure listed in UNRESOLVED XREF-0.


NOTE: The alias address must correspond to the network address that you have registered for the domain.

``Aliasing IP addresses to create virtual domains'' shows how alias addresses are used to set up the virtual domains on the host.

Aliasing IP addresses to create virtual domains

In the alpha.com domain, the host system's address has been aliased to 192.168.12.1 on network 192.168.12/24. In the bravo.com domain, the alias address has been set to 192.168.33.1 on network 192.168.33/24.

On the DNS zone files on the master server, the host system could be assigned the same name (using A and PTR records) in each domain, for example: www.mynet.com, www.alpha.com, and www.bravo.com. Alternatively, it could be assigned different names, such as mach1.mynet.com, mbase.alpha.com, and mclan.bravo.com. Using CNAME records, the host could also be assigned alias names by which it is also known in each domain.

In UnixWare® 7, the following networking applications can make use of virtual domains:


FTP server
See ``Configuring FTP virtual domains'' for information on how to configure anonymous FTP for different virtual domains.

sendmail
See UNRESOLVED XREF-0 for more information on how to configure mail users for different virtual domains.

Netscape FastTrack Server(TM)
See ``Setting up software virtual servers'' in the online Netscape FastTrack Server Adminstrator's Guide for more information on how to set up web servers for different virtual domains.


NOTE: By default, the name server daemon, named(1Mtcp), binds to all interface addresses that have been defined on a system. This means that it is possible for named to run out of file descriptors if the system hosts many virtual domains. The named option listen-on may be used to specify one IP address for each interface in addition to the loopback address, for example:
listen-on { 192.168.12.1; 127.0.0.1; };
This will force named to bind only to these addresses. See named.conf(4tcp) for more information.

Name service clients

A machine running client software can be configured to handle resolution using DNS, /etc/hosts, or NIS, or some combination of these three methods in a specified order.

If DNS is used, the IP addresses of the DNS name servers are configured in the /etc/resolv.conf file. A client can nominate itself (using the localhost or loopback address, 127.0.0.1) as a name server if it is configured as a DNS name server. Remote DNS name service only should be configured if a computer has limited memory or CPU power. In this case, all queries will be answered by a name server running on another computer on the network. In practice, however, you will obtain better performance by configuring the local machine as a caching-only name server. The resolver invoked by client programs does not cache replies because these programs tend to be short lived. Because a name server caches replies, all clients can take advantage of the data in its cache. Having a local name server avoids network traffic and propagation delays on subsequent queries to resolve the same IP addresses or host names.

The minimal configuration of the /etc.resolv.conf file to allow a host to perform a DNS look up on itself is:

   nameserver	127.0.0.1


WARNING: For correct operation of the DNS Manager and other SCOadmin managers on a host that you are configuring remotely, there must also be an entry for the localhost address (127.0.0.1) in the /etc/hosts file on the remote host.

See ``The Client Manager interface'' for instructions on how to configure a name service client using the Client Manager.

DNS utilities and daemons

The following daemon and utilities form the heart of DNS operations:


named
This daemon must be running for DNS to be operational on all but remote servers. After you enable your server, named is invoked each time your system enters multiuser mode. It reads information found in the configuration file, named.conf(4tcp), and takes appropriate actions: priming the cache, accessing zone files, and so on. named can also be invoked from the command line; see named(1Mtcp) for more information.

named-xfer
This command enables you to transfer a DNS zone from one server to another in asynchronous mode so that named can continue processing requests. See the manual page for named-xfer(1Mtcp) for more information.

nslookup
This command allows you to request DNS information, including names, addresses, and other resource records, from any server you can reach from your computer. You can use nslookup to request a single record or start an nslookup session to request multiple records from one or more servers. See nslookup(1Mtcp) or ``BIND 9 Administrator's Guide'' for more information.

dig
This command is similar to nslookup but with a slightly different syntax. See dig(1Mtcp) for more information.

host
This command is useful for finding out information about individual or multiple hosts. See host(1Mtcp) for more information.

Administering a DNS name server

Configuring a DNS name server consists of setting up /etc/inet/named.conf and other files. UnixWare provides the DNS Manager as a convenient way of setting up and maintaining these files for master, slave, and stub name servers, or for servers that provide a mixture of these services.


WARNING: For correct operation of the DNS Manager and other SCOadmin managers on a host that you are configuring remotely, there must be an entry for the localhost address (127.0.0.1) in the /etc/hosts file on the remote host.

See ``The Client Manager interface'' for instructions on how to configure a name service client using the Client Manager.

If you choose not to use the DNS Manager or the Client Manager, you must edit the configuration files yourself:

For full command line instructions, see the ``BIND 9 Administrator's Guide''.

The DNS Manager interface

You can start the DNS Manager in any of these ways:

For more information on using SCOadmin managers, see ``Administering your system with SCOadmin''.

With the DNS Manager, you can:


NOTE: The DNS Manager is intended for setting up zone files from new. It will read and preserve the contents of existing zone files in most cases but it does not understand the $include directive or types of resource record other than A, CNAME, HINFO, MX, NS, PTR, RP, and TXT.

You will not be able to use the DNS Manager to configure DNS on a remote host unless the remote host's name is locally resolvable to an IP address using an /etc/hosts entry, DNS, or NIS.


Configuring a host as a name server


NOTE: If you exit the DNS Manager and the host is not currently configured as a DNS name server, you are asked if you want to configure it as a caching-only server. This allows you to quickly set up a system as a caching-only name server.

To configure a host as a name server for a zone using the DNS Manager:

  1. Select Zones -> Add.

  2. Select the type of server that the host machine will act as for this zone; Caching-only, Master, Slave, or Stub.


    NOTE: You do not need to supply any other information to configure a caching-only server. If required, you can specify the use of forwarders and other server features as described in ``Setting general preferences for name service''.

    If you want to configure a caching-only name server as any other type of name server, you must first remove this configuration by selecting Zones -> Delete.


  3. Enter the name of the zone.


    NOTE: As recommended by RFC 952, a component of the zone name (delimited by dots (.)) can be composed of alphabetic characters (a-z or A-Z without regard to case), digits (0-9), and minus signs (-). Each component must start with an alphabetic character and must not end with a minus sign. Space, tab and underscore characters (_) may not be used in the name.

  4. Enter the IP address of each network in the zone, and click on Add to add it to the list.

  5. For a master server, click on Start of Authority to define the SOA resource record for the zone. The fields are:

    Person in charge
    Enter the mail address of the administrator who is responsible for the zone. The address must be in DNS form using ``.'' instead of ``@'' to delimit the username from the remainder of the address.

    Refresh rate
    The interval in seconds that a slave name server should wait before checking with the master name server to see if it needs to update its zone data.

    Transfer retry
    The time in seconds that a slave name server will wait before retrying a failed zone transfer.

    Expire
    The maximum time in seconds that a slave name server is to use the data before it expires for lack of being refreshed.

    Time-to-live
    The default time in seconds for which data in resource records remains valid on slave name server. This value may be overridden by a time-to-live value (ttl) in the record itself.


    NOTE: The time-to-live assigned to records and to the zone is very important. A high value leads to low network traffic and fast response time, while lower values generate additional traffic but allow faster propagation of changes. As a general guideline, set the minimum time-to-live to three days (259200 seconds). If your zone is very stable, consider setting the value even higher.

    If you need to propagate changes more quickly, reduce the time-to-live several days before making the changes, then restore it to its previous values after making your changes.

    Only changes and deletions are affected by the time-to-live value; propagation of additions is governed by the refresh rate.


    All fields except Person in charge have default values. Click on OK to accept the values.


    NOTE: The DNS Manager automatically increments the serial number in the SOA record whenever it changes a zone's data.

  6. Click on Name servers, then click on Add to define the name servers for the zone: For each name server, enter its host name and IP address, then click on OK. When you have added all the name servers to the list, click on OK.

  7. Define optional resource records for the zone as described in ``Zone resource records''. These records define the default mail exchangers, the zone administrator, information about the server machine, and a description of the zone.


    NOTE: You can only define these records for a master server's zone.

  8. Define the hosts and networks that can request zone transfers for the zone.


    NOTE: You can only define permitted requesters for a master server's zone.

  9. When you have finished configuring the zone, click on OK to view the list of configured zones for this server, then click on OK again.
You can now add resource records for each host in the zone as described in ``Defining the host resource records for a zone''.

Zone resource records

Using the DNS Manager, you can define resource records to hold the following information about a zone:

Entering information about the name server host

To enter a description of the hardware and operating system of the host machine for the name server:

  1. If you are not already entering information about a zone, select the zone from the list of those defined, and select Zones -> Modify.

  2. Click on Host info.

  3. Enter details of the hardware and operating system of the machine that is host for the name server.

  4. Click on OK.

Defining the zone administrator

To define the person responsible for administering a zone:

  1. If you are not already entering information about a zone, select the zone from the list of those defined, and select Zones -> Modify.

  2. Click on Owner.

  3. Enter the mail address of the administrator who is responsible for the zone. The address must be in DNS form using ``.'' instead of ``@'' to delimit the username from the remainder of the address.

  4. Enter the domain name that contains the free-text resource record (TXT) that describes the responsible person.

  5. Click on OK.

Defining the mail exchangers for a zone

To define the default mail exchangers for a zone:

  1. If you are not already entering information about a zone, select the zone from the list of those defined, and select Zones -> Modify.

  2. Click on Mail exchangers.

  3. For each mail exchanger in a zone, enter its host name, then click on Add to add it to the list.

  4. The order of the mail exchangers determines their priority with the most preferred being at the top of the list.

    To increase a mail exchanger's priority, select it and then click on Promote.

    To decrease a mail exchanger's priority, select it and then click on Demote.

  5. Click on OK to exit.

Entering information about the zone

To enter a short free-text description of the zone:

  1. If you are not already entering information about a zone, select the zone from the list of those defined, and select Zones -> Modify.

  2. Click on Description.

  3. Enter the description of the zone.

  4. Click on OK.

Defining the host resource records for a zone

Using the DNS Manager, enter the host resource records (A) for a zone on a master name server as follows:

  1. If you are not already viewing the list of hosts in a zone, select the zone from those listed, and then View -> Records.

  2. There are two ways of adding host records:

  3. You can now add optional resource records for a host as described in ``Optional host resource records''.

Optional host resource records

Using the DNS Manager, you can define resource records to hold the following information about a host:

Defining aliases for a host

To define alternative names for a host:

  1. If you are not currently entering the details for a host, select the host from those listed for the zone, then select Records -> Modify.

  2. Click on Aliases.

  3. For each alternative name by which a host is known, enter the host name, then click on Add to add it to the list.

  4. Click on OK to exit.

Defining the mail exchangers for a host

To define the default mail exchangers for a host:

  1. If you are not currently entering the details for a host, select the host from those listed for the zone, then select Records -> Modify.

  2. Click on Mail exchangers.

  3. For each mail exchanger that a host can use, enter its host name, then click on Add to add it to the list.


    NOTE: If you specify the full domain that the mail exchanger is in, you must specify a dot (.) at the end of the name, for example:
    mailhub.mynet.com.
    

  4. The order of the mail exchangers determines their priority with the most preferred being at the top of the list.

    To increase a mail exchanger's priority, select it and then click on Promote.

    To decrease a mail exchanger's priority, select it and then click on Demote.

  5. Click on OK to exit.

Entering a description of the host

To enter a description of the hardware and operating system of the name server:

  1. If you are not currently entering the details for a host, select the host from those listed for the zone, then select Records -> Modify.

  2. Click on Host info.

  3. Enter details of the hardware and operating system of the host machine.

  4. Click on OK.

Entering other information about the host

To enter a short free-text description of the host:

  1. If you are not currently entering the details for a host, select the host from those listed for the zone, then select Records -> Modify.

  2. Click on Description.

  3. Enter the description of the host.

  4. Click on OK.

Defining the host administrator

To define the person responsible for administering a host:

  1. If you are not currently entering the details for a host, select the host from those listed for the zone, then select Records -> Modify.

  2. Click on Owner.

  3. Enter the mail address of the administrator who is responsible for the host. The address must be in DNS form using ``.'' instead of ``@'' to delimit the username from the remainder of the address.

  4. Enter the domain name that contains the free-text resource record (TXT) that describes the responsible person.

  5. Click on OK.

Modifying the configuration of a zone

To modify the configuration of a zone defined on a name server:

  1. If you are not already viewing the list of configured zones in the DNS Manager, select View -> Zones.

  2. Select the zone that you want to reconfigure, then select Zones -> Modify.

  3. Change the name, type, networks and name servers defined for the zone as required. If the type of server is Master, you can also change the Start of Authority resource record, and optional resource records defined for the zone.

  4. When you have finished configuring the zone, click on OK.

Examining hosts that are configured for a zone


NOTE: The DNS Manager only displays information for zones for which the host is the master name server. Other name server types such as slave, stub, and caching-only do not maintain resource records for a zone.

To examine the hosts that are configured for a zone, select the zone from the list displayed by the DNS Manager, then select View -> Records.

If you are currently examining host records for a different zone, select View -> Zones. Select the zone from the list displayed by the DNS Manager, and then select View -> Records.

To search for a host among those displayed, select View -> Search. Enter a host name or an IP address and click on OK.

You can change how the information about a zone is displayed in the following ways:

Setting general preferences for name service

The following preferences may be defined and apply to all services (master, slave, or stub) provided by a name server:

Selecting name servers to use as forwarders

To select the forwarders for a name server:

  1. Select Server -> Forwarders.

  2. Select whether only forwarders should be used to resolve queries (slave mode).

  3. For each name server that will receive forwarded queries, enter its IP address and click on Add to add it to the list.

  4. Click on OK to exit.

Selecting name servers to be ignored

To select name servers to which queries should not be sent:

  1. Select Server -> Bad servers.

  2. For each name server to be ignored, enter its IP address and click on Add to add it to the list.

  3. Click on OK to exit.

Selecting hosts and networks that can request zone transfers

To define name server hosts and networks that can request zone transfers from a master name server:

  1. Select Server -> Requesters.

  2. For each server or network, enter its IP address and click on Add to add it to the list.

  3. Click on OK to exit.


NOTE: You can override the global list of allowed requesters for an individual zone on its master name server.

To define name server hosts and networks that can request zone transfers for an individual zone:

  1. If you are not already entering information about the zone, select the zone from the list of those defined, and select Zones -> Modify.

  2. Click on Requesters.

  3. For each server or network, enter its IP address and click on Add to add it to the list.

  4. Click on OK to exit.

Setting limits on the operation of the name server

To set limits on the operation of a name server:

  1. Select Server -> Limits.

  2. You can change the values of the following fields:

    Transfer limit inbound
    This controls the maximum number of inbound zone transfers that can be run concurrently on a slave name server. The default value is 10. You may want to set this value higher if your server acts as a slave name server to many zones, but this may adversely impact its performance by demanding extra memory and network resources.

    Transfer limit outbound
    This value will be used by a future release of BIND to limit the maximum number of concurrent outbound zone transfers that can be run on a master name server. At present, it is ignored.

    Transfer per name server
    This controls the number of simultaneous zone transfers from a single name server that can be started on a slave name server. The default value is 2. You can set this value higher if your server needs to pull information about many zones from a single name server but this may adversely affect the performance of both servers.

    Data segment size
    This controls the maximum amount of virtual memory that the name server can allocate to store authoritative and cached data. The default value is 64MB. This limit may be too small for dedicated name servers with more than 64MB of physical memory.

  3. Click on OK to save the changes.

Setting options on the behavior of the name server

To set advanced options on the behavior of a name server:

  1. Select Server -> Options.

  2. You can adjust the behavior of the name server using the following fields:

    Recursion
    If set to Yes (default), the name server will try to answer recursive queries and will cache non-authoritative data that it discovers. If set to No, the name server will try to answer with a referral to another name server rather than the actual data whenever it receives a query for a name for which it is not authoritative. This is used to stop an authoritative server's cache from growing in size or becoming polluted with non-authoritative data.


    NOTE: Do not set this option to No on a server that clients will use for name service.


    Fetch glue
    If set to Yes (default), the name server will fetch missing ``glue'' records when constructing a response. Glue records are A records that a zone stores for the name servers in its subdomains. These records allow the name server to respond to queries for the IP addresses of the servers in the subdomains. If set to No, the name server will not fetch missing glue. This can be used in conjunction with Recursion set to No to prevent a name server's cache from growing in size or becoming polluted with non-authoritative data which may be incorrect.


    NOTE: Do not set this option to No on a server that clients will use for name service.


    Query log
    If set to Yes, log all queries via syslog. If set to No (default), do not log queries.


    NOTE: Setting this option to Yes can quickly create a large file.

  3. Click on OK to save the changes.

Controlling and configuring the name server

You can perform the following tasks in the DNS Manager to control the operation and configuration of the name server:

Defining default resource records for a zone

Default resource records can be defined to hold the following information about a zone:

These records will be used to complete the resource records for zones that you configure subsequently on a master name server. The details entered do not affect existing resource records for zones.

BIND 9 Administrator's Guide

You can configure and administer your DNS server from the command line instead of using the DNS Manager. Full details on using the command line interface is provided in the BIND 9 Administrator's Guide, provided by the Internet Software Consortium.

BIND 9.1.0 Notes

The sections below contain the software notes that are delivered with the BIND 9.1.0 source from the Internet Software Consortium (ISC).

DNSSEC Release Notes

This document summarizes the state of the DNSSEC implementation in this release of BIND9.

Key Generation and Signing

The tools for generating DNSSEC keys and signatures are now in the bin/dnssec directory. Documentation for these programs can be found in doc/arm/Bv9ARM.4.html and the man pages.

The random data used in generating DNSSEC keys and signatures comes from either /dev/random (if the OS supports it) or keyboard input. Alternatively, a device or file containing entropy/random data can be specified.

Serving Secure Zones

When acting as an authoritative name server, BIND9 includes KEY, SIG and NXT records in responses as specified in RFC2535.

Response generation for wildcard records in secure zones is not fully supported. Responses indicating the nonexistence of a name include a NXT record proving the nonexistence of the name itself, but do not include any NXT records to prove the nonexistence of a matching wildcard record. Positive responses resulting from wildcard expansion do not include the NXT records to prove the nonexistence of a non-wildcard match or a more specific wildcard match.

Secure Resolution

Basic support for validation of DNSSEC signatures in responses has been implemented but should still be considered experimental.

When acting as a caching name server, BIND9 is capable of performing basic DNSSEC validation of positive as well as nonexistence responses. This functionality is enabled by including a "trusted-keys" clause in the configuration file, containing the top-level zone key of the the DNSSEC tree.

Validation of wildcard responses is not currently supported. In particular, a "name does not exist" response will validate successfully even if it does not contain the NXT records to prove the nonexistence of a matching wildcard.

Proof of insecure status for insecure zones delegated from secure zones works when the zones are completely insecure. Privately secured zones delegated from secure zones will not work in all cases, such as when the privately secured zone is served by the same server as an ancestor (but not parent) zone.

Handling of the CD bit in queries is now fully implemented. Validation is not attempted for recursive queries if CD is set.

Secure Dynamic Update

Dynamic update of secure zones has been implemented, but may not be complete. Affected NXT and SIG records are updated by the server when an update occurs. Advanced access control is possible using the "update-policy" statement in the zone definition.

Performance of Cryptographic Operations

The cryptographic primitives used by the BIND 9 DNSSEC implementation are based on the OpenSSL library. A version of that library is integrated into the distribution, but for portability reasons this version does not make use of any platform-specific assembly language routines.

On many platforms, particularly i386 and SPARC, a significant improvement in signing and verification speed can be achieved linking BIND 9 with a separate OpenSSL library that uses hand-optimized assembly language routines. To do this, you need to install OpenSSL version 0.9.5a or newer separately from the BIND 9 tree prior to building BIND 9, using the default openssl configuration settings which will cause it to be built with assembly language routines. Then specifying the "--with-openssl" option to the BIND 9 configure script to make BIND 9 link against the system openssl library rather than its own. For example, if openssl was installed under /usr/local, use "configure --with-openssl=/usr/local".

IPv6-related notes

Currently, there are multiple interesting problems with ipv6 implementations on various platforms. These problems range from not being able to use ipv6 with bind9 (or in particular the ISC socket library, contained in libisc) to listen-on lists not being respected, to strange warnings but seemingly correct behavior of named.

COMPILE-TIME ISSUES

The socket library requires a certain level of support from the operating system. In particular, it must follow the advanced ipv6 socket API to be usable. The systems which do not follow this will currently not get any warnings or errors, but ipv6 will simply not function on them.

These systems currently include, but are not limited to: AIX 3.4 (with ipv6 patches).

RUN-TIME ISSUES

In the original drafts of the ipv6 RFC documents, binding an ipv6 socket to the ipv6 wildcard address would also cause the socket to accept ipv4 connections and datagrams. When an ipv4 packet is received on these systems, it is mapped into an ipv6 address. For example, 1.2.3.4 would be mapped into ffff::1.2.3.4. The intent of this mapping was to make transition from an ipv4-only application into ipv6 easier, by only requiring one socket to be open on a given port.

Later, it was discovered that this was generally a bad idea. For one, many firewalls will block connection to 1.2.3.4, but will let through ffff::1.2.3.4. This, of course, is bad. Also, access control lists written to accept only ipv4 addresses were suddenly ignored unless they were rewritten to handle the ipv6 mapped addresses as well.

In bind9, we always bind to the ipv6 wildcard port for both TCP and UDP, and specific addresses for ipv4 sockets. This causes some interesting behavior depending on the system implementation of ipv6.

IPV6 Sockets Accept IPV4, Specific IPV4 Addresses Bindings Fail

The only OS which seems to do this is linux. If an ipv6 socket is bound to the ipv6 wildcard socket, and a specific ipv4 socket is later bound (say, to 1.2.3.4 port 53) the ipv4 binding will fail.

What this means to bind9 is that the application will log warnings about being unable to bind to a socket because the address is already in use. Since the ipv6 socket will accept ipv4 packets and map them, however, the ipv4 addresses continue to function.

The effect is that the config file listen-on directive will not be respected on these systems.

IPV6 Sockets Accept IPV4, Specific IPV4 Address Bindings Succeed

In this case, the system allows opening an ipv6 wildcard address socket and then binding to a more specific ipv4 address later. An example of this type of system is Digital Unix with ipv6 patches applied.

What this means to bind9 is that the application will respect listen-on in regards to ipv4 sockets, but it will use mapped ipv6 addresses for any that do not match the listen-on list. This, in effect, makes listen-on useless for these machines as well.

IPV6 Sockets Do Not Accept IPV4

On these systems, opening an IPV6 socket does not implicitly open any ipv4 sockets. An example of these systems are NetBSD-current with the latest KAME patch, and other systems which use the latest KAME patches as their ipv6 implementation.

On these systems, listen-on is fully functional, as the ipv6 socket only accepts ipv6 packets, and the ipv4 sockets will handle the ipv4 packets.

RELEVANT RFCs

2373: IP Version 6 Addressing Architecture

2553: Basic Socket Interface Extensions for IPv6

draft-ietf-ipngwg-rfc2292bis-01: Advanced Sockets API for IPv6 (draft)

BIND 8 to BIND 9 Migration Notes

BIND 9 is designed to be mostly upwards compatible with BIND 8, but there is still a number of caveats you should be aware of when upgrading an existing BIND 8 installation to use BIND 9.

Configuration File Compatibility

Unimplemented Options and Changed Defaults

BIND 9.1 supports most, but not all but not of the named.conf options of BIND 8. For a complete list of implmented options, see doc/misc/options.

If your named.conf file uses an unimplemented option, named will log a warning message. A message is also logged about each option whose default has changed unless the option is set explicitly in named.conf.

In particular, if you see a warning message about the default for the "auth-nxdomain" option having changed, you can suppress it by adding one of the following lines to the named.conf options { } block:

      auth-nxdomain no;	# conform to RFC1035
      auth-nxdomain yes;	# do what BIND 8 did by default
Handling of Configuration File Errors

In BIND 9, named refuses to start if it detects an error in named.conf. Earlier versions would start despite errors, causing the server to run with a partial configuration. Errors detected during subsequent reloads do not cause the server to exit.

Errors in master files never cause the server to exit.

Logging

The set of logging categories in BIND 9 is different from that in BIND 8. If you have customized your logging on a per-category basis, you need to modify your logging statement to use the new categories.

Another difference is that the "logging" statement only takes effect after the entire named.conf file has been read. This means that when the server starts up, any messages about errors in the configuration file are always logged to the default destination (syslog) when the server first starts up, regardless of the contents of the "logging" statement. In BIND 8, the new logging configuration took effect immediately after the "logging" statement was read.

Case sensitivity

In BIND 9, ACL names are case sensitive. In BIND 8 they were case insensitive.

Notify messages and Refesh queries

The source address and port for these is now controlled by "notify-source" and "transfer-source", respectively, rather that query-source as in BIND 8.

Multiple Classes

Multiple classes have to be put into explicit views for each class.

Zone File Compatibility

Strict RFC1035 Interpretation of TTLs in Zone Files

BIND 8 allowed you to omit all TTLs from a zone file, and used the value of the SOA MINTTL field as a default for missing TTL values.

BIND 9 enforces strict compliance with the RFC1035 and RFC2308 TTL rules. The default TTL is the value specified with the $TTL directive, or the previous explicit TTL if there is no $TTL directive. If there is no $TTL directive and the first RR in the file does not have an explicit TTL field, the error message "no TTL specified" is logged and loading the zone file fails.

To avoid problems, use a $TTL directive in each zone file.

Periods in SOA Serial Numbers Deprecated

Some versions of BIND allow SOA serial numbers with an embedded period, like "3.002", and convert them into integers in a rather unintuitive way. This feature is not supported by BIND 9; serial numbers must be integers.

Handling of Unbalanced Quotes

TXT records with unbalanced quotes, like 'host TXT "foo', were not treated as errors in some versions of BIND. If your zone files contain such records, you will get potentially confusing error messages like "unexpected end of file" because BIND 9 will interpret everything up to the next quote character as a literal string.

Handling of Line Breaks

Some versions of BIND accept RRs containing line breaks that are not properly quoted with parentheses, like the following SOA:

   	@	IN SOA	ns.example. hostmaster.example.
   			( 1 3600 1800 1814400 3600 )
This is not legal master file syntax and will be treated as an error by BIND 9. The fix is to move the opening parenthesis to the first line.
Unimplemented BIND 8 Extensions

$GENERATE: The "$$" construct for getting a literal "$" into a domain name is deprecated. Use "\$" instead.

Interoperability Impact of New Protocol Features

BIND 9 uses EDNS0 (RFC2671) to advertise its receive buffer size. It also sets an EDNS flag bit in queries to indicate that it wishes to receive DNSSEC responses; this flag bit usage is not yet standardized, but we hope it will be.

Most older servers that do not support EDNS0, including prior versions of BIND, will send a FORMERR or NOTIMP response to these queries. When this happens, BIND 9 will automatically retry the query without EDNS0.

Unfortunately, there exists at least one non-BIND name server implementation that silently ignores these queries instead of sending an error response. Resolving names in zones where all or most authoritative servers use this server will be very slow or fail completely. We have contacted the manufacturer of the name server in case, and they are working on a solution.

Unrestricted Character Set

BIND 9 does not restrict the character set of domain names - it is fully 8-bit clean in accordance with RFC2181 section 11.

It is strongly recommended that hostnames published in the DNS follow the RFC952 rules, but BIND 9 will not enforce this restriction.

Historically, some applications have suffered from security flaws where data originating from the network, such as names returned by gethostbyaddr(), are used with insufficient checking and may cause a breach of security when containing unexpected characters; see <http://www.cert.org/advisories/CA-96.04.corrupt_info_from_servers.html> for details. Some earlier versions of BIND attempt to protect these flawed applications from attack by discarding data containing characters deemed inappropriate in host names or mail addresses, under the control of the "check-names" option in named.conf and/or "options no-check-names" in resolv.conf. BIND 9 provides no such protection; if applications with these flaws are still being used, they should be upgraded.

Server Administration Tools

The "ndc" program has been replaced by "rndc", which is capable of remote operation. Unlike ndc, rndc requires a configuration file; see the man pages in doc/man/bin/rndc.1 and doc/man/bin/rndc.conf.5 for details. Some of the ndc commands are still unimplemented in rndc.

No Information Leakage between Zones

BIND 9 stores the authoritative data for each zone in a separate data structure, as recommended in RFC1035 and as required by DNSSEC and IXFR. When a BIND 9 server is authoritative for both a child zone and its parent, it will have two distinct sets of NS records at the delegation point: the authoritative NS records at the child's apex, and a set of glue NS records in the parent.

BIND 8 was unable to properly distinguish between these two sets of NS records and would "leak" the child's NS records into the parent, effectively causing the parent zone to be silently modified: responses and zone transfers from the parent contained the child's NS records rather than the glue configured into the parent (if any). In the case of children of type "stub", this behavior was documented as a feature, allowing the glue NS records to be omitted from the parent configuration.

Sites that were relying on this BIND 8 behavior need to add any omitted glue NS records, and any necessary glue A records, to the parent zone.

Although stub zones can no longer be used as a mechanism for injecting NS records into their parent zones, they are still useful as a way of directing queries for a given domain to a particular set of name servers.

named.conf options

This is a summary of the implementation status of the various named.conf options in BIND 9.

   Legend:
   

Yes Implemented in this release.

No Not implemented, may be implemented in a later release.

Obsolete Obsolete, not applicable to BIND 9, or just evil. Will not be implemented.

* New in BIND 9.

+ The option is now always enabled.

- The option is now always disabled.

% The default value has changed since BIND 8.

& The option has been extended since BIND 8.

@ Semantics of certain pathological address match lists, in particular those involving double negation, have changed. The new semantics are generally safer. IPv6 addresses are supported, but the predefined ACLs "localhost" and "localnets" match IPv4 addresses only.

# BIND 9 accepts both LF and CRLF as end-of-line markers.

$ Stub zones are partially supported. They no longer inject NS records into their parent zones, but can still be used as a way of forcing a domain to be resolved using a particular set of name servers.

options { [ version version_string; ] Yes [ directory path_name; ] Yes [ named-xfer path_name; ] Obsolete [ dump-file path_name; ] Yes [ memstatistics-file path_name; ] No [ pid-file path_name; ] Yes [ statistics-file path_name; ] Yes [ auth-nxdomain yes_or_no; ] Yes% [ deallocate-on-exit yes_or_no; ] Obsolete+ [ dialup yes_or_no | notify | notify-passive | refresh | passive; ] Yes& [ fake-iquery yes_or_no; ] Obsolete- [ fetch-glue yes_or_no; ] Obsolete [ has-old-clients yes_or_no; ] Obsolete [ host-statistics yes_or_no; ] No [ multiple-cnames yes_or_no; ] Obsolete- [ notify yes_or_no | explicit; ] Yes& [ recursion yes_or_no; ] Yes [ rfc2308-type1 yes_or_no; ] No [ use-id-pool yes_or_no; ] Obsolete+ [ use-ixfr yes_or_no; ] Obsolete [ treat-cr-as-space yes_or_no; ] Obsolete# [ also-notify { ip_addr; [ ip_addr; ... ] }; ] Yes [ forward ( only | first ); ] Yes [ forwarders { [ in_addr ; [ in_addr ; ... ] ] }; ] Yes [ check-names ... ] Obsolete [ allow-notify { address_match_list }; ] Yes* [ allow-query { address_match_list }; ] Yes@ [ allow-transfer { address_match_list }; ] Yes@ [ allow-recursion { address_match_list }; ] Yes@ [ blackhole { address_match_list }; ] Yes [ listen-on [ port ip_port ] { address_match_list }; ] Yes@ [ listen-on-v6 [ port ip_port ] { address_match_list }; ] Yes* [ query-source ... ] Yes [ query-source-v6 ... ] Yes* [ lame-ttl number; ] Yes [ max-transfer-time-in number; ] Yes [ max-transfer-idle-in number; ] Yes* [ max-transfer-time-out number; ] Yes* [ max-transfer-idle-out number; ] Yes* [ max-cache-ttl number; ] Yes* [ max-ncache-ttl number; ] Yes [ max-cache-size size_spec; ] No* [ min-roots number; ] Obsolete [ serial-queries number; ] Obsolete [ transfer-format ( one-answer | many-answers ); ] Yes [ transfers-in number; ] Yes [ transfers-out number; ] Yes [ transfers-per-ns number; ] Yes [ transfer-source ip_addr; ] Yes [ transfer-source-v6 ip_addr; ] Yes* [ request-ixfr yes_or_no; ] Yes* [ provide-ixfr yes_or_no; ] Yes* [ maintain-ixfr-base yes_or_no; ] Obsolete [ max-ixfr-log-size number; ] Obsolete [ coresize size_spec ; ] Yes [ datasize size_spec ; ] Yes [ files size_spec ; ] Yes [ stacksize size_spec ; ] Yes [ cleaning-interval number; ] Yes [ heartbeat-interval number; ] Yes [ interface-interval number; ] Yes [ statistics-interval number; ] No [ topology { address_match_list }; ] No [ sortlist { address_match_list }; ] Yes [ rrset-order { order_spec ; [ order_spec ; ... ] }; ] No [ recursive-clients number; ] Yes* [ tcp-clients number; ] Yes* [ tkey-domain ... ] Yes* [ tkey-dhkey ... ] Yes* [ min-refresh-time number ; ] Yes* [ max-refresh-time number ; ] Yes* [ min-retry-time number ; ] Yes* [ max-retry-time number ; ] Yes* [ port number; ] Yes* [ sig-validity-interval number; ] Yes* [ additional-from-auth yes_or_no; ] Yes* [ additional-from-cache yes_or_no; ] Yes* };

acl Yes@

include Yes

key Yes

logging Yes

controls { [ inet ... ] Yes% [ unix ... ] Obsolete };

server ip_addr { [ bogus yes_or_no; ] Yes [ request-ixfr yes_or_no; ] Yes* [ provide-ixfr yes_or_no; ] Yes* [ support-ixfr yes_or_no; ] Obsolete [ transfers number; ] Yes [ transfer-format ( one-answer | many-answers ); ] Yes [ keys { key_id [key_id ... ] }; ] Yes };

trusted-keys Yes

zone "domain_name" [ ( in | hs | hesiod | chaos ) ] { type master; Yes file path_name; Yes [ forward ( only | first ); ] Yes [ forwarders { [ ip_addr ; [ ip_addr ; ... ] ] }; ] Yes [ check-names ( warn | fail | ignore ); ] Obsolete [ allow-update { address_match_list }; ] Yes@ [ update-policy ... ] Yes* [ allow-query { address_match_list }; ] Yes@ [ allow-transfer { address_match_list }; ] Yes@ [ dialup yes_or_no | notify; ] Yes& [ max-transfer-time-out number; ] Yes* [ max-transfer-idle-out number; ] Yes* [ notify yes_or_no | explicit; ] Yes& [ also-notify { ip_addr; [ ip_addr; ... ] }; ] Yes [ ixfr-base path_name; ] Obsolete [ pubkey number number number string; ] No [ sig-validity-interval number; ] Yes* [ database string ; [string; ... ] ] Yes* [ min-refresh-time number ; ] Yes* [ max-refresh-time number ; ] Yes* [ min-retry-time number ; ] Yes* [ max-retry-time number ; ] Yes* };

zone "domain_name" [ ( in | hs | hesiod | chaos ) ] { type slave; Yes [ file path_name; ] Yes [ ixfr-base path_name; ] Obsolete masters [ port ip_port ] { ip_addr; [ ip_addr; ... ] }; Yes [ forward ( only | first ); ] Yes [ forwarders { [ ip_addr ; [ ip_addr ; ... ] ] }; ] Yes [ check-names ( warn | fail | ignore ); ] Obsolete [ allow-notify { address_match_list };] Yes* [ allow-update { address_match_list }; ] Obsolete [ allow-update-forwarding { address_match_list }; ] No* [ allow-query { address_match_list }; ] Yes@ [ allow-transfer { address_match_list }; ] Yes@ [ transfer-source ip_addr; ] Yes [ transfer-source-v6 ip_addr; ] Yes* [ dialup yes_or_no | notify | notify-passive | refresh | passive; ] Yes& [ max-transfer-time-in number; ] Yes [ max-transfer-idle-in number; ] Yes* [ max-transfer-time-out number; ] Yes* [ max-transfer-idle-out number; ] Yes* [ notify yes_or_no | explicit; ] Yes& [ also-notify { ip_addr; [ ip_addr; ... ] }; ] Yes [ pubkey number number number string; ] No [ min-refresh-time number ; ] Yes* [ max-refresh-time number ; ] Yes* [ min-retry-time number ; ] Yes* [ max-retry-time number ; ] Yes* };

zone "domain_name" [ ( in | hs | hesiod | chaos ) ] { type stub; Yes$ [ file path_name; ] Yes masters [ port ip_port ] { ip_addr; [ ip_addr; ... ] }; Yes [ forward ( only | first ); ] Yes [ forwarders { [ ip_addr ; [ ip_addr ; ... ] ] }; ] Yes [ check-names ( warn | fail | ignore ); ] Obsolete [ allow-update { address_match_list }; ] Obsolete [ allow-update-forwarding { address_match_list }; ] Yes* [ allow-query { address_match_list }; ] Yes@ [ allow-transfer { address_match_list }; ] Yes@ [ transfer-source ip_addr; ] Yes [ transfer-source-v6 ip_addr; ] Yes* [ dialup yes_or_no | passive | refresh; ] Yes% [ max-transfer-time-in number; ] Yes [ max-transfer-idle-in number; ] Yes* [ max-transfer-time-out number; ] Yes* [ max-transfer-idle-out number; ] Yes* [ pubkey number number number string; ] No [ min-refresh-time number ; ] Yes* [ max-refresh-time number ; ] Yes* [ min-retry-time number ; ] Yes* [ max-retry-time number ; ] Yes* };

zone "domain_name" [ ( in | hs | hesiod | chaos ) ] { type forward; Yes [ forward ( only | first ); ] Yes [ forwarders { [ ip_addr ; [ ip_addr ; ... ] ] }; ] Yes };

zone "." [ ( in | hs | hesiod | chaos ) ] { type hint; Yes file path_name; Yes [ check-names ( warn | fail | ignore ); ] Obsolete };

view "view_name" [ ( in | hs | hesiod | chaos ) ] { Yes* match-clients { address_match_list }; Yes* [ zone ... ] Yes [ auth-nxdomain yes_or_no; ] Yes [ fetch-glue yes_or_no; ] Obsolete [ notify yes_or_no | explicit; ] Yes& [ recursion yes_or_no; ] Yes [ rfc2308-type1 yes_or_no; ] No [ also-notify { ip_addr; [ ip_addr; ... ] }; ] Yes [ forward ( only | first ); ] Yes [ forwarders { [ in_addr ; [ in_addr ; ... ] ] }; ] Yes [ check-names ... ] Obsolete [ allow-notify { address_match_list }; ] Yes [ allow-query { address_match_list }; ] Yes [ allow-transfer { address_match_list }; ] Yes [ allow-recursion { address_match_list }; ] Yes [ query-source ... ] Yes [ query-source-v6 ... ] Yes [ lame-ttl number; ] Yes [ max-transfer-time-out number; ] Yes* [ max-transfer-idle-out number; ] Yes* [ max-cache-ttl number; ] Yes* [ max-ncache-ttl number; ] Yes [ max-cache-size size_spec; ] No* [ min-roots number; ] Obsolete [ transfer-format ( one-answer | many-answers ); ] Yes [ transfer-source ip_addr; ] Yes [ transfer-source-v6 ip_addr; ] Yes* [ request-ixfr yes_or_no; ] Yes* [ provide-ixfr yes_or_no;] Yes* [ cleaning-interval number; ] Yes [ topology { address_match_list }; ] No [ sortlist { address_match_list }; ] Yes [ rrset-order { order_spec ; [ order_spec ; ... ] }; ] No [ key ... ] Yes [ server ... ] Yes [ trusted-keys ... ] Yes [ sig-validity-interval number; ] Yes* [ min-refresh-time number ; ] Yes* [ max-refresh-time number ; ] Yes* [ min-retry-time number ; ] Yes* [ max-retry-time number ; ] Yes* };

Using the BIND 9 Simplified Database Interface

This document describes the care and feeding of the BIND 9 Simplified Database Interface, which allows you to extend BIND 9 with new ways of obtaining the data that is published as DNS zones.

The Original BIND 9 Database Interface

BIND 9 has a well-defined "back-end database interface" that makes it possible to replace the component of the name server responsible for the storage and retrieval of zone data, called the "database", on a per-zone basis. The default database is an in-memory, red-black-tree data structure commonly referred to as "rbtdb", but it is possible to write drivers to support any number of alternative database technologies such as in-memory hash tables, application specific persistent on-disk databases, object databases, or relational databases.

The original BIND 9 database interface defined in <dns/db.h> is designed to efficiently support the full set of database functionality needed by a name server that implements the complete DNS protocols, including features such as zone transfers, dynamic update, and DNSSEC. Each of these aspects of name server operations places its own set of demands on the data store, with the result that the database API is quite complex and contains operations that are highly specific to the DNS. For example, data are stored in a binary format, the name space is tree structured, and sets of data records are conceptually associated with DNSSEC signature sets. For these reasons, writing a driver using this interface is a highly nontrivial undertaking.

The Simplified Database Interface

Many BIND users wish to provide access to various data sources through the DNS, but are not necessarily interested in completely replacing the in-memory "rbt" database or in supporting features like dynamic update, DNSSEC, or even zone transfers.

Often, all you want is limited, read-only DNS access to an existing system. For example, you may have an existing relational database containing hostname/address mappings and wish to provide forvard and reverse DNS lookups based on this information. Or perhaps you want to set up a simple DNS-based load balancing system where the name server answers queries about a single DNS name with a dynamically changing set of A records.

BIND 9.1 introduces a new, simplified database interface, or "sdb", which greatly simplifies the writing of drivers for these kinds of applications.

The sdb Driver

An sdb driver is an object module, typically written in C, which is linked into the name server and registers itself with the sdb subsystem. It provides a set of callback functions, which also serve to advertise its capabilities. When the name server receives DNS queries, invokes the callback functions to obtain the data to respond with.

Unlike the full database interface, the sdb interface represents all domain names and resource records as ASCII text.

Writing an sdb Driver

When a driver is registered, it specifies its name, a list of callback functions, and flags.

The flags specify whether the driver wants to use relative domain names where possible.

The callback functions are as follows. The only one that must be defined is lookup().

     - create(zone, argc, argv, driverdata, dbdata)
   	  Create a database object for "zone".
   

- destroy(zone, driverdata, dbdata) Destroy the database object for "zone".

- lookup(zone, name, dbdata, lookup) Return all the records at the domain name "name".

- authority(zone, dbdata, lookup) Return the SOA and NS records at the zone apex.

- allnodes(zone, dbdata, allnodes) Return all data in the zone, for zone transfers.

For more detail about these functions and their parameters, see bind9/lib/dns/include/dns/sdb.h. For example drivers, see bind9/contrib/sdb.

Rebuilding the Server

The driver module and header file must be copied to (or linked into) the bind9/bin/named and bind9/bin/named/include directories respectively, and must be added to the DBDRIVER_OBJS and DBDRIVER_SRCS lines in bin/named/Makefile.in (e.g. for the timedb sample sdb driver, add timedb.c to DBDRIVER_SRCS and timedb.@O@ to DBDRIVER_OBJS). If the driver needs additional header files or libraries in nonstandard places, the DBDRIVER_INCLUDES and DBDRIVER_LIBS lines should also be updated.

Calls to dns_sdb_register() and dns_sdb_unregister() (or wrappers, e.g. timedb_init() and timedb_clear() for the timedb sample sdb driver) must be inserted into the server, in bind9/bin/named/main.c. Registration should be in setup(), before the call to ns_server_create(). Unregistration should be in cleanup(), after the call to ns_server_destroy(). A #include should be added corresponding to the driver header file.

You should try doing this with one or more of the sample drivers before attempting to write a driver of your own.

Configuring the Server

To make a zone use a new database driver, specify a "database" option in its "zone" statement in named.conf. For example, if the driver registers itself under the name "acmedb", you might say

      zone "foo.com" {
   	   database "acmedb";
      };
You can pass arbitrary arguments to the create() function of the driver by adding any number of whitespace-separated words after the driver name:
      zone "foo.com" {
   	   database "acmedb -mode sql -connect 10.0.0.1";
      };

Hints for Driver Writers

Future Directions

A future release may support dynamic loading of sdb drivers.

Troubleshooting DNS

After configuration, DNS starts automatically if /etc/inet/named.conf is present. When named starts up, it writes its process id to the file /etc/inet/named.pid. This is useful to programs that want to send signals to named.

If you encounter problems with named, first view the logfile /var/adm/log/osmlog for any errors. If none are found, use the ndc(1Mtcp) command to send commands to named. This allows you to troubleshoot DNS without restarting the named process. Useful commands are:


ndc dumpdb
Dumps the current database and cache to /var/tmp/named_dump.db. This gives you an indication to whether the database was loaded correctly.

ndc /debug
Toggles debugging on or off. Each following invocation of this command toggles debugging on or off. The output goes to /var/tmp/named.run.

ndc reload
Causes named to read named.conf and reload the database, overwriting cached data. This is useful when you make a change to a data file and you want named's internal database to reflect the change.

This command also has the effect of scheduling all slave servers for serial-number checks, which could lead to zone transfers ahead of the usual schedule. Normally, serial-number comparisons are done only at the intervals specified in the zone's SOA record.


ndc reload zone1 ...
Reloads the database for the specified zones.

ndc trace
Increases the tracing level of all incoming queries. The trace is sent to /var/adm/log/osmlog and provides a large amount of data.

ndc /trace
Toggles tracing on or off.

ndc notrace
Turns off tracing.
You can also use ndc to control named daemons running on remote name servers provided that they have been updated to at least version 8.2.1 of BIND and that they have been configured to allow remote control. See the ndc(1Mtcp) manual page for more information.

Using nslookup, dig, and host

nslookup, dig, and host are useful commands that allow you to perform DNS queries, and to test out your DNS configuration.

You can use the nslookup command interactively to enter a shell from which you can change servers, set query options, and debug DNS. You can also use nslookup non-interactively from the command line to issue simple queries. See nslookup(1Mtcp). Also see dig(1Mtcp).

Finally, you can use the host command to provide answers to simple host queries. See host(1Mtcp) for more information.

Using nslookup interactively

  1. Enter nslookup at the command line. The nslookup prompt appears.

  2. View the current options by entering set all.

  3. Change any desired options by entering set option.

  4. Issue nslookup commands.

  5. Enter exit to leave nslookup.
For a list of sample commands, see ``nslookup interactive commands''. For a list of options, see ``nslookup interactive options''.
nslookup interactive commands

These sample commands are available from the nslookup shell:


volga
Return the IP address of volga.

172.16.118.1
Return the name matching the IP address you enter.

set querytype=ns
Set the query type to the Name Server record. Future queries of names and IP addresses return the NS record from that host.

set querytype=a
Restore the query type to the Address record.

server server
Make server the default server that is queried.
nslookup interactive options

Here are the commonly used options of nslookup. For a complete list, see the manual page for nslookup(1Mtcp).


[no]recurse
Sets the query type to recursive. When toggled to norecurse, nslookup performs iterative queries.

querytype=type
Sets the query type to the DNS data type specified. Common types include a (Address), any (any data type), mx (Mail Exchanger), and ns (Name Server).

retry=n
Resends the query n times before giving up.

root=root server
Sets the root server to the server you enter.

timeout=n
The period of time nslookup waits for a response after the query is sent. This period doubles between each retry.
You can save any of these options in a .nslookuprc file in your home directory. The format of this file, which is searched for each time you invoke nslookup, is one set command per line. Here is an example, which sets the query type to address records, the domain to mynet.com, and sets the timeout on requests to 10 seconds:
   set querytype=a
   set domain=mynet.com
   set timeout=10

Querying a single name or address

To issue a simple query from the command line, use one of the following forms of the nslookup command:

nslookup name

nslookup IP_address

nslookup should return the desired answer by querying the default server. To query a different server, enter one of the following forms of the command:

nslookup name server

nslookup IP_address server

Examples of using the dig command

Obtain the latest list of root domain servers:

dig . ns

Find out the name servers for a zone:

dig @server domain ns

Request all records for a zone from an authoritative server:

dig @server domain axfr


NOTE: This command requires a zone transfer which the server may disallow.

Look up the domain name corresponding to the IP address 172.16.118.1:

dig -x 172.16.118.1

Examples of using the host command

Use host to find all the host records for a zone:

host -l domain

Use host to request all the records for a zone:

host -l -v -t any domain


NOTE: These commands require a zone transfer which the server may disallow.

For more about DNS

To obtain more information about DNS files and commands, consult the following manual pages:

Manual page Information provided
dig(1Mtcp) Domain Information Groper, an alternative to nslookup
host(1Mtcp) Look up host names using the domain server
hostname(1bsd) Set or print current host name
named(1Mtcp) The named daemon
named.conf(4tcp) Format of the DNS daemon configuration file
named.hosts(4tcp) Format of the DNS hosts database
named.rev(4tcp) Format of the DNS reverse host mapping file
named.soa(4tcp) Format of the DNS Start of Authority file
named-xfer(1Mtcp) Transfer DNS zone files
ndc(1Mtcp) Control the behavior of the named daemon
nslookup(1Mtcp) Name service command line query tool
nsupdate(1Mtcp) Dynamically update name servers
root.cache(4tcp) Format of the DNS cache file
resolv.conf(4tcp) Format of the resolver configuration file (/etc/resolv.conf)

To get more information about BIND, DNS, and related protocols, see the following RFCs.

RFC Title
819 The Domain Naming Convention for Internet User Applications
952 DOD Internet Host Table Specification
974 Mail Routing and the Domain System
1032 Domain Administrator's Guide
1033 Domain Administrator's Guide
1034 Domain Names -- Concept and Facilities
1035 Domain Names -- Implementation and Specification
1101 DNS Encoding of Network Names and Other Types
1123 Requirements for Internet Hosts - Application and Support
1183 New DNS RR Definitions
1535 A Security Problem and Proposed Correction With Widely Deployed DNS Software
1536 Common DNS Implementation Errors and Suggested Fixes
1537 Common DNS Data File Configuration Error
1995 Incremental Zone Transfer in DNS
2065 Domain Name System Security Extensions
2181 Clarifications to the DNS Specification
2308 Negative Caching of DNS Queries (DNS NCACHE)

You can learn more about BIND at the URL: http://www.isc.org/bind.html.

A good book for beginners is DNS and BIND, Second Edition, by Paul Albitz and Cricket Liu, 1997, O'Reilly and Associates, Sebastopol, CA.


© 2004 The SCO Group, Inc. All rights reserved.
UnixWare 7 Release 7.1.4 - 22 April 2004