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.