DnsNM allows you to centrally manage and deploy your Bind9 DNS zones and records across your DNS server infrastructure through a modern, responsive Web-UI. The agentless zero-dependency model allows for quick setup and no 3rd party software dependency on neither your management system nor your DNS servers. No webserver, database or middleware setup; everything is built-in.

DnsNodeManager deploys configuration files to remote servers running Bind9 through the SSH procotol (+SFTP/SCP). These configuration files hold the zone information only. They must be included through Bind9's main configuration (named.conf).

The application lets you enter all your zones, records and ACLs in the Web-UI and saves them in a local SQLite database file. Whenever you make changes to your DNS data, you will be notified about pending changes. Then you can deploy them to your DNS servers. DnsNM will upload the files to the DNS server, run some checks (named-checkconf, named-checkzone) and reload the Bind9 server.

The backend of DnsNodeManager is built with NodeJS/Express and a hand full of useful libraries and plugins. SQLite3 is used as the database engine. The frontend is built with React and the Material-UI kit. The PKG module compiles the shippable binary that lets you run the application without any dependencies.

This software aims to help IT Operations to manage DNS infrastucture in small to mid-size IT enviroments. Administrators need an understanding of Bind9 configurations to take advantage of DnsNodeManager. Thanks to the user roles system, simple DNS data management tasks can be delegated to even non-tech people with limited privilege.

At this time, the software is released free of charge for anyone to test and/or use. DnsNodeManager is the product of exploratory development which was (initially) started to solve a problem of the author. It is released with absolutely no warranty of merchantability or fitness for a particular purpose. In other words: use at your own risk.

Minimum specifications to run DnsNodeManager are as follows:

• 64-Bit Linux or Windows Operating System
• 1 Processor Core
• 256 MB Memory
• 500 MB of free disk space

DnsNodeManager is shipped as a binary application with a systemd service file template. You can download and unpack it to an arbitrary path of your system and run the executable straight away.

• Create a dedicated user that runs the app, i.e. 'dnsnm'
• Download the latest release from here.
• Unpack and move the files to a directory accessbile (RW) by the dnsmn user. Make sure proper file permissions are set.
• Optionally, create a systemd service using the included template.
• Start the application
• Login to the Web-UI with the default credentials: admin / dnsnmadmin1

• Download the latest release from here.
• Unpack and move the files to a directory of your choice.
• Optionally, create a system service for it using sc.exe or 3rd party alternatives.
• Start the application
• Login to the Web-UI with the default credentials: admin / dnsnmadmin1

The the 'config' folder, YAML files are used for the basic configuration of the DnsNodeManager application. Please note that the YAML file format is sensitive for indentation. Do NOT change the indentation!

You can configure the following files:

• web.yml
  Configures webserver settings, such as http/https capabilites, ports, IP bindings and certificates
• logging.yml
  Set logging options, and retention periods
• authentication.yml
  Configure local authentication and active directory connection and role mapping. Examples included.

* This applies to Linux environments with systemd only.
You can find a template for a systemd service unit in the 'systemd' folder of the Linux package. Copy that into an appropriate systemd folder, i.e. /etc/systemd/system/ and adjust the username and binary path to your needs. Run systemd daemon-reload to apply the file. Now you can manage DnsNM just like any other system service using systemctl start|stop|status commands.

To upgrade an exisiting installation to the latest release, please stop the application and take a full backup of your installation and data first. Then overwrite the existing installation with the new files from the latest release package. The database scheme will be updated on first startup of the new version if necessary.

To backup your DnsNM installation, it's sufficient to backup the data and config folder only. Restoring works in the same way. It's highly recommended to shut down the application before taking backups.

If you're encountering issues, unexpected behavior or crashes, it's a good idea to enable as much logging as possible to trace down the issue. In the logging.yml file you can set the logLevel up to 9 and set logSql to true. This will output as much status information as possible as well as any SQL statements.

In the DNS Servers panel, you can add two types of servers: Managed and Unmanaged servers. DnsNodeManager rolls out configuration files to managed servers only, which require you to set credentials for SSH login. Unmanaged servers are treated as externals. They may be operated by another person or entity.

The FQDN and IP Adress entered here are used for automatically created NS records and access lists for notiy and zone transfer. Make sure they are correct to avoid problems with notifications or failing zone transfers.

Nameserver Groups work as templates for DNS zones. Each zone must be associated with a nameserver group, which defines the NS records and the zone transfer data flow. You can add a mix of both managed and unmanaged servers to them. Servers configured as 'hidden' will get no NS record in associated zones to support "Hidden Primary" concepts. You may also set an individual transfer source for each server, defaulting to the groups primary master.

Forwarder Groups are used for forwarding-zones only. They're reusable lists of IP adresses to be associated with zones configured for forwarding only.

Access Lists are (at this time) reusable lists of IP addresses that define the allowed sources for dynamic zone updates.

DNS Views (or Split-DNS) let you host the same zone with different data and respond to queries with either zone, based on conditions, such as source IP or interface. Note that the DNS Views implementation in DnsNodeManager is very basic and requires you to write the conditions for each View as a code-snippet in bind config format. Please also keep in mind that when using DNS Views you must not have any zone (including Bind's default zones) outside of a view in your Bind configuartion. It's recommended to move all zones into DnsNodeManager or create seperate views for them in your Bind configuration.

Views also let you configure the zone's SOA defaults and the default TTL. If you don't use views, you can still use the default view for this purpose. If only the default view exists, DnsNodeManager won't wrap the configuration in a view {} statement and ignore any view configuration except the zone defaults.

The zone manager lets you create, edit and delete authorative zones and forwarding zones. Each zone needs to be associated with a Nameserver Group to define the NS Records, master/slave relationships and so on. The SOA and TTL are inherited from the view's defaults and can be edited after zone creation. Note that there's no UI helper for reverse zones yet, so you'll have to write reverse zones in the *.in-addr.arpa format.

You can import zones and records from both CSV or Bind9 Config sources.

The User Management panel lets you create and manage local users only. It has a role and permission matrix to help you identify the best role for your users.

Users can be authenticated through MS Active Directory through LDAP(-S). The server configuration, credentials and user mapping is done through the auth.yml configuration file. The default file has declarative examples that you can derive from.