DNS name resolution should not be done during configuration parsing.

DNS name resolution should not be done during configuration parsing.

[Eryk Wieliczko]

[-- Attachment #1.1: Type: text/plain, Size: 653 bytes --]

Hello everyone!

If you use a DNS address as an endpoint and there is no internet connection, WireGuard will hang for two minutes and then exit with error.

IMO the expected behavior should be the same as in OpenVPN:
WireGuard starts immediately and patiently tries to resolve the DNS until it succeeds.

Thus, WireGuard should resolve the DNS just before connecting to the server. And just keep trying and trying without any timeouts.

I'd like to install WireGuard on technician's computers and there is no guarantee that they will start phone tethering within 2 minutes of starting their machine. OpenVPN would pass this scenario.

What do you think?

[-- Attachment #1.2: Type: text/html, Size: 818 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: DNS name resolution should not be done during configuration parsing.

[David Kerr]

[-- Attachment #1.1: Type: text/plain, Size: 2044 bytes --]

Erik, see here for a proposed fix.  No response from the WireGuard team
yet.

https://lists.zx2c4.com/pipermail/wireguard/2019-January/003842.html

Recently I had a power outage and both my gateway and cable modem went
offline. On power recovery both devices start up, but the gateway completes
startup before the cable modem completes its protocol negotiations, so
initially the external network (eth0) is not functional.  That comes online
say one minute later and all is well.

Except that all is not well.  Wireguard failed to start up because I have
Endpoint=<a URL> instead of a IP address.  And because external interface
is not live yet, DNS lookup fails and Wireguard does not gracefully handle
it.  This is really important because Wireguard may be my only way into my
local network.

As work-around I replaced the URL with the IP address... but that is not a
long term solution if the endpoint is not a static IP address.

Wireguard needs to handle the situation where external network may not have
stabilized at the time it starts up.  The above link proposed a fix.

David

On Sat, Feb 16, 2019 at 8:35 PM Eryk Wieliczko <eryk@wieliczko.ninja> wrote:

> Hello everyone!
>
> If you use a DNS address as an endpoint and there is no internet
> connection, WireGuard will hang for two minutes and then exit with error.
>
> IMO the expected behavior should be the same as in OpenVPN:
> WireGuard starts immediately and patiently tries to resolve the DNS until
> it succeeds.
>
> Thus, WireGuard should resolve the DNS just before connecting to the
> server. And just keep trying and trying without any timeouts.
>
> I'd like to install WireGuard on technician's computers and there is no
> guarantee that they will start phone tethering within 2 minutes of starting
> their machine. OpenVPN would pass this scenario.
>
> What do you think?
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>
-- 
David Kerr Sent from Gmail Mobile

[-- Attachment #1.2: Type: text/html, Size: 3785 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: DNS name resolution should not be done during configuration parsing.

[Jeffrey Walton]

On Sat, Feb 16, 2019 at 10:35 PM David Kerr <david@kerr.net> wrote:
>
> Erik, see here for a proposed fix.  No response from the WireGuard team yet.
>
> https://lists.zx2c4.com/pipermail/wireguard/2019-January/003842.html
>
> Recently I had a power outage and both my gateway and cable modem went offline. On power recovery both devices start up, but the gateway completes startup before the cable modem completes its protocol negotiations, so initially the external network (eth0) is not functional.  That comes online say one minute later and all is well.
>
> Except that all is not well.  Wireguard failed to start up because I have Endpoint=<a URL> instead of a IP address.  And because external interface is not live yet, DNS lookup fails and Wireguard does not gracefully handle it.  This is really important because Wireguard may be my only way into my local network.
>
> As work-around I replaced the URL with the IP address... but that is not a long term solution if the endpoint is not a static IP address.
>
> Wireguard needs to handle the situation where external network may not have stabilized at the time it starts up.  The above link proposed a fix.

Forgive my ignorance... Should init just retry the service start?
Something like this (from Systemd):

    [Unit]
    StartLimitInterval=360
    StartLimitBurst=5

The statements above say to retry 5 times within 360 seconds.

Jeff
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: DNS name resolution should not be done during configuration parsing.

[Eryk Wieliczko]

Configuring such things is an additional unnecessary step. OpenVPN/tinc don't require such hacks. Once you start OpenVPN, it's gonna work until the server dies of old age. :-)

This is a problem that's gonna bite some users in the least opportune moment, just like it bit David. And it's a reason why I'm currently using tinc.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, February 17, 2019 5:08 AM, Jeffrey Walton <noloader@gmail.com> wrote:

> On Sat, Feb 16, 2019 at 10:35 PM David Kerr david@kerr.net wrote:
>
> > Erik, see here for a proposed fix. No response from the WireGuard team yet.
> > https://lists.zx2c4.com/pipermail/wireguard/2019-January/003842.html
> > Recently I had a power outage and both my gateway and cable modem went offline. On power recovery both devices start up, but the gateway completes startup before the cable modem completes its protocol negotiations, so initially the external network (eth0) is not functional. That comes online say one minute later and all is well.
> > Except that all is not well. Wireguard failed to start up because I have Endpoint=<a URL> instead of a IP address. And because external interface is not live yet, DNS lookup fails and Wireguard does not gracefully handle it. This is really important because Wireguard may be my only way into my local network.
> > As work-around I replaced the URL with the IP address... but that is not a long term solution if the endpoint is not a static IP address.
> > Wireguard needs to handle the situation where external network may not have stabilized at the time it starts up. The above link proposed a fix.
>
> Forgive my ignorance... Should init just retry the service start?
> Something like this (from Systemd):
>
> [Unit]
> StartLimitInterval=360
> StartLimitBurst=5
>
> The statements above say to retry 5 times within 360 seconds.
>
> Jeff


_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: DNS name resolution should not be done during configuration parsing.

[Jeffrey Walton]

On Sun, Feb 17, 2019 at 7:40 AM Eryk Wieliczko <eryk@wieliczko.ninja> wrote:
> > Forgive my ignorance... Should init just retry the service start?
> > Something like this (from Systemd):
> >
> > [Unit]
> > StartLimitInterval=360
> > StartLimitBurst=5
> >
> > The statements above say to retry 5 times within 360 seconds.
> Configuring such things is an additional unnecessary step. OpenVPN/tinc don't require such hacks. Once you start OpenVPN, it's gonna work until the server dies of old age. :-)

I have to admit I don't quite understand calling it "unnecessary".

There seems to be two use cases (maybe more?): manual start and auto
start. The auto start case is usually handled by init scripts. Init
scripts usually retry.

I'm not throwing stones, but I have to ask... Why not use the tools
available instead of adding hacks on top of hacks? The hacks likely
make the code brittle. By the time Wiregaurd gets to supporting AIX,
Dragonfly, Hurd, Solaris and other Unix personalities no one will want
to touch it.

Jeff
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: DNS name resolution should not be done during configuration parsing.

[Eryk Wieliczko]

You are right, I got confused.
I thought that this would be something that _the user_ would have to set up. Please forgive my ignorance. :-)

Since these scripts are installed by WG and not by a user, this solution would be fine.




Isn't it the case that currently WG is performing DNS both during configuration AND during connection setup? I see that there is _getaddrinfo_ in ipc.c...
Maybe just removing all getaddrinfo from config.c would be enough to fix this?

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, February 17, 2019 2:07 PM, Jeffrey Walton <noloader@gmail.com> wrote:

> On Sun, Feb 17, 2019 at 7:40 AM Eryk Wieliczko eryk@wieliczko.ninja wrote:
>
> > > Forgive my ignorance... Should init just retry the service start?
> > > Something like this (from Systemd):
> > > [Unit]
> > > StartLimitInterval=360
> > > StartLimitBurst=5
> > > The statements above say to retry 5 times within 360 seconds.
> > > Configuring such things is an additional unnecessary step. OpenVPN/tinc don't require such hacks. Once you start OpenVPN, it's gonna work until the server dies of old age. :-)
>
> I have to admit I don't quite understand calling it "unnecessary".
>
> There seems to be two use cases (maybe more?): manual start and auto
> start. The auto start case is usually handled by init scripts. Init
> scripts usually retry.
>
> I'm not throwing stones, but I have to ask... Why not use the tools
> available instead of adding hacks on top of hacks? The hacks likely
> make the code brittle. By the time Wiregaurd gets to supporting AIX,
> Dragonfly, Hurd, Solaris and other Unix personalities no one will want
> to touch it.
>
> Jeff


