As I've stumbled into exactly the same problem, I've taken the liberty to take the patch posted earlier by Ashley and update it to the latest lwIP master. It should now apply easily, with no errors or rejects. I've also allowed myself to improve it slightly:
- I've renamed the option from LWIP_DNS_SERVER_PER_NETIF to LWIP_DNS_SERVERS_PER_NETIF, as this seems more correct
- I've added the new option along with a (rather long) description to opt.h
- I've modified the few remaining dns_{get,set}server() calls which were left by the original patch (if I remember correctly - one in dns_init(), one in dhcp6.c and a few in nd6.c)
- couple of minor things

Please let me know what can be done to merge this patch, as I would really prefer NOT to keep working with a forked submodule (; I'm open to suggestions how to further improve it or even change it into some other method for solving this not-so-common issue.

(file #50107)

> What is the process for submitting this patch?

Just attach the patch file to this bug (see bottom of this page). Ideally, you'd provide a 'git format-patch -1 HEAD' like patch to have one commit from our current git master HEAD.

Windows allows manually or automatically setting two DNS servers per network interface.  No idea what linux/unix does.

Cheers

Ashley

The netif is a PPP connection to a u-Blox W152 WiFi module.  When the PPP connection is established to the module, it appears to negotiate a DNS address and set it.  The DNS address is actually just the IP address of the module on the PPP connection.  However, the module has no internet connection to the outside world until you send it commands (on a UDP port over the PPP link) to tell it to make the WiFi link.  Additionally the module is also a Bluetooth device which is controlled over the same UDP port.  Sometimes we wish to only use it for Bluetooth and never enable the WiFi.

So, to lwIP, the PPP connection appears as a valid outside world connection, which is fair enough, but it is not.  In fact, while the WiFi link is not enabled, the netif is set to link down.

But a DNS resolution on another netif still uses the DNS address supplied by the PPP connection even though it is in link down state.  Because it was the last netif to call dns_setserver.  But the DNS address is the local address of the module on the PPP link, not an outside world address.

The other situation is when you have two netifs (e.g. ethernet and wifi), both have gateways that have a preferred DNS address which is supplied upon DHCP resolution, maybe even offering a local cache or service.  Should the preferred DNS address not be used for each netif rather than just whatever the last supplied was?

There appears to be no hooks or way to manage the receive of DNS addresses to manage them yourself.  Auto assigning by DHCP can be disabled, but not by PPP.   The received DNS address is not stored anywhere for later access, except overwrites the global array (in dns_setserver).

Without deep investigation, it seems to me that if dns_setserver took a netif pointer and all reads of DNS addresses were through dns_getserver (rather than direct array access) and had a netif pointer, and these functions could be hooked or overridden.  Then you could manually manage your own DNS addresses.

In fact, it seems I have no option but to make this change in my situation?

Furthermore, there appears to be no way to manually set a DNS address without risk of it being overwritten by DHCP or PPP. 

Hope that helps explain.

Cheers

Ashley

I have stumbled across a problem today where DNS resolution was failing when using multiple netifs.  I tracked it down to the use of a global dns_servers array that is updated by the last netif that gets given a DNS address, even if that netif has no internet connection.  Other netifs can then not perform DNS resolution even though they have a valid internet connection.

Could the dns_servers array not be part of netif so that the correct dns server address can be fetched from the current default netif?  Other sending activities default to using the default netif.

Use case:

In this instance there is a DHCP capable ethernet interface and a PPP wifi interface.  Both of these interfaces set the dns_servers array while negotiating IP address.  Depending on which netif sets the dns_servers array last sets the IP address used for DNS resolution.

Typically Ethernet is set as the default netif and has a valid internet connection.  It comes up first and sets a DNS  address given by DHCP.

The PPP interface is always up, even if the wifi module has no link, which it often doesn't.  It comes up second setting dns_servers to the PPP given values, overwriting the ethernet dns address.

If I try to use DNS resolution on ethernet, it uses the PPP dns_server values which of course fails.  If I unplug ethernet, plug it back in.  dns_servers are updated by the Ethernets DHCP, then then DNS resolution can be used.