|22 Mart 2003
- System components and interaction
- Detailed description:
- Access control
- Additional documents.
- Required software.
ProBIND2 DNS management system allows control few
DNS servers (usually consisting a single domain name space, or a few
different name spaces, for example – external name space and intranet
name space) from the central management system. This system consists of
the central database repository (one for every namespace), ProBIND
scripts, web interface, and network of Name Servers (different for every
namespace) configured from this central database.
Picture 1 explains how system works. There is
central management server, which maintains database. System
administrators can manage this system thru the web. ProBIND system
(which is a set of PhP scripts for Apache web server) allows operators
to change data, configure name servers, add and remove zones, disable
and enable them, disable RR records in zones without deleting them, and
When updates in the database are completed
(and verified), it generates configuration and zone files for all name
servers in this namespace, push this files onto the servers, check
configuration and reconfigure the servers.
Picture 1 shows how system components interacts
one with other (on example of the data center):
DNS system consists of the Internal and External
Name spaces, and all components are replicated for both name spaces.
There is starting menu, which allows to switch between external and
internal name spaces, and (optionally) to go to the test name space
(which can be used for the training, testing and verification). Every
component exists in both name spaces:
- Central ProBIND system:
- Web server (Apache, port 8100,
shared by all name spaces and all management systems), with basic
authentication, php and mysql support;
- MySQL databases (‘intdns’ for
internal DNS and ‘extdns’ for external DNS).
- ProBIND scripts running by the
web server and implementing access to the system;
- Template directories which are
used to generate configuration files for the name servers;
- push scripts that push data to
the servers and reconfigure servers; standard scripts uses ‘rsync’
through the ‘ssh’.
- Test and import scripts, which
allow to test name servers (from the web interface) and to import
standard named.conf configurations (and zone files) into the
- Set of master name servers, which
maintains full set of master zones and keep secondary zones.
ProBIND allows to have a few master servers, and maintains exactly
the same zones (including serial numbers) for all of them’. For
internal name space. This servers are fully configured by ProBIND
system – it generate named.conf file, zone files and all additional
configuration files (from the template);
- Set of slave name servers, which
maintains ‘slave’ zones for the zones owned by ProBIND. Internal
name servers maintain (due to some resolving problems in the
splitted name space) all zones (including secondary).
Probind works with the standard bind version 9
(preferred) and can work with bind version 8 (without configuration
checking because ‘ndc’ does not supports it). Scripts uses standard
‘ssh’ feature by the ‘password-less’ remote access. No any components
(excluding very first named starting which is done by the system rc.*
files) is running as a root, which increases security.
- Name servers, MySQL and apache
are started by the operation systems;
- Operator can browse, add, delete
and edit zones, using web interface (see Picture1 as an example);
- When everything is completed,
‘Update’ operation is called. ProBIND makes ‘Update’ in the few
steps, applied to all servers (operator can make this steps at once or
do them one by one and check logs and files after every step):
- Generates all configuration
files for all name servers, using template directories and
database information; files are stored in the local directories;
- Run ‘Push’ scripts which
synchronizes content of configuration directories on the local and
- Run ‘reconfigure’ scripts
(they uses ‘rndc’ program for bind9 and ‘ndc’ for bind8) which
verifies configuration and reconfigure the servers;
- Run (manually) tests which
allows to send request and verify an answers;
- Save changes into the CVS (if
configured) to allow simple rollback of the zones.
- To minimize possible risk of
failure, system applies changes onto the servers that need it (for
example, if zone content changed, no any changes will be applied to
the slave servers).
ProBIND system supports a set of additional
- Automatic generation of the ‘PTR’
records by the ‘A’ records (controlled by the checkbox); it
generate this record during zone generation and has not a problem
of dead PTR records (after A record was removed);
- Duplicate A and PTR records
detection – verify data base and shows all multiple A and PTR
- IP address allocation – allow to
find unused IP addresses, shows duplicate names on the same
address, and so on;
- Lame delegation and MX violation
check – useful for the external zones;
- Bulk update – allows to
regenerate all files (with the new serial numbers);
- Log and configuration access –
allows to view configuration files and logs from the web (so
eliminates local logins to the remote systems and increases overall
- Server tests – sends requests and
show answers to the DNS system.
- Serial numbers include date,
allowing to restore database from dump and to apply them to
the servers without manual removing of the sticked secondary zones
(which happens if convenient file backup is restored and zones got
old Serial numbers – it often results into the desynchronization.
- Configuration directories
(named.conf and zones) are saved into the CVS, which allow to restore
old version or to compare configuration files. (Saving database into
the cvs can be easily added to the system, it allows to rollback any
changes without any manual manipulations with the serial numbers).
ProBIND system supports a convenient control over
the zones and records – it allows disabling zones and records temporary
(without removing information from the data base), and supports comments
to the zones and records. First feature is very important because it
makes zone cleaning much safer – it is always possible to disable a
record, and remove it only after a few days of running without the
problems (or enable it back if it cause any problems).
ProBIND version 2 uses standard apache security
and access control. Two gropups are used:
- dns - allows to browser, view
and edit zones, update servers (without cleaning sticked locks),
and use any additional operations. Do not allow – to change system
setting, add/delete servers, add/delete zones, make bulk
updates, clean locks.
- dnsadm – allows all operations.
Security level is intranet rank – this means that
system should not be opened to the outer world without extra level of
protection; and no dns group can be granted to the un-trusted
persons. This group protects against errors but do not protect against
Web access system includes web interface to the
user and group list and replicates information for all web servers
involved into the monitoring (SFO management system, log files access,
and so on).
- Very simple web based user
interface, combined with the power and reliability of the standard
classical name server for Unix (bind 9);
- No any manual operations, remote
logins, file editions required for:
- Zone adding and deleting;
- Zone option change (such as
zone access list);
- Server option change (such as
- Zone viewing and editing;
- Serial number change;
- Configuration verification and
- Embedded name server testing,
file view and log access (no need for the local access once again);
- Automatic serial synchronization
in case of a few master servers (it is important for production
because name server must work even if zones expired or master
server die, so few masters increase reliability);
- Automatic PTR generation on the
fly (no chance to stick PTR after A record was deleted);
- Disabling records and zones
without deleting them decrease a risk of mistake during zone
cleaning and allow introducing temporary changes.
- IP range control makes IP
allocation easy and safe;
- Central data base allow to deploy
new name server (in addition or instead of existing one) instantly;
- Separating data base and
configuration files allows to work without any interruption in case
of the data base failure, and MySQL database allows to deploy new
management station in a few days on a new platform.
- Web access allows easy
integration with the authentication systems and into the network
management system (which must always be WEB based).
operational guide , version 2.0.
- Management system:
- Apache 1.37;
- MySQL database system;
- PhP4 scripting (apache module
and standalone interpreter);
- Perl5 and some modules for it
(for DNS testing and verification).
- (optionally) cvs.
- DNS servers:
- bind9 or bind8 name server;
- ssh and rsync,