|
|
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:
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''.
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 name space is divided into several organizational and geographical top-level domains. Top-level non-geographic domains include:
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 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 ``.''.
The diagram below compares the domain naming scheme to UNIX pathnames.
The domain naming scheme and UNIX pathnames are similar in the following ways:
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:
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:
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.
The SCO implementation of DNS supports the following server configuration types:
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.
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.
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.
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.
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.
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.
``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.
``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:
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.
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
See ``The Client Manager interface'' for instructions on how to configure a name service client using the Client Manager.
The following daemon and utilities form the heart of DNS operations:
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.
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''.
You can start the DNS Manager in any of these ways:
DNS Manager.
With the DNS Manager, you can:
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.
To configure a host as a name server for a zone using the DNS Manager:
Add.
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.
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.
Using the DNS Manager, you can define resource records to hold the following information about a zone:
To enter a description of the hardware and operating system of the host machine for the name server:
Modify.
To define the person responsible for administering a zone:
Modify.
To define the default mail exchangers for a zone:
Modify.
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.
To enter a short free-text description of the zone:
Modify.
Using the DNS Manager, enter the host resource records (A) for a zone on a master name server as follows:
Records.
Select
Records Add Import file.
Use the file selection dialog to
specify the pathname, and click on OK.
A host will only be added to the list if its IP address shows that it is on one of the networks defined for the zone.
Add Host.
Enter the host name and the IP addresses of the host.
For each IP address you enter,
click on Add to add it to the list.
Click on OK when you have finished.
As recommended by RFC 952, a host name can be composed of alphabetic characters (a-z or A-Z without regard to case), digits (0-9), and minus signs (-). A host name must start with an alphabetic character and must not end with a minus sign. Space, tab and underscore characters (_) may not be used in host names.
Using the DNS Manager, you can define resource records to hold the following information about a host:
To define alternative names for a host:
Modify.
To define the default mail exchangers for a host:
Modify.
mailhub.mynet.com.
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.
To enter a description of the hardware and operating system of the name server:
Modify.
To enter a short free-text description of the host:
Modify.
To define the person responsible for administering a host:
Modify.
To modify the configuration of a zone defined on a name server:
Zones.
Modify.
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:
Sort.
You can sort by host name or IP address to be displayed in
ascending or descending order. By default, no sorting is performed.
Expand all
to view all the information about a zone's hosts
and the contents of their resource records.
Collapse all
to view only the names of a zone's hosts.
Expand.
Alternatively, double-click on the name.
To hide the information again,
click on it, then select
View Collapse.
Alternatively, double-click on it again.
The following preferences may be defined and apply to all services (master, slave, or stub) provided by a name server:
To select the forwarders for a name server:
Forwarders.
To select name servers to which queries should not be sent:
Bad servers.
To define name server hosts and networks that can request zone transfers from a master name server:
Requesters.
To define name server hosts and networks that can request zone transfers for an individual zone:
Modify.
To set limits on the operation of a name server:
Limits.
To set advanced options on the behavior of a name server:
Options.
You can perform the following tasks in the DNS Manager to control the operation and configuration of the name server:
Zone transfer.
Update cache file.
(The command dig . ns provides the new records for the file.)
The named daemon will re-read this file when it is next restarted.
Test configuration.
Enter a host name or IP address,
and click on Query.
Start server.
Stop server.
Default resource records can be defined to hold the following information about a zone:
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.
The sections below contain the software notes that are delivered with the BIND 9.1.0 source from the Internet Software Consortium (ISC).
This document summarizes the state of the DNSSEC implementation in this release of BIND9.
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.
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.
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.
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.
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".
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.
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).
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.
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.
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.
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.
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 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.
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
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.
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.
In BIND 9, ACL names are case sensitive. In BIND 8 they were case insensitive.
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 have to be put into explicit views for each class.
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.
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.
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.
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.
$GENERATE: The "$$" construct for getting a literal "$" into a domain name is deprecated. Use "\$" instead.
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.
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.
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.
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.
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* };
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.
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.
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.
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.
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.
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.
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";
};
A future release may support dynamic loading of sdb drivers.
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:
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.
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.
These sample commands are available from the nslookup shell:
Here are the commonly used options of nslookup. For a complete list, see the manual page for nslookup(1Mtcp).
set querytype=a set domain=mynet.com set timeout=10
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
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
Look up the domain name corresponding to the IP address
172.16.118.1:
dig -x 172.16.118.1
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
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.