_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: DNS name resolution should not be done during configuration parsing.

[zrm]

On 2/16/19 23:08, Jeffrey Walton wrote:
> On Sat, Feb 16, 2019 at 10:35 PM David Kerr <david@kerr.net> wrote:
>>
>> Erik, see here for a proposed fix.  No response from the WireGuard team yet.
>>
>> https://lists.zx2c4.com/pipermail/wireguard/2019-January/003842.html
>>
>> Recently I had a power outage and both my gateway and cable modem went offline. On power recovery both devices start up, but the gateway completes startup before the cable modem completes its protocol negotiations, so initially the external network (eth0) is not functional.  That comes online say one minute later and all is well.
>>
>> Except that all is not well.  Wireguard failed to start up because I have Endpoint=<a URL> instead of a IP address.  And because external interface is not live yet, DNS lookup fails and Wireguard does not gracefully handle it.  This is really important because Wireguard may be my only way into my local network.
>>
>> As work-around I replaced the URL with the IP address... but that is not a long term solution if the endpoint is not a static IP address.
>>
>> Wireguard needs to handle the situation where external network may not have stabilized at the time it starts up.  The above link proposed a fix.
> 
> Forgive my ignorance... Should init just retry the service start?
> Something like this (from Systemd):
> 
>      [Unit]
>      StartLimitInterval=360
>      StartLimitBurst=5
> 
> The statements above say to retry 5 times within 360 seconds.
> 
> Jeff

