DNS, or the Domain Name System, is absolutely vital to the functioning of the Internet. In fact, though you rarely interact directly with the DNS the Internet as we know it could not exist without its constant presence. DNS associates, or binds, host names and domain names to IP addresses and thus allows you to type http://www.swelltech.com instead of the much less memorable IP 216.40.244.74. Further, it makes it possible for mail servers to easily locate the correct host to send mail to for a given domain, the correct administrative contact when strange things are originating from the domain, and more. But for our purposes, as ordinary system administrators, all we need to really keep in mind is that BIND is our method of providing DNS information for our network. It will provide information to our local users, when their client applications need to access various sites by name. And it will provide information to clients (primarily other DNS servers acting as DNS clients in order to fetch the correct information for their clients) on the Internet at large in order to advertise to the world how host names on our network can be reached. Think of it as a fancy telephone book, or even better a telephone operator, for networked computers. The client computer has a name, but needs the number in order to reach it across the vast Internet. So it contacts the DNS server and asks for the number, and BIND is happy to do its best to return the correct number.
Every host on a TCP/IP network has an IP address. This address must be unique for the network on which the address is routable. So, every host that is accessible via the Internet has a unique IP address that may, theoretically, be reached from anywhere else on the Internet. Because these addresses are doled out, roughly, according to physical location on the network, and because routers keep up with which other routers have access to which subnets, this simple number is all that is needed for your computer to establish a connection with any other computer on the Internet in seconds. Unfortunately the topic of routing on the Internet falls quite outside of the scope of this document, as Webmin is not designed to manage routers or the more complex routing features of Linux, FreeBSD, and the other operating systems that are supported.
We have established already that BIND can provide name service for your network, allowing you to enter a host name rather than an IP when connecting to another computer on the network. However, we did not address how BIND, and DNS in general, works on the Internet at large. DNS on the Internet is really a multi-tiered system, wherein clients make queries of local name servers that serve a tiny fraction of the clients found on the Internet, usually on a single subnet. These local name servers then act as clients of somewhat larger name servers, which in turn act as clients for name servers above even them. At some point in this hierarchy the server will be one of the ROOT, or top level domain, name servers, which will know what other lower name server to query regarding the requested name. Each name server in the chain will likely save the results of the query, or cache the result, so will have no need to go all the way up the chain the next time the same query is made. Shockingly, perhaps, this system works quite well, and has scaled as the Internet has grown from a few thousand hosts to hundreds of millions.
When you open your favorite browser and enter a request for a web page, for example http://www.swelltech.com, quite a lot goes on behind the scenes before the browser can even begin to load data from the server. First, the URL you entered must be parsed and interpreted by the browser. But we don't care about that step. Next, the domain and host name where the data is located must be found on the Internet. The name, www.swelltech.com, tells the browser very little about the physical or network location of the data, so it queries a tool that can make some sense out of that information: the DNS server.
The DNS server receives the request and checks its internal cache for the host named www, in the second level domain swelltech, in the top level domain (aka TLD) com. If the DNS server does not have this information cached, it becomes a client and asks its parent name server the same question: "What is the IP for the host www.swelltech.com?" Eventually, assuming no lower level name servers have information about this host, a Top Level Domain name server (in this case, the one for the com TLD will receive the query. The difference here is that the Top Level Domain name server knows the address of the name server that is responsible for that domain name, or at least the next level down, swelltech. Finally, the name server for the swelltech.com domain is queried, and the IP for the host www is returned. As mentioned earlier this data will then be cached by each name server in the query path so that next time, they won't have to work so hard to answer the request.
The BIND module opens to a screen with two sections (Figure 8.1, “The BIND start page”). The upper portion of the page, is devoted to global BIND options, such as other DNS servers, logging, access control, and more. The lower portion of the display provides a number of icons, one for each of the zones your BIND is responsible for. This will include all Master, Slave, Forward, and Stub zones.
Configuring your BIND server is an area where Webmin can really make things simpler. Even though DNS is a very simple service on the surface, the BIND configuration files are notoriously confusing and it is very easy to make a mistake that will render your name server useless. That's not to say you can't misconfigure your name server with Webmin, but it does make it a lot easier to generate a syntactically correct BIND configuration.
![[Note]](http://swelltech.com/support/webminguide/images/note.png) | Note |
|---|---|
There are three BIND versions in common usage today, specifically version 4, 8 and 9. BIND 8 and 9 are functionally identical in many ways and share a configuration file syntax, so that a working BIND 8 configuration will very likely also be a working BIND 9 configuration. BIND 9 adds a few new features, but is primarily a rewrite of BIND 8 (the reasons for the rewrite are irrelevant for general users). Webmin has two BIND modules, one for 4 and one for 8 and 9. Because version 4 is extremely old, and pretty rarely used outside of OpenBSD and older UNIX environments, it will not be covered here. BIND 8 and 9, because they share the same module and configuration syntax, can be covered together. Features available only in BIND 9 will be noted as such. | |
The Other DNS Servers page allows you to configure the behavior of DNS servers that BIND will communicate with in one way or another in a zone transfer relationship. This allows you to explicitly configure several aspects of the transfer relationship for each server (Figure 8.2, “Configuring Other Servers”).
The first field is the IP address of the server to configure. If you are receiving zone transfers for several servers and one of them is to be treated differently, here is where to configure it. The next field tells BIND to treat replies from this server as bogus, meaning incorrect. Future results that come from this domain will not be trusted. Next, in the Zone transfer format field, you can configure whether BIND will receive zone transfers one at a time, or in a batch of many. Finally, though it is not yet implemented in BIND (at least not the latest version of BIND 8--BIND 9 may have this feature by now), there is a place holder for a per-server limitation on the number of transfers to initiate concurrently called Maximum transfers.
This page configures the server directive and related options in your named.conf file. By default, no other servers are defined.
This page provides a list of existing logging channels that are active for bind. It also allows you to add new logging channels. Generally speaking, the logs provided by BIND by default are enough for most purposes, providing a general overview of operations (starting, stopping, etc.) as well as any errors that occur during operation. However, if you need additional logging or logging of specific information to a separate file, you can configure it here.
Logging in BIND 8 is very flexible but also a little confusing at first glance. To add a new log, you first create a new channel that can be set to log to a file or to a syslog level. You then configure the level of information to log there, as discussed below. Finally, you assign logging categories to that channel. The categories dictate what types of information are logged to this particular channel (Figure 8.3, “Creating a new logging channel”).
In the example, I've created a logging channel called test. I've chosen to send it to a log file located at /var/log/test (I know what you're thinking: "Where does he come up with these great names?"). So far it's all pretty self-explanatory, but then we come to Minimum message level. Here we can set the logging level for the information we'd like logged. There are five presets and you can also choose a numeric debug level. The five presets are, from order of least important, info, notice, warning, error, and critical, which are pretty much what they sound like. The info level is almost everything the server has to say about the subject, making for quite a chatty little log. On the other hand, the critical level is reserved for things that usually mean your name server is experiencing one or more serious problems, possibly leading to improper functioning of the server. These first five levels are the same as those used by syslog. The Debug level option allows you to set a debug level for debugging messages to be sent to your log. Note that debug messages cannot be sent to syslog, and must be logged to a file. Finally, the Global level sets this log to the same level as the global server logging.
Next, I assigned a logging category to the logging channel test. In this case I decided to send security information to this channel. There are currently 22 supported categories of information that can be logged. They are as follows.
Logging categories
- default
If no categories are specified, then default is used. Default contains most messages from the other categories, but a few are left out.
- config
Configuration file processing information. BIND writes these messages as it loads the configuration file.
- parser
Configuration file parsing information. BIND writes these messages as it parses the configuration file.
- queries
Logging of queries.
- lame-servers
Notifies you of the detection of a bad delegation.
- statistics
Provides periodic reports of general system runtime information.
- panic
Logging of problems that will cause the shutdown of the server.
- update
Dynamic updates.
- ncache
Negative caching.
- xfer-in
Zone transfers the server is receiving.
- xfer-out
Zone transfers the server is sending.
- db
All database operations.
- eventlib
Debugging info from the event system. Only one channel may be specified for this category, and it must be a file channel. If you do not define the eventlib category, eventlib will be directed to default. This is generally only useful to developers debugging BIND or its related libraries.
- packet
Dumps of packets received and sent. Only one channel may be specified for this category, and it must be a file channel. If you do not define the packet category, it will be directed to the default category at the debug level.
- notify
The NOTIFY protocol, which provides asynchronous change notifications.
- cname
CNAME errors.
- security
Approved and unapproved requests.
- os
Problems with the underlying operating system.
- insist
Internal consistency check failures.
- maintenance
Periodic maintenance events.
- load
Zone loading messages.
- response-checks
Messages arising from response checking, such as "Malformed response ...", "wrong ans. name ...", "unrelated additional info ...", "invalid RR type ...", and "bad referral ...".
This page is for entering any number of named address match lists. The lists defined here are used later in the configuration for a number of purposes, though having an ACL by itself does nothing. To create an ACL, simply enter a name in the ACL Name field, and the addresses, networks, and other ACLs that this ACL will match in the second field. There are a few ACLs that are built in, and do not need to be defined manually, these are any which matches all hosts, none which matches no hosts, localhost which matches the IP address of all interfaces on the system where BIND is running, and localnets which matches all hosts on the local networks for which the system has an interface configured.
Here you configure a few of the file locations for files that your BIND process may need to read from or write to. These usually do not need to be changed, but it may be useful to know what each of them refers to.
- Statistics output file
This option allows you to choose a different filename and path for the statistics that BIND generates when signaled. To cause BIND to dump statistics to this file, you can use the ndc program with the stats option which will send the correct signal to BIND. This corresponds to the statistics-file directive in the options section of named.conf, and defaults to named.stats.
- Database dump file
Configures the location of the file where BIND dumps its database when it receives the correct signal. The signal can be generated by using ndc dumpdb. This option correlates to the dump-file directive in the options section of named.conf, and defaults to named_dump.db.
- Process ID file
This is the location of BINDs process ID file. This location and file must be writable by the BIND process.
- Path to zone transfer program
This sets the path to the named-xfer program that BIND uses for inbound zone transfers. This option configures the named-xfer directive of the options section in named.conf.
This page allows you to configure parent DNS servers (Figure 8.4, “Forwarding and Transfers”). Here, you declare what servers your BIND can query and how to behave towards them.
- Servers to forward queries to
With this field, you enter any name servers that you wish your BIND process to query in the event it does not have a cached result to serve to the client. Usually this will be the name servers that your ISP or hosting service provides for you, but it may also be other servers on your local network. It's a good idea to have at least two, which will be called the primary and secondary name servers, respectively. This option configures the forwarders directive in the options section of named.conf.
- Lookup directly if no response from forwarder
This option allows you to choose whether BIND should query the TLD servers directly if the forwarders do not reply. You may need to turn this off if you have a non-Internet-connected DNS server, or a server isolated by a firewall on your local network that can only communicate with the forwarders. This option configures the forward directive.
- Maximum zone transfer time
This allows you to put an upper limit on the time allowed for inbound zone transfers. This option correlates to the max-transfer-time-in directive, and defaults to 120 minutes. After this time, a transfer will be terminated.
- Zone transfer format
Sets the global transfer format (which can be overridden on a per server basis, in the Other Servers section). Here you can choose whether BIND should receive a message for each resource record transferred. The many choice tells BIND to accept several per message, which is more efficient. This option correlates to the transfer-format directive.
- Maximum concurrent zone transfers
Places a limit on the number of concurrent transfers. This corresponds to the transfers-in option and defaults to 10. Increasing this may improve performance but at the cost of more system resources being consumed.
- Ports and addresses to listen on
BIND can answer on any number of ports and addresses on your server. By default, BIND will answer on port 53 on every active IP address. If you choose to listen on one or more specific addresses and/or ports, then BIND will answer on only those allowed by the match list. It is also possible to negate a port or IP by prepending an !.
- Source IP address for queries
If your BIND does not know the answer to a query, it will query other name servers. Here you can define the local addresses and ports on which to query those name servers. By default it can use any IP or port that is available on the system.
- Nameserver choice topology
When querying other servers, BIND can be configured to choose name servers that are closer in the topology address list. The order the servers appear in the list indicates their distance from the local name server, where the first is closest and the last is furthest. It is also possible to force one or more name servers to be last resorts, by prepending them with !. Those servers prepended by an exclamation point will be placed at the end of the queue, regardless of placement in the topology address list.
The BIND options with no other obvious locations ended up in this section, so it has a relatively large number of options. Luckily for you, most administrators don't have to worry about these options very often. Unluckily for me, to achieve my goal of fully documenting the BIND module, I have to document these features just as completely as those that are more often used. So, on this page you'll find several configurable memory usage settings, some timing options, and some general behavior choices.
- Maximum core dump size
This is the maximum file size of a dump file that BIND will generate in the event of a crash. This option configures the coresize option in the named.conf file. Your operating system may also impose a limit on core size, which may or may not be smaller than the value configured here.
- Maximum data memory usage
This defines the maximum amount of memory that BIND will use for storage of data. This is not the complete memory usage of BIND, as the process itself must have memory, but it can be used to limit BIND somewhat. This option correlates to the datasize in named.conf.
- Maximum open files
Defines the number of files that BIND can have open at any given time. The default is the limit of the OS, however, BIND is not always able to determine this at runtime if the operating system does not accurately report it. In this case, it may be necessary to use the correct value here. This is not a problem under the most popular operating systems where Webmin and BIND are used, such as FreeBSD, Linux, etc. This option configures the files directive.
- Maximum stack memory usage
Defines the maximum amount of stack space that the BIND process may use. This correlates to the stacksize directive.
- Interval between cleaning expired records
BIND will periodically remove expired records from the cache. This option configures how often this cleaning occurs. This corresponds to the cleaning-interval and defaults to 60 minutes.
- Interval between check for new interfaces
BIND will scan the network interface list periodically, and this option configures the interval, in minutes, between scans. The default is 60 minutes. This option configures the interface-interval directive.
- Interval between logging stats
This setting controls how often BIND writes general server statistics to the logs. By default this occurs every 60 minutes, and if set to 0 statistics logging will be turned off. This option correlates to the statistics-interval directive.
- Do full recursive lookups for clients?
BIND can respond in one of two ways if it does not have an answer for a client. If this option is set to Yes , the default, then BIND will perform the lookup itself on a parent or root server. If this is turned off, BIND will simply refer the client to another name server that can answer the query. This option configures the recursion directive.
- Allow multiple CNAME aliases for one name?
Older versions of BIND allowed multiple CNAME resource records for a single domain, and many sites used this for load balancing. However, this usage is against standards and is not recommended. Turning this on allows you to use multiple CNAMES, as in older versions of BIND. The default is off, and it correlates to the multiple-cnames directive.
- Fetch glue records?
If this option is set to Yes, the default, the server will fetch "glue" resource records it does not have when constructing the additional data section of a response. Setting this to No can be used in conjunction with recursion no to prevent the server's cache from growing or becoming corrupted. However, doing this increases the work for the client. This option configures the fetch-glue directive.
- Set authoritative AA bit on responses?
BIND normally caches negative responses (i.e., NXDOMAIN, or "this does not exist"), however, some very old servers and clients may have problems with this and generate errors. It's probably wise to upgrade those old clients and servers rather than turning this off. This option configures the auth-nxdomain directive, and defaults to Yes.
BIND provides a command line utility called rndc (or ndc in older versions) that allows an administrator to perform some administrative tasks. The newer rndc version allows these tasks to be performed on remote BIND servers as well as a server running locally, as it operates via a network socket. Common uses for this utility include stopping the named process, forcing a reload of configuration files, refreshing zone information, and triggering a dump of server stats. Because the rndc tool can be used to shutdown the server, as well as other potentially dangerous actions, its use should be limited to a few trusted client addresses.
This page of the BIND module provides access to the controls section of the BIND configuration file, and configures the hosts that are allowed to connect to the running BIND server.
- Internet port access
If enabled, the first field must contain the local address on which the named server will listen for control requests. The port field can either be the port on which you'd like the process to listen, or you can simply fill in an asterisk, "*", to specify a randomly selected unprivileged port (unprivileged ports on a UNIX system are usually those above 1024). Finally, the allow field should contain the addresses of the hosts you would like to be able to administer your server from. Generally, unless you have a reason to do otherwise, security is most easily maintained by preventing access to all outside addresses. In such a case you would choose an address of 127.0.0.1 in the first field, a port of * and an allow list containing only 127.0.0.1. Assuming your local machine is trusted, your server will be relatively secure.
- Unix filing system access
As in the previous set of options, this directive specifies which clients will have access to the administrative channel of the running named process, but in this case, it is for the older style of communication using a UNIX FIFO pipe. A pipe in UNIX, is a mechanism by which a stream of data can be treated as a file, and vice-versa. Or, in other words, it allows a running process to accept data being written into it as though it were a file and it can output data likewise in a form that can be read like a file.
If using this mechanism for communicating with your named process, you can choose a filename for the pipe, the permissions for the pipe, and the owner and group of the pipe. Care should be taken to make the file inaccessible to all but the administrative users of the system.
Note The UNIX pipe mechanism is not available in BIND 9. It has been deprecated in favor of using the network socket interface along with security keys. It is supported in BIND version 8.
Newer BIND version support secure keys for the purpose of authentication and authorizing access to certain functions. This page allows you to generate keys for use in other sections. Specifically, after generation, a key can be used to secure your Other Servers connections.
To create a new key, simply fill in a new Key ID which must be an alphanumeric string with no whitespace, for example mynewkey or supersecret or HenryThe8th. The Algorithm can usually safely remain at the default of hmac-md5. Finally, the Secret string must be a base64 encoded string.
To generate a base64 encoded string for use in the Secret string field, you can use the dnssec-keygen or dnskeygen utility that is included in most installations of BIND. You can even use a plain string encoded with the mmencode utility, though this will be significantly less secure than using an MD5 key. To create a key using dnssec-keygen, the following command line can be used with minor modifications to suit your server:
[root@delilah]# dnssec-keygen -a HMAC-MD5 -b 128 -n HOST delilah.swelltech.com
Kdelilah.swelltech.com.+157+06448
In the above example, the second line is the output from the command, which gives you a hint about the filenames under which your new key is stored. In this case, two files were generated, named Kdelilah.swelltech.com.+157+06448.key and Kdelilah.swelltech.com.+157+06448.private. Both contain the newly generated key, and so you can view either to copy the key for pasting into the Webmin Secret string field. This key will also need to be made available to any servers that will be communicating with this server using security features.
Here you can define several default options for new zones on your server, and zones for which you provide backup service (Figure 8.5, “Zone defaults”). These options can often be overridden in the definition of the individual zone; however, most such items are best configured here, and any differences from the norm can be configured in the individual zone. These options are only documented here, though they apply to individual zones as well. Note also that these do not affect the named.conf file at all. These are merely default values used by Webmin when creating new master zones, similar to the /etc/skel file used when creating new users. You'll also find on this page settings for some default zone permissions options.
- Refresh time
This is interval for which your zones will be cached before being refreshed by slaves. Lowering this will increase the load on your master server but will help insure fresh data reaches clients from your slave DNS servers. This option configures the refresh field in the SOA record in each new zone you create, and defaults to 10800 seconds, or 3 hours. Note that the introduction of the DNS NOTIFY protocol into BIND 8 removes the reliance of slaves on refresh times for prompt updates. To find out more take a look at RFC 1996. BIND 4 and some other name servers may not have NOTIFY, so if your slaves are not all known to be NOTIFY capable, you should still be aware that your slaves will take the full refresh time to be guaranteed to be fresh.
- Transfer retry time
This defines the amount of time between retries if a refresh attempt fails. If you have reduced the refresh time, this value should be reduced accordingly. This option correlates to the retry field in an SOA record and defaults to 3600 seconds or 1 hour.
- Expiry time
This sets the expiration age for your zone records, for the use of DNS servers that have a cached your domain information. Beyond this date, if the server with the cached data cannot contact a name server that is authoritative for your domain, it will no longer return a positive result. This option configures the expires field of the SOA record and defaults to 432000 seconds, or five days.
- Default time-to-live
This sets the minimum time to live for a zone. Downstream name servers will no longer consider the information they have cached accurate if it is older than this. They will continue to serve the old data if new data cannot be retrieved, until the Expiry time has been reached. This option can be used to very effectively insure that server or address changes can be performed without interruption of client services. For example, if you are aware that your website will be moving to a new server on a new address in a week, you can alter this to something very short, perhaps 30 seconds. By the end of the week, when your change happens, all name servers that have cached your information will know to check with a name server that is authoritative for your domain often. No one will even notice you changed! This option configures the TTL field in the SOA record, and defaults to 38400 seconds, or 10 hours.
- Template records
This section can be a nice time saver if you create a large number of domains with Webmin (for example, if you run an ISP or a web hosting company). Here you can define several template records that can be automatically inserted into some or all of your new zones. For example, if you have a single mail server and two name servers that are the same for all of the domains you create you can create templates for each of those. When you create a zone file later, you can choose to have the templates included. It is also possible to add a single host, whose IP can be defined at zone creation time. The mail server, name alias, and name server templates must have addresses assigned to them from the beginning, however. There is no default template, and this section does not directly effect any BIND configuration files.
This section configures zone settings that will be applied by BIND for zones that do not override them. Unlike the Defaults for new master zones section, these options do impact the BIND configuration file.
- Allow transfers from..
Here you can define other servers that will, by default, be allowed to receive transfers from this server. This option correlates to the allow-transfer directive, and defaults to allowing zone transfers to all hosts.
- Allow queries from..
This one allows you to define what hosts or networks will be allowed to query your server. Any host that will use your name server should be listed here. However, by default, the server will allow requests from all hosts. This option configures the allow-query directive.
- Check names in master zones? and Check names in slave zones?
These two allow you to choose how strict you name server will be with regard to checking names within their expected client context. This means that, for example, a domain name used as a host name can be checked for compliance with relevant standards regarding domain names and host names. These options configure check-names master and check-names slave and default to fail and warn, respectively.
- Check names in responses?
Similar to the previous two options, but checks the names in responses to queries sent by the name server. If this is set to fail, your name server will REFUSE a query it receives and invalid name. This option configures the check-names response directive and defaults to ignore.
- Notify slaves of changes?
This option allows you to configure whether BIND will use the NOTIFY protocol to inform its slaves of updates. In this way, its slaves can query the master to see if a zone transfer is needed. If so, the transfer takes places immediately, and all servers are brought up to date much more quickly then if the slaves awaited their usual refresh age to be reached. This option configures the notify directive.
This section of the BIND main page displays a list of all existing DNS zones. There are four types of of zones (actually there are five, but the hint needs little configuration and is usually setup only once), master, slave, stub, and forward. And each of these types may then be either a forward zone (meaning it maps names to addresses), or a reverse zone (maps addresses to names). Each of the four types has a specific purpose, depending on your name servers relationship to the data it presents to clients.
Zone Types
- master
The server has the master copy of the zone data, and will provide authoritative answers for it.
- slave
A slave zone is a copy of a master zone. Each slave zone will have a list of masters that it may query to receive updates to its copy of the zone. A slave may, optionally, keep a copy of the zone saved on disk to speed startups. A single master server can have any number of slaves in order to distribute load.
- stub
A stub zone is much like a slave zone, and behaves similarly, however, it only replicates the NS records of a master zone rather than the whole zone.
- forward
A forward zone directs all queries in the zone to other servers. In this way it can act as a caching DNS server for a network, or provide Internet DNS services to a network behind a firewall that limits outside DNS queries (obviously the forwarding DNS server must have DNS access to the Internet!). Note that this is similar to the global forwarding facility, but allows per-zone selection of forwarders.
To create a new zone, click on one of the zone creation links in the Existing DNS Zones section of the screen. Each zone type will present you with the various fields necessary for Webmin to generate the new zone file for a zone of the selected type. The fields present differ for each zone type, except slave and stub, so we'll document each in turn.
A master zone is one which contains the authoritative and complete data for a DNS zone, and therefore has the most configurable options (Figure 8.6, “Creating a new master zone”). When creating any type of zone, it is necessary to create at least two zone database files, one for forward mappings and one for reverse mappings. This is to provide both name to address translation, as well as address to name translation. Luckily, once you've created a forward and reverse master zone, Webmin can automatically add the correct reverse records for each host you add to your master zone.
The options when creating zones are pretty straightforward, but I'll discuss them briefly, as well as give an example of creating a new master forward and master reverse zone database.
- Zone type
The zone type is either Forward or Reverse, as discussed earlier. In the example shown, I'm creating a new forward zone.
- Domain name/Network
This option will either be the domain name of the zone in the case of a forward zone, or the network in the case of a reverse zone. Here, I'm creating a zone named myzone. Note that in my case, my domain is for a local network, and will not be able to be resolved from the Internet at large (which requires registration in one of the Top Level Domains, such as .com, .org, or .net). Registration of a domain zone and obtaining addresses and other related tasks are well beyond the scope of this book, but the steps for creating Internet domains are precisely the same.
- Records file
This option allows you to choose the name and location of the db file while you would like your zone information stored. Webmin will automatically create a correctly named file in the system default location for you if you leave this option set to Automatic. Unless you have good reason for breaking convention it is recommended that you leave this as it is.
- Master server
Here you select the name of the master server for this domain. Since we are creating a master zone, this should be the host name of the server that will be the master for this file, in my example, I've selected the host name delilah.swell. a host on my local (non-Internet) domain swell. The sub-option Add NS record for master server? when checked, will add a name server record in this zone for this name server. It's usually good to leave this checked and let Webmin handle one more of the many minor details it will handle if you let it.
- Email address
This should be the email address for the maintainer of this domain. In the case of Internet resolvable domains, this will be the person contacted in the event of problems with your DNS server(s).
- Use zone template?
If you created a zone template in your Global Server Options:Zone Defaults you can include that template information here. This can include any number of automatically generated records of several types (host address, mail server, name server, name alias, and host information). If you chose From form as a source for one of your host addresses, then you can enter that information in the IP address for template records field. Using the template facility in Webmin can prove a very powerful tool for administrators who manage a large number of zones that have the same name servers and mail servers. Creating a new domain can be done almost automatically, in this way.
- Refresh time
This is the same as the option of the same name in Global Server Options:Zone Defaults, though it will only apply to this zone. This option will override the global zone default. The same applies to Transfer retry time, Expiry time, and Default time-to-live
Clicking create takes you to the primary page for this new zone. We'll come back to these options after discussing the creation of a reverse master zone, as it makes good sense to create your reverse zone for this domain before adding any records to the zone. In this way, Webmin can keep the two files in sync for you automatically.
After creating a forward master zone, you may then want to return to the main BIND module page and create another master zone (Figure 8.7, “Creating a Reverse Master Zone”). This time, you will choose to create a reverse zone, in order to provide mapping from IP addresses to names.
Here, you'll see that creating a reverse master zone is exactly like creating a forward master zone. In this case, I've chosen a zone type of Reverse, as this zone will map addresses to names. The only other difference between this and the previous example, is that I've entered the network address, 172.16.1, instead of the domain name. After creating this, I'm taken to the primary page for the new zone. We will rarely edit the reverse master zone records directly, as it is easier and safer to allow Webmin to do it for us. So let's return to the primary BIND module page, and then edit our new myzone master zone.
Assuming you successfully created a Forward Master Zone, it will now appear in the Existing DNS Zones section of your main BIND page. Clicking it takes you to a page that allows adding records of all types, as well as a few general zone options at the bottom of the page (Figure 8.8, “Edit Master Zone”). The options at the bottom of the page are the same as those documented in the Global Zone Options sections earlier, except they only effect the one zone you are editing, so these options will not be covered here.
- Address
An address record allows you to enter the host name, the time-to-live, and the address for a host. Every host on your network should have an Address Record (Figure 8.9, “Adding an Address Record”). In the example, note that I've entered the fully qualified host name, and ended with a period. I've also chosen to have Webmin update the reverse master zone with this address, as well. This option creates an A record.
- Name Server
If you have another name server that is responsible for another subdomain (such as joeszone.myzone.), you can add it here. You can also add other name servers for this domain, including slaves and redundant masters. This option creates an NS record.
- Name Alias
Name aliases provide a means to name a host more than one name. For example, if you wanted your mail server (real name mail.myzone.) to also be addressable by the name smtp.myzone., you could create an alias for it here, and both names would resolve to the same machine. Also, it allows you to create shortcuts for your users. If for example, you wanted users to be able to simply enter news to reach a news server, even though your news server is actually in another domain. This option creates a CNAME record.
- Mail Server
Every mail server in your domain should have an entry here. On this page, the Name field should contain the name of the domain, and the Mail Server field should contain the name of the mail server. When creating a mail server record, you are given an extra option that is not present in any of the other records, called Priority. The Priority of a mail server is a relative value to indicate which mail server has precedence. The lower the value, the higher its precedence. Every mail record must have a Priority. In the event that the server with the highest precedence is down, mail servers can then deliver mail to the next server on the list. This option creates a MX record.
- Host Information
This record type allows you to identify the type of host that is referenced by an address record. Here, you enter the name of the host, and the Hardware type and Operating System type. These types are entirely optional, but if you do enter them, you should be aware of the security implications (identifying your hardware and OS is the first step a cracker takes in identifying ways to crack your system). Also, there are several rules documented in RFC 1700 regarding how one should identify hardware and OS. However, these rules are not at all strictly enforced and it is usually quite safe to use this record for internal record keeping purposes (i.e., instead of keeping a notebook or separate database of all of your hosts and what OS and version they run). This option creates a HINFO record.
- Text Record
Here you can enter any arbitrary text string up to about 2K. You can use this for notes regarding the host, perhaps the location or primary user of the host, as well as for other notes that can be referenced by other records, for example, in a Responsible Person record. This option creates a TXT record.
- Well Known Service
The Well Known Service record type allows you to configure what types of services a particular host provides. So, for example, you could advertise that the host myhost.myzone. can provide telnet, ftp, and smtp services. The services are identified by the same name as is found in the services file. This option creates a WKS record. More on Well Known Services can be found in section 3.4.2 of RFC 1035. WKS records are optional, and are not in very common usage, nor is it supported by all domain name servers.
- Responsible Person
Here you define the person who is responsible for a given host or domain. The Name field is for the host name or the domain name, ending in a period if an absolute name. You can also enter the email address for the responsible person. The Text Record field can contain the name of a previously configured Text record. For example, if I were maintaining a domain and wanted people to be able to locate me in the event of a problem, I could create a text record named joe containing my cell phone number. Then for each host and subzone I manage, I could create a Responsible Person record that contains not only my email address, but also refers to the joe Text record. This option creates an RP record.
![[Tip]](http://swelltech.com/support/webminguide/images/tip.png)
Tip When entering an email address in the Responsible Person section, Webmin will automatically convert it to the dot-separated format required by BIND. You should enter email addresses in their real world form, i.e., joe@swelltech.com.
- Location
The Location record is a rather new and experimental record type, that allows one to include precise (on a global scale, anyway) information about each host and network in your zone. The location is defined in latitude, longitude, and altitude. The current Webmin version does not distinguish the separate parts of this information, so you must enter it yourself in the correct format. RFC 1876 provides a more complete description of the Location record. One good resource to help you understand and use the LOC record, provided by one of the co-creators of the LOC specification, is DNS LOC: Geo-enabling the Domain Name System. There you can find links to sites that will provide the coordinates for your location for free. There is also a link to AirNav, which will provide altitude information for public landing sites (airports) in your area. This isn't as precise as a GPS system, but it's better than nothing, and a lot more information than most DNS servers are configured to provide.
- Edit Records File
This option merely provides a simple text editor window that contains the complete db file for your zone. This allows you to edit it manually, however, this is not recommended unless you are familiar with the BIND configuration file grammar as it is not checked by Webmin for correctness.
Slave and Stub zones are created in exactly the same way, and are quite similar in some ways though their purposes are very different (Figure 8.10, “Creating a Slave Zone”). Slave zones keep a complete copy in memory, and sometimes also on disk, of a zone that it receives via a zone transfer from a master zone. A slave zone can answer any queries for a zone, and as long as network connectivity remains intact between the master and slave, and the servers are configured correctly, it will stay in sync with the master server. A stub zone also syncs to a master server, however it only keeps NS and SOA record information from the master server. This allows BIND to keep up with delegation information automatically.
Creating a slave is extremely simple. The only information required is the domain name or the network (as was used in the master zone earlier), and the addresses of one or more master name servers. As with Master zones, you configure both a forward and reverse zone type for each zone. This server can then be used by clients just as the master zone is used. In fact, whether it is a slave or master is entirely transparent to the user.
A forward zone is simpler still. It's only possible configuration options are whether it is a forward (name to address) or reverse (address to name) zone type, the name or network of the domain, and the master servers to forward requests to. A forward zone is just specific instructions for BIND that it should forward requests for a specific zone to one or more specific name servers. BIND does not perform zone transfers with a forward zone, as it does in the case of slave and stub zones.
A caching name server can be beneficial in a number of situations. First, because it brings name service closer to the user, performance of all name-based services will likely be improved. Also, in secured environments with a strict firewall implementation, it can be used to allow local clients to obtain name service without having to pierce the firewall for all users. Only the local caching DNS server must have access to outside name servers. Finally, it provides a simple mechanism for providing a private name space to local users, by allowing users to obtain all name service from the local caching name server which also acts as a master name server for the local network name space..
A caching name server is perhaps the simplest type of name server to configure, and Webmin makes the configuration even easier. Because caching is a core part of how DNS scales, it is an automatic part of any BIND configuration. All that is left for us to do is allow Webmin to create our initial configuration files, and alter a couple of options in the configuration.
When first opening the Webmin BIND module, you'll be given a few choices about how to generate the initial configuration files. The ideal choice is to allow Webmin to initialize your configuration, and download the root name server list. If you are not currently connected to the network you can choose to use the root name server list file that is included in the Webmin distribution.
After Webmin has completed the download, and initialized your files, click on the Forwarding and Transfers icon. Add the primary and secondary name server addresses provided by your ISP to the field labeled Servers to forward queries to. Then select Yes for the option Lookup directly if no response from forwarder. Click Save.
Believe it or not, your configuration is finished. Simply click on the Start BIND button, and point your client workstations to the IP of your server for their primary name server, and test it out. Check the later section on troubleshooting BIND if problems arise.
As discussed earlier in the Apache chapter, a name-based virtual host has to have a name mapped to an IP address before you can even access its contents with a browser. BIND, of course, will be our means of providing lookup of those names. Because we're only concerned with web service for this tutorial, we only need to concern ourselves with the creation of a forward zone (a forward zone maps names to addresses).
Assuming you've already allowed Webmin to initialize your named configuration files you're ready to add a master forward zone for your domain (Figure 8.11, “An example master zone”. Click on the Create a new master zone link on the front page of the BIND module.
The Zone type should remain at its default of Forward. The Domain name/Network field should contain the second level domain name under which your virtual hosts will reside. For example, if I had one or more virtual hosts under the swelltech.com domain, that would be the domain name I would enter here. If you have other second level domains, you will create a zone for each. It is easiest to allow Webmin to automatically name the Records file, and the Master server will probably be correct if your host name is configured correctly. Enter your email address, or the address you would like to be the administrative contact for this zone, into the Email address field. Finally, click Create. You will immediately be directed to the new zone for further configuration.
Now we can begin adding records to our new zone. The first record I would add to my swelltech.com domain would be swelltech.com itself, and it will be an address record, also known as an A record. Clicking on the Addresses icon provides a simple form for adding the new record. Because this first record is for a host named simply swelltech.com, we enter nothing in the Name. Then we enter the IP address of the server we'd like this name to point to, in my case it is the same address on which my Webmin server is running. All other fields can remain at their defaults. Clicking Create adds the record.
Follow the same steps to add another address record for www.swelltech.com, presumably on the same IP. All that changes from the above steps is to enter www in the Name field instead of leaving it blank. If you've worked through the examples in the Apache tutorial on virtual hosting, you'll now have all of the pieces for web service on both domain names.
Because no domain would be complete without mail service, and mail service for a domain does not have to reside on the same server as web service, we need to have some way to tell mail servers where to direct our mail. Luckily, the designers of DNS have thought of that already and provide the MX, or mail server, record as a means of notifying other mail servers where to send email destined for the domain.
Adding a mail server is usually a two part process. First, a new record is created pointing to the address of the mail server. In the case of small networks, this will likely be a machine that is providing other services, for example the Swell Technology mail server resides on the same machine as our web server, and our NTP time server. So, in most cases we can use a Name Alias record, also known as a CNAME record, for our mail server name. If you have a dedicated mail server you will use an address record instead.
Because my mail server is hosted on the same address as my web server, I've chosen to use a CNAME record, or name alias, for mail.swelltech.com. Creating a name alias record is a lot like creating an address record. Click on the Name Alias icon, and fill in the appropriate fields. In this case, I will fill in mail for the Name and swelltech.com. for the Real Name. Notice there is a period at the end of my real name. This period is significant, and required to indicate a fully qualified domain name, otherwise the real name pointed to would be swelltech.com.swelltech.com, which is probably not what we want. Click Create to add the new record.
| Note |
|---|---|
This step is not strictly necessary if your mail server is hosted on the same machine as other named services. However, traditionally mail servers have had a name record of their own, usually mail.domain.com or smtp.domain.com. It also makes it easier to plan for later network expansions if you begin your network design with appropriate names for all of the services available on your network. If you wish to avoid adding a CNAME for mail service, you can skip this step, and point your MX record to an existing name. | |
Now that we have a name for our server, we can add an MX, or mail server, record. This is simply a record that indicates to other mail servers where mail for our domain should be delivered. In my case, I would like mail directed to swelltech.com and all names within the domain to be delivered to mail.swelltech.com. So when a mail server receives a mail from one of its users directed to joe@swelltech.com, it will first find out where that mail ought to be delivered by querying the name server that is authoritative for swelltech.com for its MX record.
To create a new mail server record, click on the Mail Server icon. Since we are currently concerned with our primary domain, in my case swelltech.com, the Name field can be left empty. The Mail Server field can be filled in with the name of the mail server we created in the previous step, mail.swelltech.com in my case. There is an additional field required, called the Priority, which is simply a number that dictates the preference of this mail server relative to others that may be configured, where lower numbers have higher priority with zero being the lowest. Traditionally, a priority of 10 is used for the primary mail server, and other servers will be given priorities higher in steps of ten. So a backup mail server could have a priority of 20. There is no enforcement of this de facto standard, so you could use priorities of 0 and 43 to represent your primary and backup mail servers, but following traditions is probably more polite to any administrator who might have to follow in your footsteps. Click Create to add the mail server record.
Now we have the bare minimum configuration required to make good use of our name server in the real world, so let's reload our BIND configuration and make sure it is working. First, return to the BIND module front page by clicking on the Module Index link in the upper right corner of the page. Then click the Apply Changes button at the bottom of the page to signal BIND to reload its configuration files.
To test our work, we can use the host program. First, we'll test to be sure our domain is resolvable from our name server:
[joe@delilah joe]$ host swelltech.com 192.168.1.1
Using domain server:
Name: 192.168.1.1
Address: 192.168.1.1#53
Aliases:
swelltech.com has address 192.168.1.1
The host command is discussed further in the troubleshooting section of this chapter, but I will point out arguments I've used. Obviously, the first argument to the command is swelltech.com, which is the domain I'd like to lookup. While the second argument is 192.168.1.1, which is the name server I'd like to query for the information. This allows us to easily setup a name server in isolation, without relying on it for real world name service, so that it can be thoroughly tested and confirmed working. Since the above result is exactly what we expected to see, we can move on to testing the MX and NS records, to be sure they also match our expectations.
[joe@delilah joe]$ host -t mx swelltech.com 192.168.1.1
Using domain server:
Name: 192.168.1.1
Address: 192.168.1.1#53
Aliases:
swelltech.com mail is handled by 10 mail.swelltech.com.
This time, we've added an additional argument, "-t mx", to specify the type of record we'd like to retrieve. With this we can retrieve any record type we would like to test. Our only other currently configured record type is an NS record to indicate the authoritative name server for this domain, so we'll also check it.
[joe@delilah joe]$ host -t ns swelltech.com 192.168.1.1
Using domain server:
Name: 192.168.1.1
Address: 192.168.1.1#53
Aliases:
swelltech.com name server ns1.swelltech.com.
So far, so good! Just for completeness, let's run one last lookup, to see how a name alias differs from a normal address record.
[joe@delilah joe]$ host mail.swelltech.com 192.168.1.1
Using domain server:
Name: 192.168.1.1
Address: 192.168.1.1#53
Aliases:
mail.swelltech.com is an alias for swelltech.com.
swelltech.com has address 192.168.1.1
Assuming all went well with your results, you're ready to put your name server into service. The rest of this chapter is devoted to troubleshooting methods, and more advanced uses for the host and dig utilities, and working through the examples might provide some insight into the workings of DNS in a variety of applications and environments.
There are a number of tools that are available to assist with testing and troubleshooting problems with your BIND configuration. The simplest tool on most systems is the host command, which simply performs an address lookup or a reverse address lookup. More complete information can be gathered using dig. On extremely old systems, nslookup might still be the only available option for this type of testing, but it is rather confusing and inconsistent in a number of ways and is not recommended.
The host utility provides a very easy to use command line interface for looking up a name or an address. In its simplest usage form it will return the IP address or addresses when given a host name as its argument. The mail host address or addresses will also be returned if available. If the command line argument is an IP address, a reverse lookup will be performed and the host name will be returned. host also has a few additional options that may be helpful in tracing DNS problems or testing your configuration for correctness. You may query your system default name server, or you can query any name server you need to test by appending a server address to the end of the command line.
The simplest usage of host is to lookup an address, or a name.
[joe@delilah joe]$ host swelltech.com
swelltech.com has address 216.40.244.74
[joe@delilah joe]$ host 216.40.244.74
74.244.40.216.in-addr.arpa domain name pointer swelltech.com.
Above, I've requested the address for the domain swelltech.com, and then the name for the address 216.40.244.74. I could also ask for the name servers that are authoritative for a domain by using the -t ns command line option..
[joe@delilah joe]$ host -t ns google.com
google.com name server ns2.google.com.
google.com name server ns3.google.com.
google.com name server ns4.google.com.
google.com name server ns1.google.com.
Finally, the MX record can be retrieved by using the -t mx option.
[joe@delilah joe]$ host -t mx yahoo.com
yahoo.com mail is handled by 1 mx2.mail.yahoo.com.
yahoo.com mail is handled by 5 mx4.mail.yahoo.com.
yahoo.com mail is handled by 1 mx1.mail.yahoo.com.
In the above MX record example, yahoo.com has three mail servers defined. The MX record has an additional field to indicate the priority of the server relative to other servers, in this case mx1.mail.yahoo.com and mx2.mail.yahoo.com have a priority of 1 so they will be preferred over mx4.mail.yahoo.com, which will only be used in the event the other two servers are unavailable.
| Note |
|---|---|
Not all options of the host utility are discussed here. For more detailed coverage of all of the command line options consult the host man page, either via the Webmin man pages interface or from the command line. | |
The -v option enables verbose output, which is in a format compatible with BINDs own master file format, so it can be directly imported into a BIND configuration without additional parsing or modification. The -t option allows you to specify the query type to make of the name server. There are many query types, but common types that may be useful include cname which lists the canonical name entries for the host if available, and the ns type which lists the authoritative name servers for the host.
One of the more verbose options of host is the -a option which will list all available fields for the host, including all A records, CNAME records, NS records, etc. Using host with this option against your own name server is a good way to insure it is providing all of the information you expect.
The dig, or domain information groper, provides the ability to query any domain server for information about the domains it serves. It operates in both an interactive mode and a batch query mode. Using dig is much like using host, in that in its simplest mode you enter just the command and the name to lookup. However, dig is more verbose by default and presents a much wider array or information, though in a somewhat less readable form.
Just like host, it is possible to query your default system resolver, or you can query a name server specified on the command line. For example, I could query my local name server about the nostarch.com domain.
[joe@delilah joe]$ dig @192.168.1.1 nostarch.com
; <<>> DiG 9.2.1 <<>> @192.168.1.1 nostarch.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21448 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;nostarch.com. IN A ;; ANSWER SECTION: nostarch.com. 8585 IN A 66.80.60.21 ;; AUTHORITY SECTION: nostarch.com. 8585 IN NS ns1.megapath.net. nostarch.com. 8585 IN NS ns2.megapath.net. ;; ADDITIONAL SECTION: ns1.megapath.net. 123591 IN A 66.80.130.23 ns2.megapath.net. 123591 IN A 66.80.131.5 ;; Query time: 281 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Sat Oct 26 19:42:45 2002 ;; MSG SIZE rcvd: 126
Above, we have a large amount of information, though not all of it is generally useful to us. First is the version of dig, and the command line options we specified. The comes some status information, including the NOERROR designator that indicates the name was retrieve without error. If the domain did not exist, or could not be queried, there would be an NXDOMAIN error or some other error. Next are the flags of the query. In this case, we have one query and one answer which are contained in the QUESTION and ANSWER sections below it. The next two items inform us of the number of AUTHORITY and ADDITIONAL sections that follow. In this case, the authority section gives us the primary and secondary name servers for this domain, ns1.megapath.com and ns2.megapath.com, and the additional section provides the IP addresses of those name servers.
The last few lines give the time the query required, the server that was queried and the port on which it was queried, the time and date on which the query was made, and the size of the message received from the name server.
Like host, dig has a mode in which you can query all of the information available about the domain. This can be done by appending the ANY argument to the end of the command line. Furthermore, the options NS, MX, CNAME, etc. are also available and do just what you would expect.
Tidak ada komentar:
Posting Komentar