DNS name resolution should not be done during configuration parsing.

[Vincent Wiemann]

Hi Matthias,

On 21.02.2019 08:59, Matthias Urlichs wrote:
> On 19.02.19 16:45, Vincent Wiemann wrote:
>> A kernel VPN module should not depend
>> on a user space daemon for doing regular checks or a daemon running at
>> all.
> 
> It doesn't. You only need userspace when the external IP address changes
> *and* the other side either doesn't initiate a link to us, or can no
> longer reach us due to firewall or NAT issues. This is already orders of
> magnitude better than OpenVPN.

There are setups where the "server" has a dynamic IP address and uses
DynDNS. The "client" sits behind a firewall. Thus the server can't
initiate a connection. When the IP address of the server changes, the
client loses connection.

> DNS is a complex protocol that's nontrivial to implement securely,
> DNSSEC even more so. You do not want that in the kernel. I'd wager a
> large chunk of money that neither does Linus Torvalds.

Please don't understand me wrong. I don't want to have DNS queries
running in kernel land.

>>     One could build up on
>>     https://www.kernel.org/doc/Documentation/networking/dns_resolver.txt ,
>>     but it's a lot of work and shouldn't be a goal before WireGuard becomes
>>     an upstream kernel module.
> 
>     I'm pretty sure that's the way to go long-term.
> 
> Umm … you might want to read that. It specifies upcalling to userspace.
> How is that better than running a WG daemon?

Not depending on a daemon, but only calling a userspace program when needed.

> We'd also lose flexibility. I might want to teach that WG daemon to get
> the new address from somewhere else, like a secure connection to a VPN
> server (given that DNS timeouts might be too long), or to use that
> netlink callback to trigger an alert or to activate a fallback connection.

You are right. Netlink notifications are a desirable feature.

I just think we should not depend on a daemon in this scenario.
We could also rewrite WireGuard to be in the userspace and implement a
"tunsock" in the kernel allowing us to use recvmmsg on a tun device. The
throughput would not be that much lower as the limiting factor of
userspace VPNs is often the number of context switches, but instead we
love to see WireGuard in the kernel, because high-bandwidth packet
processing should be done there. Likewise something as fundamental for a
VPN as DNS resolution should be called from where the VPN lives.
As far as I know no tunnel implementation exists in the kernel that
depends on a daemon running and as there is an existing API for DNS
resolution although it upcalls a userspace program (on which we agree
it's legit for DNS resolution) why don't we reuse and improve it?

Regards,

Vincent Wiemann