dynago

As the name suggests, a HTTP based REST API to create, read, update and delete resource records of domains, generating RFC 1035 conform files.

Backends

Currently, there are two backends to use: memory and sql.

memory Backend

More precise, the in-memory backend. Stores the domains and their records in memory and forgets them upon shutdown. Most likely, you want this only for debugging purposes. The memory backend has no configurable settings.

sql Backend

The SQL-based backend. Stores the domains and records in tables. You want this backend for production use, as it allows you to restart the executable as often as you like. Also, thanks to basing on the database, you can scale the software up as you desire. Configurable settings are:

Flag	Default	Description
dbUser	“root”	The database server user to use
dbPass	"”	The database server user password to use
dbHost	“sql”	The database server to use
dbDatabase	“db”	The database to use

DIY Backend

To write your own backend, implement the storage interface, found in src/storage/storage.go, then switch the backend in the main function of src/main.go. Have a look at memory and sql backends for reference.

Usage

Have a look at the docker-compose file, which covers the typical use case:

• dynago running on port 80/tcp, writing Zonefiles to a persistent volume
• a mysql container storing the database on a persistent volume, linked to the dynago container
• a coredns container hosting the Zonefiles with a refresh time of 10 seconds, exposing 53/tcp and 53/udp

You may want to install a reverse HTTP proxy in front of the dynago container, e.g. caddy or traefik, to encrypt your traffic and add a layer of authentication.

If used in a production scenario, you may want to alter the Corefile to allow zone transfers, for example with transfer to 1.2.3.4, and spin up another DNS server pulling zones from the master.