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 80205e1581 Make records toggleable via `disabled` attribute 3 months ago
.gitignore Moved attributes to `dns.` namespace 6 months ago
Dockerfile Bump module versions 4 months ago
README.md Update README.md 4 months ago
docker-compose.yml Moved attributes to `dns.` namespace 6 months ago
go.mod Add preliminary Prometheus metrics endpoint 4 months ago
go.sum Add preliminary Prometheus metrics endpoint 4 months ago
main.go Make records toggleable via `disabled` attribute 3 months ago
overnode.yml Moved attributes to `dns.` namespace 6 months ago
replica1.yml Moved attributes to `dns.` namespace 6 months ago
replica2.yml Moved attributes to `dns.` namespace 6 months 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.