The issue is that the service shouldn't terminate over failure to 
resolve an individual endpoint.

Suppose name resolution fails because of a DNS failure rather than a 
network failure. If there are other endpoints configured by address that 
are still reachable, should we give up entirely and not even connect the 
ones that we can? What if one of the endpoints configured by IP address 
is the DNS server?

Pushing this onto init would imply something like separate unit files 
per endpoint, which may complicate things more than simplify them.

It seems like the conflict is that on the one hand, we want to resolve 
the name at connection time rather than configuration time, but on the 
other hand we don't want a DNS resolver in the kernel. How hard would it 
be to call out to a trivial userspace DNS client? This shouldn't be very 
performance sensitive, the results could be cached for the TTL which is 
typically hours or at least minutes.
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: DNS name resolution should not be done during configuration parsing.

[Matthias Urlichs]

On 19.02.19 04:01, zrm wrote:
> How hard would it be to call out to a trivial userspace DNS client?

We don't even need call-outs. We already have a netlink interface which
a userspace client can use to monitor WG. Teach that client to
re-resolve the name and to update the peer.

-- 
-- Matthias Urlichs

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: DNS name resolution should not be done during configuration parsing.

[Lonnie Abelbeck]

> On Feb 19, 2019, at 1:22 AM, Matthias Urlichs <matthias@urlichs.de> wrote:
> 
> We don't even need call-outs. We already have a netlink interface which
> a userspace client can use to monitor WG. Teach that client to
> re-resolve the name and to update the peer.
> -- 
> -- Matthias Urlichs

Agreed.  For example Jason's "reresolve-dns.sh" script. [1]

The missing piece is to keep "wg setconf" (et al.) from failing given a DNS failure on any peer.

Per this trivial patch.
https://raw.githubusercontent.com/astlinux-project/astlinux/master/package/wireguard/wireguard-0001-ignore-endpoint-dns-failure.patch

