resolvconf: support Debian's broken resolvconf #702
Conversation
This patch is untested, and won't really be easily testable until EggieCode/wireguard-ppa#20 is merged and uploaded. However, without testing, several observations struck me: - resolvconf doesn't need real interface names. A bogus name will work just fine. - Prefixing an arbitrary name with 'tun' moves it to the top-ish of the list. - Debian's resolvconf ignores arguments after the first, so we can still continue to supply the openresolv flags for implementations that support it. Thus, we give resolvconf tun.%i, and this should work good enough. There are a few limitations, however: - The DNS server is not _exclusive_, which means that if it doesn't reply in time, the resolver might choose to try other servers. This is a security feature limitation of Debian's resolvconf. Not our problem, perhaps? - This doesn't handle anything with the convoluted --enable-updates/ disable-updates logic, which may or may not be in use, in which case, who knows what to do. - Building on that last point, I'm still uncertain exactly how Ubuntu's use of dnsmasq interacts with --enable-updates/disable-updates and resolvconf in general. So, all and all this might be a bug-fix improvement over before, but still not perfect. Incremental baby steps. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Looks like EggieCode/wireguard-ppa#20 has been merged. |
Tested the on ubuntu zesty, works! |
Ultimately if the Debian resolvconf doesn't have a way to support an exclusive DNS server I think our hands are tied. We can document this and revisit when there are better options.
@zx2c4 Can you expand on what Overall seems like the least bad approach in a sea of bad choices. It's unfortunate that the one resolvconf package can't be used in a leak-resistant manner and the other can't be used reliably as a drop-in and has its own warts. :-/ I'm trying this PR in a few environments and will merge when those complete. Thanks! |
Worked as advertised on the 16.04 hosts I tested. |
@cpu wrote:
Well, there's this insanity:
That will make it exclusive and prevent anything from overwriting it. When you're done, you run @cpu wrote:
http://manpages.ubuntu.com/manpages/zesty/man8/resolvconf.8.html
One way of dealing with this would be to just call If you're especially paranoid, just recursively download the entire Ubuntu source package tree, untar everything, and grep for @cpu wrote:
Did you test this on a fresh Ubuntu desktop host? That might be the setup to evaluate, since it probably has the largest quantity of nausea. |
Ha! I just tested this on a desktop installation of Ubuntu 16.04 and it works perfectly. The tun prefix is a clever workaround that amounts to a huge improvement for Debian resolvconf users while still maintaining compatibility with other distros. It's hard not to smile while reading the "insane hack", but the good news is that I was unable to trigger any DNS leaks in my testing. We can probably avoid the dark incantations for now. Thank you! |
I wrote several months ago:
It is nearly Halloween and I am thus revisiting these dark incantations: https://lists.zx2c4.com/pipermail/wireguard/2017-October/001826.html Any opinons from the Stresiand-side of things? |
@zx2c4 Thanks for tagging us with the discussion (And for another foray into the darker regions of the Linux desktop ecosystem 🔮 👻 🔮 ) I find the hatchet somewhat unpleasant but that's not a point of disagreement with anyone. I don't have strong opinions whether or not it be used. It seems like if systemd/systemd#7202 were adopted the best bet for Streisand Ubuntu WireGuard clients would be to use I guess that's a longer way of saying that I'm going to punt to the maintainers of the Ubuntu/Debian packages here while I watch 7202. |
This patch is untested, and won't really be easily testable until
EggieCode/wireguard-ppa#20 is merged and uploaded. However, without
testing, several observations struck me:
just fine.
list.
continue to supply the openresolv flags for implementations that
support it.
Thus, we give resolvconf tun.%i, and this should work good enough. There
are a few limitations, however:
reply in time, the resolver might choose to try other servers. This is
a security feature limitation of Debian's resolvconf. Not our problem,
perhaps?
disable-updates logic, which may or may not be in use, in which case,
who knows what to do.
use of dnsmasq interacts with --enable-updates/disable-updates and
resolvconf in general.
So, all and all this might be a bug-fix improvement over before, but
still not perfect. Incremental baby steps.
Signed-off-by: Jason A. Donenfeld Jason@zx2c4.com