To allow dynamic zones to work, the IP addresses and domain names in themodules configuration and the named.conf file must agree. To that extent thereare module configuration options which specify the address or domain name to beused for DNS queries and zone transfers. The IP address for DNS updates canalso be specified. These addresses must agree with those specified in thenamed.conf file. For example, DNS queries are used to retrieve a dynamic zonesSOA record, and to retrieve the NS records of stub zones. If the module has theaddress 127.0.0.1 configured for DNS queries, then named.conf must also havethat address, or the name 'localhost', configured for DNS queries eitherglobally or for specific zones. Similarly the addresses for zone transfers andDNS updates must match. If the addresses do not match then the effect willgenerally be that no zone records are displayed or a timeout will occur intrying to talk to the name server.When creating a reverse zone, of any type, either enter the full reverseaddress, for example '157.10.in-addr.arpa', or enter the IP address in theforward format, for example '10.157'. The same applies for IPv6 addresses.The generation of records, via 'generate records', only supports IPv4addressing. Currently dynamic zones are not supported at all.When a slave or stub zone has just been created, viewing the zone records mayshow a warning line at the top indicating that no records have been found. Thiswill obviously disappear once a zone transfer has occurred. The warning canoccur under other circumstances as well - for example, dynamic zones which arenot allowed to transfer the zone will result in no records being seen.Large zones will be slow to view. Timings of the module code showed that themodule itself only took a few seconds to process the entire zone, including anysorting or filtering of the records. The problem is with the speed of thebrowser in generating a table of the zone. In testing on a 1.3GHz PC with astandard IDE disk and using the Mozilla browser, a zone of 18,000 records tookaround 30 seconds to display - the module itself took around 6 seconds toprocess the zone. Where both the forward and reverse zones are large, and bothzones are to be updated, the time taken will increase even further. The use ofthe record filters can improve the performance simply by significantly reducingthe number of records to display. Secondly, they allow the user to specify thatonly specific records be shown (by entering enough of their FQDN to make themunique).When creating a new zone on a local host as well as on a remote server, thezone options may need to be changed straight away to allow zone transfers fromthe remote server. Once this has been done an 'rndc reconfig' needs to be doneon the local host and on the remote one. This should cause the zone to becomelive on the local server, and for a zone transfer to occur on the remote one.Depending on how tightly you have set up your named.conf, you may also need toallow the local and remote server to query the new zone. This cannot be doneremotely, so you will have to login to the remote server and then set therelevant options correctly.Creating a record of the same name to one already existing, but with adifferent TTL value, will, for static zones, show the TTL values as beingdifferent. In fact named will use the lowest value. Dynamic zones will showthis correctly but static zones, which get their information from the zonefile, will not.It is generally recommended that for options in named.conf that require a filename, either a full pathname is specified or a file name is given and the'directory' option is set with a full pathname. By default BIND will use a'directory' setting of '.' if it is not set. However, this is supposed toindicate the directory that named is run from, whereas with webmin it willactually refer to the directory that the module is run from (usually whereverit is installed). To avoid this, the default 'directory' setting used by thismodule is '/' - the root directory. This seems a more sensible setting, butdoes not resolve the problem that failing to configure named.conf options withpathnames correctly may well give errors.It is possible to run both BIND and this webmin module without 'rndc' workingcorrectly! However, the index page of the module will show the named status as'unknown' since it uses the 'rndc status' command to try and determine if namedis running or not. Several specific errors are catered for, and any remainingones will simply be displayed as an 'unknown' error type. The point is that theadministrator SHOULD have rndc configured correctly before running the module -the module is not concerned with installing BIND, and the installation andconfiguration of rndc is deemed to be part of that process. If rndc is notconfigured correctly then changes to static zones, via the rndc 'reload' and'reconfig' commands, will obviously not work and so the relevant buttons willbe greyed out. Dynamic zones should be okay since they do not need to use therndc command. The creation and deletion of zones will basically work, butgetting named to initially recognise (or not) the zone will not be possiblebecause the reconfigure button will be greyed out.