changelog

BIND 9 dynamic DNS webmin module. This module supports both static and dynamic zones, and IPv4 and I

8) The module configuration check was not correctly testing some of the options
with pathnames. If named was to be run in a chroot'd directory then this was
not always accounted for, and as such the module would always report a
configuration error. This has now been fixed. The required BIND commands are
checked first, then the chroot directory itself, and then the, possibly
chroot'd, directories for the named.conf file, the PID file (if set), and the
zone file directory. Thanks to James Deucker for reporting this bug.

7) If named.conf does not exist and is therefore created, then the directories
for the 'directory' and 'pid-file' options are created if necessary. They have
their ownership set according to the module configuration option specifying the
zone file owner. (If we didn't do this then it may not be possible to create
zone files.) Although the main index page will check, for example, any
specified PID file directory, if named.conf does not exist then the overall
global values for the zone files (in /var/named) and the PID file (in /var/run)
have to be used. Hence we must check, at this time, that they exist.

6) When the named.conf option 'random-device' was set it wasn't being quoted.
Also a check was made that the device was a 'file', which would fail because
the device is a 'device' (a character device on my linux box). These have now
been fixed.

5) Renumbered this file (ChangeLog). Each release has its own modification
numbering rather than continuously incrementing the change number.

4) A 'Record filters' section has been added to the zone page to allow the user
to specify the names of records to be shown and/or hidden. This was initially
written to help speed up the displaying of large zones. By filtering out those
records which we did not want to display, or alternatively to specify those
records we did want to display, only the relevant record(s) were shown and this
was much quicker than trying to display all the records. However, this could
also be useful for smaller zones since it is equivalent in function to the user
specifying a 'search'.

The input format is a space-separated list of regular expressions. The record
label is checked against the filters, unless the 'Use record value' checkbox is
ticked. In that case, the record value is used. This allows the user to, for
example, enter a domain name to be shown and then selecting PTR records only
those records with this domain as its value will be shown.

Note that care must be taken when filtering records. If, for example, the IP
address '127.0.0.4' is entered for hiding, and the 'Use record value' box is
checked, then when selecting 'Address' records this setting will exclude *all*
the records containing 127.0.0.4 within its value. That is, the records
127.0.0.40, 127.0.0.41, 127.0.0.42, etc will also be hidden. To ensure that
just the one address is hidden use the expression '127.0.0.4$' instead.
Likewise with domain names - using 'dhcp' would hide every record containing
this name. To ensure that just that particular sub-domain is hidden then use
the setting of '\.dhcp\.' instead.

The module configuration has a new option which allows the filters to either
always be displayed, never be displayed, or only be displayed if the zone has
more than the specified number of records (in total). By default the filters
are configured to only be shown if more than 5000 records exist in the zone.

The filters are shown on the web page for each zone were the record types are
displayed. Having set the filters and then selecting, for example, 'Address'
records, then when returning to the zone page the filter settings will be
remembered. The filters have no effect when selecting to view 'All records'.

When the records are shown, if any records have been filtered out then a single
text line will be displayed indicating how many records there were in total,
how many were hidden and how many displayed. If all the records were filtered
out then the message will state this. If no records were filtered out, or the
filters not set, then no message appears.

3) There was a bug whereby if the BIND version was less than 9.2 then the PID
file was used to determine if named was running or not. However, neither the
PID file pathname, nor non-existant or empty PID files, were catered for. In
these cases the named status would have been shown as 'unknown'. These cases
are now catered for and the named status is now correctly shown as 'not
running'. The PID file pathname is now correctly determined from the named.conf
file.

2) If the index page name server controls shows 'unknown', then a more detailed
reason as to the cause of the problem is now shown in brackets.

1) Added three new module config options. The first is used to specify the IP
address or DNS name that is to be used for queries - for example, 'dig
localhost. @xxx' where 'xxx' is the configured address or DNS name. This option
is used whenever the SOA serial number of a dynamic zone needs to be checked
(amongst other things). The second option specifies the IP address or DNS name
to be used for the zone transfer of dynamic zones. The third option is used to
specify the IP address for DNS updates. In all cases the IP address can be IPv4
or IPv6. All the options default to the localhost address of 127.0.0.1. The use
of these options allow the administrator to specify, for example, zone
transfers from the local host, but allow queries and/or updates to appear from
a different address.

Version 1.0.3 released onto SourceForge.

7) The banner for forward zones and the zone options was not being displayed
correctly. This has now been fixed.

6) Executing an 'rndc' command on a remote server is now logged on that server
as well as on the local one. Creating or deleting a slave zone via the master
is also logged on the remote server. This allows an administrator to see not
only when, for example, a master zone was created but the fact that the slave
was also created.

5) Creating delegated zones from a dynamic zone was not working correctly. The
reason being that nsupdate would try and update the delegated zone rather than
the parent. Calls to nsupdate are now preceeded by a 'zone' statement, which
for delegated zones will mean the parent.

4) The rndc command code has been reworked. Previously dynamic zones, for
example, were being reloaded when in fact this is not required. Likewise,
changes made to the zone options were not being invoked unless an 'rndc
reconfig' was done from the main index page. This will now occur via the 'Apply
changes' button in the relevant zone page.

The 'Apply changes' button for a zone will now execute an 'rndc reconfig', an
'rndc reload', or both, depending on the type of zone and whether any changes
have been made to the zone options.

Typically the root zone, forward zones, slave zones, stub zones, and dynamic
zones will do a reconfig and not a reload - that is, only a static master will
do a reload.

