30.6. Editing a Master Zone
You can use Webmin to edit many of the settings that apply to an entire master zone, such as the expiry and retry times, and the clients that are allowed to query it. These settings effectively apply to all records in the zone, although some (such as the TTL) can be overridden on a per-record basis.
Webmin uses the term zone parameters to refer to all information stored in the domain's SOA record, including the primary name server, administrator email address and retry and expiry times. All of these are set when the zone is created, but you can edit them at any time by following these steps:
1. | On the module's main page, click on the icon for the zone that you want to edit. This will take you to the form shown in Figure 30.4. |
2. | |
3. | |
4. | To change the address of the person responsible for the zone, edit the Email address field. Any @ symbols that it contains will be automatically converted to dots for use in the SOA record, as BIND requires. |
5. | The Refresh time, Transfer retry time, Expiry time and Default time-to-live fields all have the same meanings as explained in Section 30.3 “Creating a New Master Zone”. If records in your zone are going to be changing frequently in future, you may want to reduce some of these times. However, any changes, may not be detected by secondary servers and DNS clients until the old refresh or expiry time has elapsed, even if the new times are much lower. This is because they will wait for the old times to elapse before checking with the master server again to discover the new ones. |
6. | Click the Save button at the bottom of the page when you are done, and then the Apply Changes button back on the module's main page. The serial number in the SOA record will be automatically incremented when the form is saved, so that secondaries know that the zone has changed. |
The is another set of options that you can edit for a master zone which are stored in the named.conf file in the zone's section. These control which servers and clients are allowed to query records in the zone, do zone transfers and update records over the network. The most useful of these options specifies a list of slave DNS servers for the zone that should be notified when a change occurs, so that they can perform immediate zone transfers and thus remain synchronized.
To edit these master zone options, the process to follow is:
1. | On the module's main page, click on the icon for the zone that you want to edit. This will take you to the form shown in Figure 30.4. |
2. | Click on the Edit Zone Options icon, which will bring up a form showing the existing settings. |
3. | The Check names? field determines the level of checking that BIND performs on records in this zone when it reads the records file. The available options are: Warn If an invalid record is found, an error will be written to the system log file, but processing of other records continues normally. Fail Invalid records cause the entire zone to be rejected, but other zones will still be processed normally. Ignore No checking is done at all. Default The global default from the Zone Defaults page is used. If it is not set, then the default compiled into BIND will be used instead. The default is to fail when invalid records are encounterd. |
4. | To have secondary servers notified when records in the zone change, set the Notify slaves of changes? field to Yes. BIND works out which slaves will be notified by looking at the Name Server records for the zone, and the list of IP addresses in the Also notify slaves field. If your zone has an secondary servers, then you should definitely turn this option on. |
5. | To allow some systems to update records in the zone dynamically, fill in the Allow updates from field with a list of IP addresses, IP networks (like 192.168.1.0/24) and BIND ACL names. Only those hosts that match will be able to modify records using commands like nsupdate and if the list is left empty updates will not be allowed at all. You should be careful allowing the dynamic update of zones in which Webmin is also being used to edit records, as it is very likely that updates made dynamically will be overwritten by changes made in this module or vice-versa. |
6. | By default, all DNS clients and servers will be able to lookup records in the zone. This may not be what you want for a zone that is used only on an internal network, as it may give away sensitive information to potential attackers. To restrict queries, fill in the Allow queries from field with a list of IP addresses, IP networks and BIND ACL names. If the field is left empty, the field with the same name on the global Zone Defaults page determines which clients are allowed. |
7. | To restrict the clients and servers that are allowed to perform zone transfers of all the records in this domain, fill in the Allow transfers from field. Often you will only want to allow secondary servers to perform transfers, especially if your zone is very large or contains records that you want to hide from attackers. Enter a list of IP addresses, IP networks and ACL names into the field to limit transfers to only matching clients. If it is left empty, the Allow transfers from field on the Zone Defaults page applies instead. |
8. | To specify additional slave servers to be notified when the zone changes, fill in the Also notify slaves field with a list of IP addresses. BIND normally uses the addresses of all secondary servers for the zone from its Name Server records, but this may not always be complete. |
9. | When you are done, click the Save button at the bottom of the page to update the BIND configuration file with your changes. You will need to use the Apply Changes button on the module's main page to make them active. |
If a master zone is no longer needed, you can use this Webmin module to totally delete it along with all the records that it contains. To do this, the steps to follow are:
1. | On the module's main page, click on the icon for the zone that you want to edit. |
2. | |
3. | When deleting a forward zone, the field Delete reverse records in other zones? controls whether matching Reverse Address records in hosted reverse zones for all of the address records in this one should be removed as well. It is generally safe to set this to Yes, as only records with the exact same IP address and hostname will be deleted. |
4. | Similarly, when deleting a reverse zone the field Delete forward records in other zones? determines whether matching forward records should be deleted too. |
5. | Once you have made your selection and are sure you want to go ahead with the deletion, click the Delete button. The zone's entry in the named.conf file will be removed and its records file deleted. |
You can convert a master zone to a slave zone of the same name without needing to delete and re-create it. This can be useful if the new server is taking over as the master for some domain, or if the master and secondary servers are switching roles. Section 30.8 “Editing a Slave Zone” explains how to carry out the reverse action of converting a slave zone to a master, which may be useful in this situation.
To convert a zone, the steps to follow are:
1. | On the module's main page, click on the icon for the zone that you want to edit, then on the Edit Zone Options icon. |
2. | When you click on the Convert to slave zone button, the zone's entry in named.conf will be immediately updated to convert it to a slave zone. The browser will then return to the module's main page. |
3. | Normally, every slave zone has a list of master server IP addresses it can use to perform zone transfers from. In the case of converted zones, this list will be initially empty unless the Default master server(s) for slave zones module configuration option is set. Follow the instructions in Section 30.8 “Editing a Slave Zone” to set the master servers addresses correctly. |
4. |