Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
confusing dns behavior #192
Using telepresence to proxy my local shell into a cluster was awesome, but it took me a few minutes to figure out that it was actually working. This was because when I typed 'host ', the output is confusing since it reports the correct ip, but the fully qualified hostname reflects the laptop's local configuration and hence references something that doesn't actually exist:
It sounds like, in the original report, there was a legitimate
So the behavior was likely that:
I would guess that if we rewrite the name in the response to the suffix-stripped version of the name,
I expect the thing to do is to modify
What do you think of
In other words, can we avoid all this suffix detection and stripping stuff entirely? Normal split-tunnel VPNs rely on the outside world returning NXDOMAIN to prompt a query into the VPN DNS; we might be able to get away with the reverse.
Possibly. I don't have any first-hand experience with split-tunnel VPNs. I'm not sure if there are other drawbacks that come with that (applications dealing with the NXDOMAIN poorly? But if getaddrinfo etc deal with it then it's probably fine).
Seems like a similarly easy experiment we could run, at least.
An entirely different solution would be to make a new mount namespace for the Telepresence context and bind-mount a better