For the record - going to do a debugging session with davidsbond tomorrow to examine the DNS stack on that machine and try to figure out where we’re going wrong.
2 Likes
We found the issue(s). It’s a combo of our DNS manager picking the wrong configuration mechanism (“overwrite /etc/resolv.conf” instead of “configure via NetworkManager”), and the way we overwrite /etc/resolv.conf (using a symlink to point at a tailscale config) conflicting with Ubuntu Snap’s sandboxing mechanisms.
The snap bug is at DNS Support breaks resolving for SNAP on Ubuntu · Issue #683 · tailscale/tailscale · GitHub
Unfortunately, there’s no very quick fix or workaround for this, other than “stop using snaps”, which isn’t an acceptable answer for us to give. I’m working on revamping our DNS functionality in Tailscale 1.8, and I’ll make sure this scenario is handled correctly there. Look out for it in upcoming unstable builds in the meantime.
Thanks @davidsbond for taking the time to video-chat! Going through linux configuration interactively is a huge help for tracking down this kind of issue.
1 Like
Thanks @danderson, was a good little session. There was the one other issue we found where stopping the tailscale service using systemctl didn’t clean up the syslinked resolv.conf. Not sure if that’s tracked also.
I don’t have an issue waiting for tailscale 1.8, so will await the update!
I think that’ll go away when I revamp how the resolv.conf overwriter works. It’s currently not being cleaned up because tailscaled wants to be sure that it owns the config it’s trying to clean up, and the test for that right now is “is resolv.conf a symlink to my file?”
Since I’m going to replace that with a different test that doesn’t rely on symlinks for different reasons, the cleanup will update to match.