DNS HTTP API written in Go
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
Alexander Karl a8faf9e4ca Merge pull request 'converted the single line command into a list' (#7) from docker-fmt into master 5 months ago
src fixed merge conflicts 11 months ago
.drone.yml add drone config 11 months ago
API v1.md Rename project: 'go-dns-api' => 'dynago' 1 year ago
Corefile Add reload setting to Corefile - default 10s 1 year ago
Dockerfile Rename project: 'go-dns-api' => 'dynago' 1 year ago
README.md Add build status from drone to readme 11 months ago
TODO.md Update TODO 2 years ago
docker-compose.yml converted the single line command into a list 11 months ago

README.md

GoDoc Go Report Card Build Status

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 GoDoc

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.