DMS System Architecture
In Fig:DMS System Architecture, only one of the DR replica pairs is shown below for clarity. As shown in Fig:Conceptual Network Layout the standby replica runs as a server of the replica SG group. PostgresQL Replication is also live to the DR replica, carried over the IPSEC connection between the DR master and replica servers. The master/replica servers use iptables/ip6tables to filter access to services carried over IPSEC.
Conceptual Network Layout
The DMS is designed to support anycast and unicast servers, as per Best Practice Guidelines.
The DMS backend software is written in Python 3.x, which is a good choice given the code base size of 22,000 lines. Python is well suited to larger projects, and fully object oriented, and very clear and systematically defined. Python 3.x was chosen over 2.x for future proofing.
The Python JSON RPC interface is implemented with Apache2 mod_wsgi, with a back end DNS Manager Daemon. zone_tool is a command line shell environment that implements all the functionality of the JSON RPC calls, as well as DMS systems configuration and management functionality. This common code functionality allows the JSON RPC calls to be called from a terminal, where a debugger can be used, for ease of development.
A state machine and event queue design is used, with state and event information recorded in PostgresQL. State machines exist for each:
Decided to go forward using ISC Bind 9 as DNSSEC is on the way, and Bind 9 will be the software used to roll this out. Other implementations of DNS software exist, Netlabs NL NSD3 is one, but it looks more suited to a TLD registry and large site/domain use than for DNS Provider use for small zones.
The DNS server state machine classes are designed so that NL Netlabs nsd 3.x can be added latter on as a slave server. This is done achieved by the use of state machine design, object oriented code and modularity.
A Hidden Master DNS architecture is implemented, with a DR replica master server.
PosgresQL 9.1+. PostgresQL has a significant history of high end functionality including transactions and stored procedures. Replication is also baked in as well.
DNS Website Software (DNS Management Interface - DMI) will communicate with DMS via the WSGI server. The DMS server can handle multiple Web UIs via different Web services URIs. An administrative help desk DNS Management Interface can be implemented as well. To begin with, the DMS will be administered via zone_tool by ssh into the Master DMS system.
DNS and logging traffic between the slave servers outside Net24 is be secured using IPSEC. Iptables filtering and IPSEC SAs are used to control the traffic that the slave servers accept from the network and Internet. IPSEC SAs exist for zone update and port 53 administrative traffic, and secure that traffic. Ie, DNS Traffic from the Master DNS server will be secured using IPSEC. This keeps all the cryptographic verbiage out of the DNS server configurations, and makes them a lot simpler to generate from templates. IP numbers and acls may need to be inserted in the named.conf files to identify the designation of administrative control and updates from the Master DNS server, but this is a lot easier that having to track of lot of configuration details about TSIG/SIG0 keys for each individual master-slave relationship, and where they are used....
The Web GUI for the DMI will be rendered using ExtJS. Check logic, and business logic will be separated out and not mixed in (as much as possible) with the UI. This is basically a Mode View Controller programming model.