Mongo backed DNS server
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.
 
 
Lauri Võsandi 71fd0879c5 Add Drone config 10 months ago
.drone.yml Add Drone config 10 months ago
.gitignore Moved attributes to `dns.` namespace 2 years ago
Dockerfile Bump module versions 2 years ago
README.md Update README.md 2 years ago
docker-compose.yml Moved attributes to `dns.` namespace 2 years ago
go.mod Add preliminary Prometheus metrics endpoint 1 year ago
go.sum Add preliminary Prometheus metrics endpoint 1 year ago
main.go Make records toggleable via `disabled` attribute 1 year ago
overnode.yml Moved attributes to `dns.` namespace 2 years ago
replica1.yml Moved attributes to `dns.` namespace 2 years ago
replica2.yml Moved attributes to `dns.` namespace 2 years ago

README.md

Background

GoreDNS is MongoDB backed authoritative DNS server. GoreDNS does not have notion of zones as such. Whatever is found in MongoDB is returned.

We evaluated Bind, CoreDNS and other existing tooling for our usecases described below, but none of the existing tools covered the needs on a satisfactory level.

Name resolution mechanism

Queries hostnames are looked up from dns.fqdn and dns.san attributes in collection specified by GOREDNS_COLLECTION. IP addresses listed in ips attribute are returned, IPv6 is handled correctly. MongoDB target is read from MONGO_URI.

Usecases

GoreDNS is used in Pinecrypt Gateway to resolve IP addresses of the VPN clients and also to return IP addresses of the gateway itself. In the upper level domain subdomain is delegated to GoreDNS. Each VPN client and gateway replica gets unique hostname assigned under that subdomain. Whenever VPN client connects, it's internal IP address is recorded in MongoDB using the OpenVPN and Strongswan helpers. GoreDNS then starts resolving those DNS records.

GoreDNS is used at K-SPACE MTÜ to resolve internal IP addresses assigned by DHCP in a highly available manner. MongoDB is run on 3-node replica set and there are two instances of GoreDNS serving the records.

Why not ...?

Bind configuration is complex and error prone. DHCP added records must be submitted to primary instance. Configuration for secondary servers differs from the primary one. Whenever primary instance is down DHCP records can't be updated. Zone files updated due to DHCP or Let's Encrypt DNS validation using the TSIG mechanism are mangled and reformatted.

CoreDNS with etcd plugin nearly covers the usecases here, however issue 3861 makes it useless for any general purpose DNS resolution. Additionally it introduces dependency on etcd and data duplication if records are already primarily stored in MongoDB.