|Lauri Võsandi 80205e1581||3 months ago|
|.gitignore||6 months ago|
|Dockerfile||4 months ago|
|README.md||4 months ago|
|docker-compose.yml||6 months ago|
|go.mod||4 months ago|
|go.sum||4 months ago|
|main.go||3 months ago|
|overnode.yml||6 months ago|
|replica1.yml||6 months ago|
|replica2.yml||6 months ago|
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.
Queries hostnames are looked up from
in collection specified by
IP addresses listed in
ips attribute are returned, IPv6 is handled correctly.
MongoDB target is read from
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.
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
etcd and data duplication if records are already primarily stored in