altoid via Dng <dng@???> wrote:

> On 19 Mar 2025 at 7:37, Ralph Ronnquist via Dng wrote:
>
>> RTFM :)
> Right.
> Thanks for the heads up. 8^D
>
>> ... been part of the Dynamic Host Configuration Protocol (DHCP) for
>> a very long time ...
> I see.
>
> From what I have seen and read on the web, the great many complaints
> from users that did not take kindly to their DNS settings getting
> changed without notice *also* seem to have started a long time ago,
> impossible for me to say with any certainty if both timelines match.
>
> What I can say is that that specific part of the DHCP ended up being
> a severe nuisance till I decided to drop [connman] and use
> [ifupdown].

If you take a step backwards and take a deep breath ...

The vast majority of users, regardless of operating system, like the idea that they can plug their computer into a network and it will “just work” - and “works” really means “has working DNS resolution". The vast majority of users (even Linux ones but perhaps not such an overwhelming proportion) will be happy with the defaults - otherwise they have strange problems where it doesn’t work and they have to perform arcane rituals and incant strange commands.
And it’s something you can over-ride easily if the default is not to your liking - unlike the other commercial OS’s.

So I’d suggest that the vitriol is undeserved. For those of us technically literate enough to want something different, it’s reasonably easy to change the default behaviour - on Linux, and when not using the more cantankerous software like Network Manager !

Now, if you have a crippled, ISP supplied router that does “interesting”* things - that’s not the fault of the DHCP protocol, it’s the fault of the ISP and/or router vendor for doing “interesting”* things. It’s why I’ve turned off the DHCP service in the router and run my own DHCP service on a (pre-systemd) Debian box.

* One recent “interesting” thing being that while the ISP supplied router would allow me to change the internal subnet away from 192.168.1.0/24 (being in a day job involving networking for clients, it saves a lot of complications to avoid that default), the DHCP service wouldn’t work properly if I did. I assume bug (192.168.1.0 hardcodes in the DHCP config) rather than malicious intent on that one.
More recently, I manage the internet connection and WiFi for our church & hall. The WiFi has an option to provide the AP with an IP address via a custom DHCP option and it will use a controller at that address for management - the router doesn’t have the ability to add custom options.


So there are multiple ways to solve this issue :

1) Just turn off the ISP supplied DHCP service and run your own.

2) Reconfigure it to not provide the DNS-Server option.

3) Reconfigure it to provide the DNS-Server option using your desired internal address(es).

4) Add a second router between your network and the ISP supplied router - thus isolating you from the ISP router. This doesn’t mean having a second layer of NAT if the ISP router supports adding a static route to send all internal traffic via your own router.

5) If none of those are possible, use a switch which has the ability to snoop and block “rogue” DNS servers so that the ISP supplied rubbish cannot fudge about with your network.

All of the above will solve the problem at the network level for all of your clients. The ones below affect individual hosts.

6) Configure your DHCP client to not ask for the DHCP-Servers option, or to ignore it if it’s returned.

7) Use one of the other workarounds already described in this thread.


For comparison, things are different with IPv6.
DHCPv6 isn’t used by default - it has to be specifically enabled by setting the managed flag in router advertisements (RAs). If it is used, it doesn’t provide all the information that is provided by DHCPv4 - e.g. it can’t provide router information (that’s in RAs).
In part this is driven by a certain vendor with a religious zeal that networks must not be allowed to control devices connected to them - in spite of this being a legal requirement in some settings. This goes so far as to require (or at least, encourage) hardware vendors to actively filter DHCP packets in the hardware if they want to run that vendor’s mobile OS, and thus prevent the use of a third party supplied DHCP client. It’s also driven by the case that mobile devices typically change connection state frequently, and this would be problematic with DHCP assigned addresses - but this also affects devices (e.g. on static wired networks) where this isn’t the case, but “la la la, we can’t hear you” seems to be the attitude of said vendor.
It’s also driven by the argument that typically the network and servers are managed by different groups in large organisations - hence the server people shouldn’t be handing out network information. I personally think this is a bit bogus since the two can’t exist in isolation - the server people need to understand the network, and the network people need to understand the servers, they can’t just change stuff in isolation and expect everything to carry on working.


Just my 2d worth, Simon