Peers without DNS endpoints (or successful DNS) would be allowed to start promptly as expected, and any failed DNS endpoints would be filled in later via a userspace WG monitor (ex. reresolve-dns.sh).

Lonnie

[1] https://git.zx2c4.com/WireGuard/tree/contrib/examples/reresolve-dns

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: DNS name resolution should not be done during configuration parsing.

[Vincent Wiemann]

Hi Matthias,

On 19.02.2019 08:22, Matthias Urlichs wrote:
> We don't even need call-outs. We already have a netlink interface which
> a userspace client can use to monitor WG. Teach that client to
> re-resolve the name and to update the peer.
>

that's not a good design choice. A kernel VPN module should not depend
on a user space daemon for doing regular checks or a daemon running at
all. We want to be able to set it up using e.g. systemd-networkd and
don't have to care about it afterwards. Thus WireGuard should be able to
resolve the hostnames.

On 17.02.2019 19:26, Vincent Wiemann wrote:
> One could build up on
> https://www.kernel.org/doc/Documentation/networking/dns_resolver.txt ,
> but it's a lot of work and shouldn't be a goal before WireGuard becomes
> an upstream kernel module.

I'm pretty sure that's the way to go long-term.

Regards,

Vincent Wiemann
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: DNS name resolution should not be done during configuration parsing.

[Matthias Urlichs]

