changelog

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

Without this, it would be possible to cause BIND to, in effect, lookup invalid
addresses. This is allowed by BIND because CNAME's are used, and the CNAME
value can be anything. Record collision checking is carried out to ensure that
there are no existing records within the DNAME domain, and that no DNAME or
CNAME record exists of the same name.

84) For static zones any $GENERATE records are now displayed if all the records
are to be shown. These are shown as record type '$GEN'. Whilst this does speed
up the reading of large zones, this is only a short-term fix for dealing with
this directive.

83) Previously when deleting a zone, and the forward/reverse records are to be
deleted as well, no account was taken of the zones SOA serial number. As such,
for date-based serial numbers, it would be very easy to exceed the limit of 100
changes per day. We now not only take care of dynamic zones, and use nsupdate
to remove the record, but we check that the serial number is indeed updateable.
For any record or zone which we cannot modify, the record is ignored. It is,
thus, very much up to the administrator to ensure that all forward/reverse
records are deleted from the relevant zones. All that webmin can do in this
situation is provide some help by deleting those records to which it does have
access.

82) Journal files are no longer deleted via the main (index) page. The user may
have configured a dynamic zone to be static, but not have reloaded named yet.
As such the journal file could contain record changes which would be lost if
the file was deleted. At present journal files are only deleted when a zone or
view is deleted, because the zone file itself will be removed. It is,
therefore, up to the user to ensure that any remaining journal files are
deleted.

81) If a user creates an IPv4 or IPv6 address record, or a PTR record, which
already exists, an error message is now displayed. This occurs if the domain
name AND the IP address already exist in a record. Previously the record would
have been created, resulting in two records which were identical. I can think
of no use for this at all. If only the TTL changed then the forward and reverse
records were not updated, this now occurs (to the existing forward/reverse
record and to any created record). Similarly, specifying that a forward/reverse
record is to be automatically created, but it already exists, will not result
in a new record. The old record will be updated instead (see point 24 below).

80) When creating a master zone, or setting the global zone defaults, a default
TTL value for the zones records can now be set. This value is placed at the top
of the zone file in a $TTL directive.

79) As before, if there are too many zones to display then a search box is
displayed instead. However, it is now possible to find the root zone simply by
entering the word 'root' or 'hint'. Just hitting the search button, with no
text being entered, will return all the zones. The search pattern is also now
trimmed before being used.

78) Allowed remote servers to execute the 'rndc reconfig' command. When a zone
is created or deleted then the remote server, and the local one, will need to
use 'reconfig' rather than 'reload'. For the local server a 'reconfig' will be
done for new zones even if the 'reload' button is used. Enabled logging to
webmin of the rndc commands executed. Added a button to the index page to flush
the local name server cache. Merged the reload_slave.cgi file into
rndc_cmd.cgi.

77) Modified the code creating zone types. Zones are now created using the more
generic address match list subroutines. This allows, for example, forward zones
to be created with specific ports and/or a master port specified, and creating
a master zone it is possible to specify a port that the slave should use. This
also avoids us having to open/edit/close the named.conf file since the zone is
added using the tidier 'save_directive'. Examples:

	'10.0.0.1 port 97'		IP address using port 97
	'port 103'			Default port number (103) to use

Each entry should be added per-line, but it is possible to enter them all on
one line.

76) Added a per-user ACL specifying that the forward/reverse zone, when
modifying an A/AAAA/PTR record, must be updateable by the user. The requirement
was that when an A/AAAA/PTR record was being modified then the relevant
forward/reverse zone MUST exist AND be updateable by the user. An example would
be a site not using private addresses (RFC 1918), and as such they do not want
anyone entering, for example, a 10/8 address into a DNS record. It is already
possible to specify that the reverse/forward zone must exist. It is also
possible to specify that the user may not edit a given zone, but any attempt to
update the zone, via automatically updating the forward/reverse record, is
currently silently ignored. In the above example this would lead to invalid
data being added to the DNS. This new option ensures that all the relevant
zones are updateable, even if the user selects not to update the
reverse/forward zone when modifying a record. By default users are not required
to be able to update the forward/reverse zone. Wildcard records do not update
the forward/reverse zone, but the user will still be checked to ensure that
they can update the zone if this option is set. This option is not checked when
a zone is being deleted.

