Skip to content. | Skip to navigation

Personal tools


Python Plone Linux and Debian
You are here: Home / Software / DNS Management System

DNS Management System

Aka 'DMS'. A DNS Management System back ended on PostgreSQL, written in Python 3. Can handle 50,000 - 100,000+ domains.

Source Code:

Also need py-magcode-core

Documentation: DMS-090713-1002-38.pdf

Dump from Net24 Wiki.  Please replace 'Net24' in PDF with 'DMS'

Please see Technical Notes|Master Server Install from Source Repository to get master server installed.  DR master procedure is simaliar.  See Adminstration Operational Procedures | DMS Master Server Install as well.

Project sponsored and Code copyright by voyager-logo.png Internet Ltd 

This page is temporary while a proper site is built

DMS Features

  • Master can have DR Failover
  • IPv6 fully supported in back end and front end
  • IPv6 DNS RRs (AAAA)
  • Dynamic DNS configuration of Master server reduces need for reconfig and reload operations.
  • IPSECKEY HINFO CERT DS. DNSSEC handled by bind9 master
  • Auto DNSSEC via Bind9 dynamic DNS. Bind9 master server auto maintains zone DNSSEC operations records and signing. NSEC3 and NSEC supported. DNSSEC key management on Master server file system pending write of key management module. Key material directory is replicated via DR protocol (rsync) though. DMS is fully enabled to use DNSSEC for securing our core domains.
  • Apex resource record (SOA and NS) management across all zones - can be turned off per zone.
  • Auto reverse PTR generation
  • Customer control of their own automated reverse DNS. Individual PTR records, and complete reverse zones. Useful for business IPv6 and IPv4 blocks. Enables on site use of IP PABX, intranet and email for SMBs on XDSL/Fibre.
  • zone_tool command line administrative tool on master servers
  • IPSEC secured communications between each of DR master replicas and slaves
  • Modular design. For example, Racoon IPSEC can be replaced if needed.
  • Multiple Slave DNS server software implementations. NL Netlabs nsd3 can be used as a slave server once backend code is completed, and a simple configuration monitoring/HUP daemon implemented to run on each slave.
  • slave server/Server Groups (SG) support. Live migration of zones.
  • Private SGs for internal zones.
  • Retention of deleted zones in database for aged auto-deletion later.
  • Multiple Zone Instances per Zone. Roll forward and roll back changes. Again old ZIs aged for auto deletion above a threshold number.
  • Templates used for generating name server configuration includes - master, replicas and slaves.
  • Rsync to distribute name server configuration to servers.
  • Central distribution of name server configuration segments.
  • Hot standby master replica for DR purposes with manually controlled fail over. Includes automatic replica/slave server reconfiguration.
  • WSGI JSON RPC over HTTPS API for mulitple front ends
  • Security tags to control what front ends can see
  • Zone reference metadata to tag the zone with the owner/customer entity ID. Set by DMI when a zone is created. Tag out of table in DB via foreign key for easy reference renaming.
  • zone_tool has built in pager support and editor support via standard shell environment variables.
  • zone_tool has a configurable restricted shell mode for Help Desk use
  • RR Groups and RR comments supported in DB for use in text editor and in Web Admin DMI
  • zone_tool has colourised diff support to display changes between different ZIs for a zone
  • Vim can be used as zone tool editor, giving DNS colourised Zone file syntax high lighting.

Software Architecture Diagram

Only one of the DR replica pairs is shown below for clarity.
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

DMS System Architecture

Conceptual Network Layout

Conceptual Network Layout