tunnel+conf+ui: periodic update of endpoint ip

[tripplet]

Hi,
This PR implements a an new config option "UpdateEndpointIP=0-65535" to periodically update endpoint IPs for dynamic DNS scenarios.

[unquietwiki]

@tripplet @zx2c4 My email client was being stubborn (doesn't send plain text emails), and I think my problem is related to this patch. This patch is supposed to periodically update endpoint resolution as part of dynamic DNS behavior. I saw some comment on r/wireguard mentioning what they and my own systems are both encountering; that specifying a hostname with both AAAA & A DNS records, will never use the AAAA record. I did find some 4 year-old article on disabling IPv6 DNS resolution back in Go 1.8/1.9; but WG is using Go 1.17 now. I feel like the fix being done here, could be extended to solve this other problem as well; I did find some more up-to-date examples, that were also IPv6-friendly.

Thank you for hearing me out on this.

[unquietwiki]

@tripplet it looks like from the code changes here, you got my message. Thanks!!!

[z0mb1e-kgd]

I suppose it would be reasonable to add an option to perform this once the last KeepAlive timeout reaches a certain threshold. Great PR nevertheless, the subject option is totally necessary.

[guillaume-uH57J9]

Thanks for submitting the patch.
Contributors, please consider this improvement !
Relying on the existing endpoint host configuration but periodically querying DNS would be a minimal addition.
I was actually surprised then I first read that wireguard only query endpoint IP once, when bringing up the interface, not more regularly.

Note DNS answers include a TTL value that provide a hint for caching result.
An idea to further improve would be to use this TTL to dynamically select a endpoint IP update period, rather than hard-coding it within the configuration.
This could be exposed as UpdateEndpointIP=auto (using TTL) or UpdateEndpointIP=1-86400 (using manually configured period).
Anyway, a manually configurable period would already be great.

There are a few projects built on top of Wireguard that provide dynamic endpoint capabilities, via mDNS or a signalling server.
But all the projects I've seen so far provide (too) many features and are too complex for my taste.
So it would be great to see a basic dynamic endpoint capability in wireguard itself.

[beposec]

Any idea why this was never merged?

[tripplet]

No idea I posted it to the mailing list but never got a response.
I have been using my version since then, still works like a charm.
If anyone wants to use it you can simply

1. Install the normal wireguard
2. Quit the GUI program in the systray
3. Copy the custom build executable somewhere
4. Start the custom executable, from then on this executable is started automatically instead of the default one.
5. If you ever start the build in GUI the default executable again becomes the default.

You can use the executable I build here:
https://github.com/tripplet/wireguard-windows/releases/tag/v0.5.3
or compile it your self which is awesomely by wireguard.
Just clone the branch and run the build.bat which will do the rest automatically.

There is one downside I discovered:
Due to the way the config is parsed by GUI program it will reject the UpdateEndpointIP setting and display the whole tunnel config as invalid not allowing you access to the rest of the data of this tunnel config and making the tunnel unusable.

To get out of this state use the custom GUI, remove the UpdateEndpointIP setting and save the tunnel config.
Now you are again able to use the default wireguard program.

[Johanneslueke]

This should really be merged and made available to everyone officially.

[weedy]

Note DNS answers include a TTL value that provide a hint for caching result.
An idea to further improve would be to use this TTL to dynamically select a endpoint IP update period, rather than hard-coding it within the configuration.
This could be exposed as UpdateEndpointIP=auto (using TTL) or UpdateEndpointIP=1-86400 (using manually configured period).
Anyway, a manually configurable period would already be great.

If we are going to start bike-shedding.
After XYZ seconds of failed handshakes, if peer is a domain not an IP re-resolve the domain.

Persistent keepalive should keep you going most of the time. But if both peers change IPs yeah the client should try harder.