ProBIND2 Design document
|
|
|
Document author: |
Alexei Roudnev |
|
Date: |
24 May 2004 |
|
Version: |
2.0-build1 |
|
Status: |
Release |
Table of content
1. System components and interaction
4. Benefits
System components and interaction
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 much more.
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):
Detailed description:
System components
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:
1. Central ProBIND system:
a. Web server (Apache,
port 8100, shared by all name spaces and all management systems), with basic
authentication, php and mysql support;
b. MySQL databases
(‘intdns’ for internal DNS and ‘extdns’ for external DNS).
c. ProBIND scripts running
by the web server and implementing access to the system;
d. Template directories
which are used to generate configuration files for the name servers;
e. push scripts that push
data to the servers and reconfigure servers; standard scripts uses ‘rsync’
through the ‘ssh’.
f.
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 system.
2. 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);
3. 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.
Component interaction.
1. Name servers, MySQL and
apache are started by the operation systems;
2. Operator can browse,
add, delete and edit zones, using web interface (see Picture1 as an example);
3. 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):
a. Generates all
configuration files for all name servers, using template directories and
database information; files are stored in the local directories;
b. Run ‘Push’ scripts
which synchronizes content of configuration directories on the local and remote
system;
c. Run ‘reconfigure’
scripts (they uses ‘rndc’ program for bind9 and ‘ndc’ for bind8) which verifies
configuration and reconfigure the servers;
d. Run (manually) tests
which allows to send request and verify an answers;
e. Save changes into the
CVS (if configured) to allow simple rollback of the zones.
4. 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).
Additional features:
ProBIND system supports a set of additional services:
1. 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);
2. Duplicate A and PTR
records detection – verify data base and shows all multiple A and PTR records;
3. IP address allocation –
allow to find unused IP addresses, shows duplicate names on the same address,
and so on;
4. Lame delegation and MX
violation check – useful for the external zones;
5. Bulk update – allows to
regenerate all files (with the new serial numbers);
6. 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 security);
7. Server tests – sends
requests and show answers to the DNS system.
8. 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.
9. 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).
Access control
ProBIND version 2 uses standard apache security and access
control. Two gropups are used:
1. 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.
2. 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 serious hacking.
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).
Benefits
1. Very simple web based
user interface, combined with the power and reliability of the standard
classical name server for Unix (bind 9);
2. No any manual
operations, remote logins, file editions required for:
a. Zone adding and
deleting;
b. Zone option change
(such as zone access list);
c. Server option change
(such as notify list);
d. Zone viewing and
editing;
e. Serial number change;
f.
Configuration verification and applying.
3. Embedded name server
testing, file view and log access (no need for the local access once again);
4. 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);
5. Automatic PTR
generation on the fly (no chance to stick PTR after A record was deleted);
6. Disabling records and
zones without deleting them decrease a risk of mistake during zone cleaning and
allow introducing temporary changes.
7. IP range control makes
IP allocation easy and safe;
8. Central data base allow
to deploy new name server (in addition or instead of existing one) instantly;
9. 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.
10. Web access allows easy
integration with the authentication systems and into the network management
system (which must always be WEB based).
Additional documents.
1. ProBIND
operational guide , version 2.0.
2. ProBIND2
Instatllation guide.
Required software.
1. Management system:
a. Apache 1.37;
b. MySQL database system;
c. PhP4 scripting (apache
module and standalone interpreter);
d. Perl5 and some modules
for it (for DNS testing and verification).
e. (optionally) cvs.
2. DNS servers:
a. bind9 or bind8 name
server;
b. ssh and rsync,
Changes.
Version 2.0-build1
-
Few minor bugs fixed;
-
Push scripts fixed;
-
Import improved;