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 nameservers relationship to the data it presents to clients.
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.
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 thus has the most configurable options. 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.
Figure 8-6. Creating a new master 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 IPs 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 hostname 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 nameserver record in this zone for this nameserver. 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 nameservers 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 should then return to the main BIND module page and create another master zone. This time, you will choose to create a reverse zone, in order to provide mapping from IP addresses to names.
Figure 8-7. Creating a Reverse Master Zone
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. 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 we will not cover those options here.
Figure 8-8. Edit Master Zone
Address – An address record allows you to enter the hostname, the time-to-live, and the address for a host. Every host on your network should have an Address Record. In the example, note that I’ve entered the fully qualified hostname, 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 a A record.
Figure 8-9. Adding an Address 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 a 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 hostname 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.
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. email@example.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. 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.
Figure 8-10. Creating a Slave Zone
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 nameservers. 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 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.