75) Reworked the record sort code. It is now possible to sort on specific
record attributes - for example, the priority value of MX records. (The code
for this was present in the BIND8 module but it didn't work.) The use of a
numeric or lexical sort is determined by the attribute being sorted. Not all
attributes can be sorted - for example, the email address in RP records.
Reverse zone records are now correctly sorted  - previously only PTR records
were sorted by their IP address, but in a reverse zone all the record types
should be sorted by the address. IPv6 addresses, both forward and reverse, can
be sorted.

74) Added a per-user ACL allowing or disallowing the user to create or delete
top-level sub-domains. That is, such as 'www.finance.example.com'. The user
will be restricted to whether they can create or delete the sub-domain
'finance'. They will be able to change other attributes of the record, for
example, the TTL value or whatever data is associated with the record. As below
there is an option to restrict the user to only creating or deleting sub-domain
names from the master zone. There is also an option to allow or disallow the
user to create or delete sub-domains at the second-level or below, but they
cannot create or delete top-level sub-domains. This allows an administrator to
let users create and delete sub-domains as they wish but only within the
existing top-level sub-domains within the organisation. By default users can
create and delete any sub-domain names.

73) Added a per-user ACL allowing or disallowing the user to create or delete
top-level names within zones. That is, names such as 'www'. Users can modify an
existing record, but can/cannot change its name. So, for example, they cannot
change the name of 'fred.abc.example.com' to 'www.example.com'. Likewise they
can/cannot change the name of 'www.example.com' to 'www2.example.com'. NS and
DNAME record labels are not considered as zone top-level names, and as such are
not checked. An option to allow names to only be created within master zones
has been included. This will prevent users using slave update forwarding to
create top-level names when the owner of the zone master does not want that to
happen. By default users are allowed to create and delete top-level domain
names.

72) Added ability to sort records on record type. This is only avilable when
all the records in the zone are being shown.

71) Changed options for the global 'Miscellaneous' section. Removed obsolete
options for multiple CNAME's; fetch glue records; AA bit set for non-existant
domains - this was only required for old software. Added options to provide
minimal responses; ability to blackhole sites; set BIND version string; set
entropy device for DNSSEC; enable zone statistics; set the maximum cache and
negative caching TTL values. The 'statistics-interval' option has been greyed-
out since it is currently not supported. However, the documentation implies
that it may be supported at a later version, so the code has been left in.

70) Added options to the global 'Other DNS name servers' - Added option for
EDNS, and options to provide and/or request IXFR. Added 'Default' buttons to
the options to allow them to be 'unconfigured'. Currently each server can only
use one key but the code is present to cater for multiple keys (it only
requires commenting out the error message produced when multiple keys are
selected).

69) Where necessary old keys will be displayed. That is, keys which were
defined but have now been removed, but whose names are still present in certain
options. The user cannot select to use these keys, but they will have the
option to remove them - usually via a checkbox.

68) In the global 'Zone Defaults' options the 'Allow transfers' option has been
moved to the 'Forwarding and Zone Transfers' options, and the 'Allow queries'
option has been moved to the 'Miscellaneous' options. This seems to make a bit
more sense since 'Zone Defaults' should only set defaults for new zones,
whereas the above options apply to all zones. So changing them would affect all
zones and not just any new ones - that seemed at bit risky. These options can
be set per zone within the 'Edit Zone Options' section.

67) When configuring a key the secret must be supplied.

66) The use of the 'Can apply zone and named changes - only to zone' ACL option
is only available with BIND 9.1 and above. The rndc program of previous
versions did not support the reloading of individual zones.

