DHCP settings of different cards are mixed up

[pulkomandy]

On my local network I have my own dhcp server that provide name lookup for the local machines, so that I can easily ssh my homeserver or otherwise communicate without remembering all the IP addresses.

However, Haiku insist on using the DNS server it got from DHCP on my wireless card that's connected to my neighbour's unencrypted wifi, which I don't want to use. Disabling the wireless card in the network settings and re-running a DHCP request seems to work, but the wireless is enabled again on next boot and I have to disable it again.

Please use different DNS settings for each card and don't overwrite them each time a DHCP lease is run on any card.

Note that having one interface configured as static and another one as DHCP will make the DHCP one overwrite the DNS and domain settings for the static one, too.

[bga]

I am not sure I understand what you mean. DNS servers are set globally in a computer. There is no way to set a DNS server for one interface and a different DNS server for another interface.

[pulkomandy]

The problem is I want to use my wired ethernet card, and the DHCP settings I get from this card. But the DNS is overwritten by the one I get by DHCP on my wireless card, which I don't want to use, but I have no way to tell that to my computer.

If there is only one DNS list, why can each interface request DNS servers from DHCP ? And can't they be chained instead of overwriting each other ?

[bga]

Well, they can't. Merging the lists is not a real solution either as the order DNS lookups happen matters. I am not sure what is the expected behavior when you have 2 different interfaces receiving DHCP reponses with different web servers. Do you have any other OS in the same machine that you can use to test that?

Anyway, I guess the correct solution would be to simply request the DNS in one interface (or ignore the response on the other). But then a way to tell the OS what to do is needed.

[axeld]

I've made this an enhancement ticket, as bga is absolutely right about this - there is no actual bug. I'm not sure how this could be solved in a nice way, but if you can figure something out, maybe we can implement it :-)

One way to solve your specific problem would be not to allow the second DHCP run overwrite the settings of the first unless its lease expired. As bga said, the order of the DNS lookups matter, so while chaining would be a possibility, it's not a perfect one, either -- still probably better than what we do now.

[IIsi50MHz]

On other OSes, I like being able to set DNS server IP addresses, as overrides to DHCP. Haiku's Network preflet appears to allow this, and in fact does save them to resolv.conf in whatever order your specify, but once DHCP runs, it deletes them.

Being able to specify that you _do_ or _do_not_ want (for example) to use Google's DNS servers at 8.8.8.8 and 8.8.4.4 is a desirable thing, as the DNS servers provided via DHCP maybe be slow, buggy, or less trusted.

Looking at:

DNSTools::GetDNSServers(BObjectList<BString>* serverList) in haiku/src/preferences/mail/DNSQuery.cpp

I see a TODO about wanting a function to retrieve the DNS list instead of reading resolv.conf directly. I can see where it is just looking for the nameservers in the file.

At first thought, it seems this and haiku/src/add-ons/network_settings/dnsclient/DNSSettingsView.cpp could be a place to start for allowing DNS server overrides. Possibly, resolv.conf and its accessors could support a flag to force user-added entries to remain in the list.

However, then a conceivable enhancement would be to store DNS servers per-interface and per-wifi-access-point, instead of (or in addition to) globally. It is conceivable, for instance, that:

1. A user might have an ISP-provided router at home that:
   1. Tries to make itself the default DNS server.
   2. Is terrible at its job as a DNS server (while remaining functions work; ISP will not replace it)
2. While connected to that network, the user wants to specify different DNS servers.
3. While connected to other networks, other DNS servers configure by DHCP might be acceptable to the user.

A global override of DNS servers might be a good start, as it resolve the original problem scenario. It could however, in rare(?) circumstances possibly cause a user to need to enter the Network preflet and adjust settings if they connect to a network where either certain DNS servers are mandated or the user-specified overrides are not reachable.

To account for this, the DHCP-provided DNS servers could be tried after any user-added DNS servers. This could make name-resolution noticeably slower. To mitigate this, perhaps for the duration of an established link, if user-provided nameservers are unreachable (after n attempts?), they could be soft-flagged to be skipped.

Of course, the next thing somebody might ask for is a way to blacklist nameservers, even if they are provided by DHCP...