allowDNS doesn't work on Linux: `LinuxEthernetTap::setDns` doesn't do anything

[jfly]

I'm trying to enable allowDNS on Ubuntu, and it's not doing anything. No changes to /etc/resolv.conf, nothing.

I dug into the code, and it looks like this is because LinuxEthernetTap::setDns simply is a no-op:

ZeroTierOne/osdep/LinuxEthernetTap.hpp

Line 61 in 185a3a2

virtual void setDns(const char *domain, const std::vector<InetAddress> &servers) {}

It found some threads online talking about this:

• https://www.reddit.com/r/zerotier/comments/lmei2w/how_do_you_set_up_the_new_dns_feature/
• https://discuss.zerotier.com/t/dns-servers-ignored-on-ubuntu/25231

But I couldn't find any official docs talking about this, so I thought I'd ask here:

1. Is this feature WIP, or intentionally not supported on Linux?
   • I understand that there are lots of ways to do networking and DNS on Linux. Supporting systemd-resolved would work well for a lot of Linux users (myself include). See How to Implement this in Your VPN Software > If managing a corporate VPN for how to configure dns for a specific tld, which would work well with ZT's model.
2. Would you accept a PR adding some logging to LinuxEthernetTap::setDns with some explanation about the state of this? The current behavior is very confusing.

[laduke]

Thanks for writing. It's definitely not implemented. If you didn't see any notes about it, we need to improve the docs.
There are so many ways to do dns on linux, we didn't implement any of them. There's a systemd based tool here
https://github.com/zerotier/zerotier-systemd-manager

[jfly]

Thanks for the pointer to https://github.com/zerotier/zerotier-systemd-manager, I'll check it out.

I do believe a warning would be a godsend for future users. How does #2493 look?

[jmariondev]

I've put up a PR ( #2575 ) with an implementation to call resolvectl as necessary, though I've only tested this on Fedora.

This required a Polkit rule to allow the zerotier-one user to manipulate systemd-resolved but this may need to be generalized more to work on a wider range of systems.