65) Modified the address input and output code. This is now mainly handled as
an 'address match list', with specific options where only IP addresses are
allowed. Generally this should mean the user can enter either an IP address -
version 4 or 6, an IP subnet, an ACL name or one of the reserved words. The use
of the '!' symbol is also supported.

64) Empty zones will display a message at the top to indicate that something is
possibly wrong. For dynamic zones, new slave or stub zones, or zones with no
'file' option, this could indicate the zone transfer has failed.

63) Added options to the global 'Control Interface' options - Added support to
recognise keys, and enabled recognition of the instances where all IPv4 (*) or
all IPv6 (::) interfaces are to be used. Also enabled support for disabling the
control interface (which is not the same as letting it default because that
enables the interface). If no keys have been defined then the user can only
disable the interface or allow it to default. If the interface is disabled then
the named status on the index page will state this.

62) Added options to the global 'Ports and Addresses' options - Added the
'listen-on-v6' and 'query-source-v6' options, and enabled both this option and
the 'query-source' option to take '*' as a value meaning 'any' for the address
and/or port.

61) Added options to the global 'Forwarding and Zone Transfers' options - Added
'max-transfer-time-out', 'max-transfer-idle-in', 'max-transfer-idle-out',
'max-transfers-out', 'notify', 'also-notify', 'provide-ixfr' and 'request-ixfr'
options. The notify options have been removed from the global 'Zone Defaults'
settings.

60) Added the named.conf 'directory' option to the 'Files and Directories'
global options. This option was set when creating new zones, but it was not
possible to modify it.

59) Removed 'named-xfer' named.conf option - it no longer exists at BIND 9.

58) Modified the 'zone directory' options and code because it was a little
confusing - to me anyway! There are 3 possible settings. The webmin user ACL
can set, and restrict, the user to one specific directory - all new zones must
be in this directory, and the user may be restricted solely to that directory.
By default this directory is the root. Secondly, the module configuration can
set the directory for the master/hint and/or slave/stub zone files. As such
this must be either the same as or a sub-directory of the directory set in the
users ACL. Finally, the named.conf file may specify a 'directory' option to
indicate the default working directory of named. If this is set and the zone
file pathname begins with the working directory, then only the shortened name
is stored in named.conf (this seems to be  pretty much what admins who use
'directory' do anyway). Previously it was possible to use different settings
such that it was impossible to create and/or save zones because the different
settings would conflict with each other. To help with all of this the index
page will check the ACL setting and any specified zone directories to ensure
the latter are a sub-directory of the ACL setting. Creating and saving zone
options will, of course, check all this as well.

57) Combined some of the work below so that the user is presented with a more
consistent interface regardless of the zone. Forward zones are the exception
because they have no records to display. All (most?) of the other icons, links
and buttons are either active, in-active or greyed out depending on the access
rights the user has.

56) Slave zones now recognise the 'allow-update-forwarding' option. As such
they will be recognised as dynamic zones. Master zones with the 'update-policy'
option will also now be recognised as dynamic. However, we only check to see if
a 'grant' policy is present - this is no guarantee that the local host can
actually update the zone! When converting to or from a slave or master zone,
all the 'update' type options will be removed from the zone section.

55) Master, slave and stub zones now include an 'ALL' records link; previously
only master zones did this. The link also includes the (read-only) SOA record.
I'm not sure why the SOA record was especially left out. Changing the SOA
record must still be done through the master zone's 'zone parameters' link.
Unknown record types will also appear in the ALL section, but as read-only.

54) Slave and stub zones can be configured with no 'file' option. As such
slaves read their zones by zone transfer, and stub zones read the specific NS,
SOA and A or AAAA records. Changing a zone from using a file to one that does
not use a file will NOT cause the old zone file to be deleted. The reason is
that the file will be in use up to the point that the zone changes are
applied - but that might never happen if the user changes their mind!