DNS management software is computer software that controls Domain Name System (DNS) server clusters. DNS data is typically deployed on multiple physical servers. The main purposes of DNS management software are:

to reduce human error when editing complex and repetitive DNS data
to reduce the effort required to edit DNS data
to validate DNS data before it is published to the DNS servers
to automate the distribution of DNS data

Background

In 1995, there were only 70,000 domains in existence.^[1] The way to register them was by email^[2] and the way to publish them was BIND. By mid-1997, the domain count was 1.3 million.^[3] As the number of domains and internet hosts skyrocketed, so too did the quantity of DNS data and the time required to manage it. Sysadmins responded by writing Perl or Shell scripts that helped automate DNS changes. These scripts were mostly in-house tools. The closest thing to widely available DNS management software was the BIND module in webmin, which provided web tools for editing BIND zone files.

During the late 1990s, the sheer quantity of DNS data was overwhelming the tools available to manage it. The cost of managing the data instigated the birth of DNS management software. The costs can best be explained by illustration. In 1998, three of the largest web hosting companies (HostPro, Interland, and Vservers) each hosted about 100,000 DNS zones. DNS changes were made by telnetting to a BIND master and editing zone files with a text editor. A staff of several DNS admins performed this task all day, every day. Their changes would only take effect after a BIND reload. Because disks were slow, it took several hours for BIND to do a full reload. If a DNS admin made a typo in a zone file, BIND would fail to parse that file and die. Often after hours of processing. Whoever noticed BIND wasn't running would have to read the logs, find the zone file with the error, manually review the file, fix the error, and then try starting BIND back up. Once up, the changes could propagate to the DNS slaves via zone transfers. Changes often took more than 24 hours to fully propagate.

DNS and databases

While struggling with the challenges of editing zone files, more than a few sysadmins noticed that SQL is a terrific place to store DNS data. By moving the Single Source of Truth from text files into SQL, DNS data could be validated and constrained before acceptance into the database. Export scripts could convert the SQL to zone files. Rsync could replace named-xfer for distribution, increasing security and reducing propagation time. Among large hosting providers, it became fashionable to store DNS data in SQL and build a custom interface for managing it. mysqlBind is one such DNS manager. It provides a web interface for data input and exports the data to BIND zone files.

In 2000, Daniel J Bernstein released Djbdns. One of the novel features was that tinydns, the included authoritative DNS server, served DNS directly from a CDB database. The cdb had to be compiled from a plain text file whose format was designed to be edited by scripts. Tinydns quickly became the second most popular DNS server and a number of DNS managers were released for it, including: VegaDNS, SuaveDNS, and NicTool.

In 2005, PowerDNS was released. One of its features was the ability to serve DNS data directly out of the SQL database, bypassing the export step entirely. PowerDNS also spawned a number of DNS managers that provide web interfaces to its SQL data store.

DDNS

Using the RFC2136 DDNS update protocol, it is possible to change DNS zones without accessing the zone files. Management tools known to work that way are Admin4 and NicTool via its nsupdate^[4] export mechanism.

Service Providers

DNS service providers often deploy different types of DNS servers in their networks. In addition, different answers may be provided to DNS clients based on the clients' geographic location, as determined by their IP address (GeoIP). The most practical way to manage such critical Internet infrastructure has been to rely on databases and complex DNS management software to ensure homogeneity and avoid single points of deployment errors.

DNS management software comparison

Feature	NicTool	VegaDNS	mysqlBind	Webmin	Admin4	Microsoft DNS	SuaveDNS	Xname	dnsadmin	fmDNS	Micetro
Language	Perl & JS	PHP	C	Perl	Python	C	PHP & Perl	PHP & Perl	C	PHP & JS	C++
Database	MySQL	MySQL	MySQL	flat files	-	flat files or Active Directory	MySQL	MySQL	MySQL	MySQL	SQLite, MS SQL, PostgreSQL
Delegated Permissions	Yes	3 groups	Yes	No	No	No	No	No	No	Yes	Yes
Open Source	Yes^[5]	Yes	Yes	Yes	Yes	No	No	No	No	Yes	No
Latest Release	2017	2016	2016	2017	2016	2012	2003	2005	2003	2021	2021

DNS Server Support

Name	NicTool	EfficientIP	VegaDNS	mysqlBind	Webmin	Admin4	Microsoft DNS Manager	fmDNS	Infoblox
BIND	Yes	Yes	No	Yes	Yes	Yes	No	Yes	No
tinydns	Yes	No	Yes	No	No	No	No	No	No
PowerDNS	Yes	No	No	No	No	?	No	No	No
MaraDNS	Yes	No	No	No	No	?	No	No	No
NSD	Yes	Yes	No	No	No	?	No	No	No
Microsoft DNS Server	No	Yes	No	No	No	No	Yes	No	No
Infoblox	No	No	No	No	No	No	No	No	Yes
EfficientIP	No	Yes	No	No	No	No	Yes	No	Yes

BIND zone file format

The BIND zone file format is a widely used industry standard documented in RFC 1035. Several other DNS servers, including PowerDNS, NSD, Knot DNS, Microsoft DNS Server, and Micetro by MEn&Mice have the ability to read BIND zone files and serve from them.

Resource Record Types Supported

Name	NicTool	VegaDNS	mysqlBind	Webmin	Admin4	Microsoft DNS Manager	ProBIND	fmDNS	Micetro
A,NS,SOA,PTR	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
MX,TXT,CNAME	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
KEY	No	No	No	Yes	Yes	Yes	No	Yes	Yes
AAAA	Yes	Yes	Yes	Yes	Yes	Yes	No	Yes	Yes
LOC	Yes	No	No	Yes	Yes	No	No	No	Yes
SRV	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
NAPTR	Yes	No	Yes	No	Yes	Yes	No	Yes	Yes
SSHFP	Yes	No	No	No	Yes	No	No	Yes	Yes
RRSIG	Yes	No	No	No	Yes	Yes	No	No	Yes
NSEC	Yes	No	No	No	Yes	Yes	No	No	Yes
DNSKEY	Yes	No	No	No	Yes	Yes	No	Yes	Yes
DS	Yes	No	No	No	Yes	Yes	No	Yes	Yes
NSEC3	Yes	No	No	No	Yes	Yes	No	No	Yes
NSEC3PARAM	Yes	No	No	No	Yes	Yes	No	No	Yes
IPSECKEY	Yes	No	No	?	Yes	?	?	No	Yes
DNAME	Yes	No	No	?	Yes	Yes	?	Yes	Yes
SPF	Yes	No	No	Yes	Yes	No	No	Yes	Yes

Microsoft DNS manager supports DNSSEC from Windows Server 2012 onwards. Some of the DNSSEC records can not be directly added but are generated during zone signing and managed as such.

DNS software homogeneity

Primary reasons for DNS providers (especially root operators) to use different DNS servers is code diversity and application performance. Code diversity makes it less likely that a performance or security bug in one DNS server could be exploited to inflict a Denial of Service attack upon an organization. It is for this reason that NSD and Knot DNS are frequently used by root and TLD operators. DNS management software can greatly simplify publishing DNS data to varying DNS servers.^{[citation needed]}