|Alexander Karl a8faf9e4ca||1 month ago|
|src||8 months ago|
|.drone.yml||8 months ago|
|API v1.md||1 year ago|
|Corefile||1 year ago|
|Dockerfile||1 year ago|
|README.md||8 months ago|
|TODO.md||2 years ago|
|docker-compose.yml||8 months ago|
As the name suggests, a HTTP based REST API to create, read, update and delete resource records of domains, generating RFC 1035 conform files.
Currently, there are two backends to use:
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.
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:
||“root”||The database server user to use|
||"”||The database server user password to use|
||“sql”||The database server to use|
||“db”||The database to use|
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
sql backends for reference.
Have a look at the
docker-compose file, which covers the typical use case:
dynagorunning on port
80/tcp, writing Zonefiles to a persistent volume
mysqlcontainer storing the database on a persistent volume, linked to the
corednscontainer hosting the Zonefiles with a refresh time of 10 seconds, exposing
You may want to install a reverse HTTP proxy in front of the
dynago container, e.g.
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 220.127.116.11, and spin up another DNS server pulling zones from the master.