Converting a zone to or from a slave will also cause a reconfig to occur.
However, moving a zone will not do this because after the move we do not know
which zone to display, so the index page is shown. An 'rndc reconfig' can be
done from there.

3) New zones were added to named.conf with no specific zone class. All new
zones are now created as Internet ('in') type.

2) Changes to slaves with allow-update-forwarding set, and in which the forward
or reverse zone is to be updated as well, could fail. The reason being that the
host with the slave on it may well contain the slave for the forward/reverse
zone as well. This is the most likely scenario. As such we need to treat
updateable slaves as if they were masters, so that both the forward and reverse
zones can be updated. Obviously the relevant forward/reverse zone must have the
allow-update-forwarding option set on it, and it must be updateable from the
host. Checks such as requiring the zone to be updateable, and whether an IP
address is in use or not are all now executed for updateable slaves as well as
master zones.

1) Added a NOTES file. Administrators should read this file since it will
include querks of the module. These may seem like bugs but are actually known
items.

Version 1.0.2 released onto SourceForge.

6) Displaying views categorized by zone did not work due to a variable being
overwritten. This has now been fixed.

5) Views will now be displayed in a table, similar to the zones, when
configured to be displayed as a list. When configured to appear as icons, then
they will appear as such. Previously views always appeared as icons.

4) A typo prevented the view name appearing with the zone name. This has now
been re-written such that when views are used, the zone table will show a third
'View' column (when zones are not categorized by view). When displayed as
icons, the zones will include the view name in the icon title.

Note: Use of the table should make it easier to see if any zones are not
configured into a view (which is not allowed at BIND 9).

3) Added the view options 'match-destinations' and 'match-recursive-only'. Both
of these options require BIND 9.2 or above, otherwise they will be greyed out.
The default now in the create view form for 'match-clients' and 'match-
destinations' is to allow access by all clients and to all destinations -
previously the default option was any listed IP addresses, ACL's etc. However,
if the user didn't enter any then an empty list was created. Removed the record
class option for views - this module only uses the 'IN' class.

2) Corrected a bug in the date-based SOA serial number code. Calculating the
number of days during a leap year, which 2004 is, included the leap day before
it had actually occurred! This meant, for example, that just changing the SOA
mailbox (email) address could fail since the serial number could look like a
future date, which, depending upon the configuration, wouldn't be allowed. This
has now been corrected.

1) Fixed a bug with the mailbox (email) address being quoted in SOA and RP
records. This should not occur. Thanks to James Saint-Rossey for reporting
this. Also tightened up email address checking a little bit more. The use of
'.' as an SOA email address is not allowed (whereas it is perfectly valid in
the RP record).

Version 1.0.1 released onto SourceForge.

2) The top-level and sub-domain name checks for SRV records was not being
performed correctly. Sub-domain names were being seen as top-level names, and
top-level names were not being handled correctly if they contained sub-domains!
This has now all been corrected.

1) The top-level domain name check worked fine for A/AAAA type records but not
for other record types. This has now been corrected. Thus it is possible, for
example, to just modify a top-level names MX preference value - this is allowed
because the top-level name itself is not being changed.

Version 1.0 released onto SourceForge.

88) Removed redundant entries from 'en' file. Hopefully I haven't deleted
anything that should have been there!

87) Added a forward zone, A record, sort option, to sort the record labels by
their sub-domain names. The sort function starts with the top-level sub-domain
name, then the second-level, and so on. The origin is not included in this
sorting. The option appears as the text '(sd)' next to the 'Name' column label.
Labels with no sub-domain will appear interspersed amongst the sub-domain
sorting, but all the records for a sub-domain will appaear toegther.

86) Added per-user display options to 'hide' specified forward or reverse
records based upon a regular expression. This is read as a space separated
list, so several expressions can be specified. For forward zones the check is
done on the record label of all record types. For reverse zones the check is
done on the record value of PTR records (that is, the domain name the record
points to). If there are hidden records then a line before the displayed
records will indicate how many records were seen in total, and how many are
hidden. When selecting to view all records, then all the records will be shown.
For forward zones a '.*' will be appended to the expression unless a '$' is
seen at the end. The origin will then be appended to the resulting expression.
The checks are not made against the origin itself, but against anything
preceeding it. For example, given the origin of 'abc.example.com':

	\.dhcp$	   would hide records ending in \.dhcp\.abc\.example\.com\.$
	\.dhcp			"		\.dhcp.*\.abc\.example\.com\.$
	abc.example		"	abc.example.*\.abc\.example\.com\.$
	\.			"		\..*\.abc\.example\.com\.$

The last example is a good one since it actually hides all the sub-domained
records, so only the zones top-level names are shown. Note that the origin
automatically has any dots in it escaped. For a reverse zone we might use:

	\.dhcp	   would hide any PTR record domains containing \.dhcp
	\.dhcp\.abc\.example\.com\.$

For reverse zones we have to specify any origin associated with the record
value - as in the last example above. Needless to say, these options are
probably not useful on small zones. However, with large zones they can be useful
to hide, for example, dhcp entries.

85) Completed the DNAME record support. These records are available for both
forward and reverse zones, and for IPv4 and IPv6 addresses. For IPv6 addresses
the records MUST be entered with all the required leading zeros specified in
the last part of the address. Otherwise the code has no idea where the subnet
actually ends. For example, '...:ae' could mean ':0ae', ':00ae' or just ':ae'.
Checks are made for reverse records that the entries are of the same length.