30 lines
1.2 KiB
Markdown
30 lines
1.2 KiB
Markdown
|
---
|
||
|
|
type: task
|
||
|
|
---
|
||
|
|
|
||
|
|
# Shared DNS Server
|
||
|
|
|
||
|
|
Consider a shared dnsmasq (or maybe embedded CoreDNS) instance across all the
|
||
|
|
daemon's networks.
|
||
|
|
|
||
|
|
This would have a few benefits:
|
||
|
|
- Less processes, less problems
|
||
|
|
- Less configuration for the user in the case of more than one network.
|
||
|
|
- Can listen on 127.0.0.x:53, rather than on the nebula address. This
|
||
|
|
allows DNS to come up before nebula, which is helpful when nebula depends
|
||
|
|
on DNS.
|
||
|
|
|
||
|
|
This would break an existing use-case where a host is using the DNS server of a
|
||
|
|
remote host, as the DNS server would no longer be available on the nebula
|
||
|
|
address. The primary need for this at the moment is mobile, where there is not a
|
||
|
|
real app yet. Once there is a real app this won't be necessary.
|
||
|
|
|
||
|
|
In the meantime this could be worked-around by allowing the daemon to configure
|
||
|
|
which IP/ports the server listens on (which it would want to do anyway, I
|
||
|
|
imagine). The user can configure the DNS server to listen on the nebula address
|
||
|
|
manually.
|
||
|
|
|
||
|
|
This solution has the downside of potentially allowing cross-network DNS
|
||
|
|
queries, which might be a big enough security issue to be worth working around
|
||
|
|
even in the initial implementation of this.
|