[-- Attachment #1.1: Type: text/plain, Size: 1303 bytes --]

On 19.02.19 16:45, Vincent Wiemann wrote:
> A kernel VPN module should not depend
> on a user space daemon for doing regular checks or a daemon running at
> all.

It doesn't. You only need userspace when the external IP address changes
*and* the other side either doesn't initiate a link to us, or can no
longer reach us due to firewall or NAT issues. This is already orders of
magnitude better than OpenVPN.

DNS is a complex protocol that's nontrivial to implement securely,
DNSSEC even more so. You do not want that in the kernel. I'd wager a
large chunk of money that neither does Linus Torvalds.

>     One could build up on
>     https://www.kernel.org/doc/Documentation/networking/dns_resolver.txt ,
>     but it's a lot of work and shouldn't be a goal before WireGuard becomes
>     an upstream kernel module.

    I'm pretty sure that's the way to go long-term.

Umm … you might want to read that. It specifies upcalling to userspace.
How is that better than running a WG daemon?

We'd also lose flexibility. I might want to teach that WG daemon to get
the new address from somewhere else, like a secure connection to a VPN
server (given that DNS timeouts might be too long), or to use that
netlink callback to trigger an alert or to activate a fallback connection.

-- 
-- Matthias Urlichs


[-- Attachment #1.2: Type: text/html, Size: 2131 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: DNS name resolution should not be done during configuration parsing.

[Vincent Wiemann]

Hi Matthias,

On 21.02.2019 08:59, Matthias Urlichs wrote:
> On 19.02.19 16:45, Vincent Wiemann wrote:
>> A kernel VPN module should not depend
>> on a user space daemon for doing regular checks or a daemon running at
>> all.
> 
> It doesn't. You only need userspace when the external IP address changes
> *and* the other side either doesn't initiate a link to us, or can no
> longer reach us due to firewall or NAT issues. This is already orders of
> magnitude better than OpenVPN.

There are setups where the "server" has a dynamic IP address and uses
DynDNS. The "client" sits behind a firewall. Thus the server can't
initiate a connection. When the IP address of the server changes, the
client loses connection.

> DNS is a complex protocol that's nontrivial to implement securely,
> DNSSEC even more so. You do not want that in the kernel. I'd wager a
> large chunk of money that neither does Linus Torvalds.

Please don't understand me wrong. I don't want to have DNS queries
running in kernel land.

>>     One could build up on
>>     https://www.kernel.org/doc/Documentation/networking/dns_resolver.txt ,
>>     but it's a lot of work and shouldn't be a goal before WireGuard becomes
>>     an upstream kernel module.
> 
>     I'm pretty sure that's the way to go long-term.
> 
> Umm … you might want to read that. It specifies upcalling to userspace.
> How is that better than running a WG daemon?

Not depending on a daemon, but only calling a userspace program when needed.

> We'd also lose flexibility. I might want to teach that WG daemon to get
> the new address from somewhere else, like a secure connection to a VPN
> server (given that DNS timeouts might be too long), or to use that
> netlink callback to trigger an alert or to activate a fallback connection.

You are right. Netlink notifications are a desirable feature.

I just think we should not depend on a daemon in this scenario.
We could also rewrite WireGuard to be in the userspace and implement a
"tunsock" in the kernel allowing us to use recvmmsg on a tun device. The
throughput would not be that much lower as the limiting factor of
userspace VPNs is often the number of context switches, but instead we
love to see WireGuard in the kernel, because high-bandwidth packet
processing should be done there. Likewise something as fundamental for a
VPN as DNS resolution should be called from where the VPN lives.
As far as I know no tunnel implementation exists in the kernel that
depends on a daemon running and as there is an existing API for DNS
resolution although it upcalls a userspace program (on which we agree
it's legit for DNS resolution) why don't we reuse and improve it?

Regards,

Vincent Wiemann
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: DNS name resolution should not be done during configuration parsing.

[David Kerr]

[-- Attachment #1.1: Type: text/plain, Size: 3055 bytes --]

I agree.  Wireguard should never terminate because of DNS failure, and
should continue to parse config files for links that may be able to get
established in absence of DNS.  Wireguard also has a significant startup
delay when DNS fails, several seconds while DNS times out, which should be
avoided.

David

On Tue, Feb 19, 2019 at 12:04 AM zrm <zrm@trustiosity.com> wrote:

> On 2/16/19 23:08, Jeffrey Walton wrote:
> > On Sat, Feb 16, 2019 at 10:35 PM David Kerr <david@kerr.net> wrote:
> >>
> >> Erik, see here for a proposed fix.  No response from the WireGuard team
> yet.
> >>
> >> https://lists.zx2c4.com/pipermail/wireguard/2019-January/003842.html
> >>
> >> Recently I had a power outage and both my gateway and cable modem went
> offline. On power recovery both devices start up, but the gateway completes
> startup before the cable modem completes its protocol negotiations, so
> initially the external network (eth0) is not functional.  That comes online
> say one minute later and all is well.
> >>
> >> Except that all is not well.  Wireguard failed to start up because I
> have Endpoint=<a URL> instead of a IP address.  And because external
> interface is not live yet, DNS lookup fails and Wireguard does not
> gracefully handle it.  This is really important because Wireguard may be my
> only way into my local network.
> >>
> >> As work-around I replaced the URL with the IP address... but that is
> not a long term solution if the endpoint is not a static IP address.
> >>
> >> Wireguard needs to handle the situation where external network may not
> have stabilized at the time it starts up.  The above link proposed a fix.
> >
> > Forgive my ignorance... Should init just retry the service start?
> > Something like this (from Systemd):
> >
> >      [Unit]
> >      StartLimitInterval=360
> >      StartLimitBurst=5
> >
> > The statements above say to retry 5 times within 360 seconds.
> >
> > Jeff
>
> The issue is that the service shouldn't terminate over failure to
> resolve an individual endpoint.
>
> Suppose name resolution fails because of a DNS failure rather than a
> network failure. If there are other endpoints configured by address that
> are still reachable, should we give up entirely and not even connect the
> ones that we can? What if one of the endpoints configured by IP address
> is the DNS server?
>
> Pushing this onto init would imply something like separate unit files
> per endpoint, which may complicate things more than simplify them.
>
> It seems like the conflict is that on the one hand, we want to resolve
> the name at connection time rather than configuration time, but on the
> other hand we don't want a DNS resolver in the kernel. How hard would it
> be to call out to a trivial userspace DNS client? This shouldn't be very
> performance sensitive, the results could be cached for the TTL which is
> typically hours or at least minutes.
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>

[-- Attachment #1.2: Type: text/html, Size: 4190 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: DNS name resolution should not be done during configuration parsing.

[Eryk Wieliczko]

[-- Attachment #1.1: Type: text/plain, Size: 2565 bytes --]

That fix is a hack. There simply shouldn't be ANY checking if the domain/port is correct in config.c.
If someone wants to use "nonexistentdomain.nonexistenthost.nonexistenttld:41342", WireGuard should not complain about it.

Of course, it should still check if the port number is < 65535. But leave the domain alone and check it only during connection.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, February 17, 2019 4:03 AM, David Kerr <david@kerr.net> wrote:

> Erik, see here for a proposed fix.  No response from the WireGuard team yet.
>
> https://lists.zx2c4.com/pipermail/wireguard/2019-January/003842.html
>
> Recently I had a power outage and both my gateway and cable modem went offline. On power recovery both devices start up, but the gateway completes startup before the cable modem completes its protocol negotiations, so initially the external network (eth0) is not functional.  That comes online say one minute later and all is well.
>
> Except that all is not well.  Wireguard failed to start up because I have Endpoint=<a URL> instead of a IP address.  And because external interface is not live yet, DNS lookup fails and Wireguard does not gracefully handle it.  This is really important because Wireguard may be my only way into my local network.
>
> As work-around I replaced the URL with the IP address... but that is not a long term solution if the endpoint is not a static IP address.
>
> Wireguard needs to handle the situation where external network may not have stabilized at the time it starts up.  The above link proposed a fix.
>
> David
>
> On Sat, Feb 16, 2019 at 8:35 PM Eryk Wieliczko <eryk@wieliczko.ninja> wrote:
>
>> Hello everyone!
>>
>> If you use a DNS address as an endpoint and there is no internet connection, WireGuard will hang for two minutes and then exit with error.
>>
>> IMO the expected behavior should be the same as in OpenVPN:
>> WireGuard starts immediately and patiently tries to resolve the DNS until it succeeds.
>>
>> Thus, WireGuard should resolve the DNS just before connecting to the server. And just keep trying and trying without any timeouts.
>>
>> I'd like to install WireGuard on technician's computers and there is no guarantee that they will start phone tethering within 2 minutes of starting their machine. OpenVPN would pass this scenario.
>>
>> What do you think?
>> _______________________________________________
>> WireGuard mailing list
>> WireGuard@lists.zx2c4.com
>> https://lists.zx2c4.com/mailman/listinfo/wireguard
>
> --
> David Kerr Sent from Gmail Mobile

[-- Attachment #1.2: Type: text/html, Size: 4356 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: DNS name resolution should not be done during configuration parsing.

[Vincent Wiemann]

It would be great if WireGuard could resolve DNS without one having to
call the userspace configuration tool manually (e.g. to support DynDNS).
One could build up on
https://www.kernel.org/doc/Documentation/networking/dns_resolver.txt ,
but it's a lot of work and shouldn't be a goal before WireGuard becomes
an upstream kernel module.

Regards,

Vincent Wiemann

On 17.02.2019 04:03, David Kerr wrote:
> Erik, see here for a proposed fix.  No response from the WireGuard team
> yet. 
> 
> https://lists.zx2c4.com/pipermail/wireguard/2019-January/003842.html
> 
> Recently I had a power outage and both my gateway and cable modem went
> offline. On power recovery both devices start up, but the gateway
> completes startup before the cable modem completes its protocol
> negotiations, so initially the external network (eth0) is not
> functional.  That comes online say one minute later and all is well.
> 
> Except that all is not well.  Wireguard failed to start up because I
> have Endpoint=<a URL> instead of a IP address.  And because external
> interface is not live yet, DNS lookup fails and Wireguard does not
> gracefully handle it.  This is really important because Wireguard may be
> my only way into my local network.
> 
> As work-around I replaced the URL with the IP address... but that is not
> a long term solution if the endpoint is not a static IP address.
> 
> Wireguard needs to handle the situation where external network may not
> have stabilized at the time it starts up.  The above link proposed a fix. 
> 
> David
> 
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
> 
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard