[buug] DHCP: override name server conditionally

[Michael Paoli]

Quoting Ian Zimmerman <itz at madbat.mine.nu>:

> With the ISC DHCP client version 3, I would like to change the name server,
> just as a "supersede domain-name-servers" line in dhclient.conf would do,
> but _only_ if I am talking to a particular DHCP server.
> 
> The right place to change seems to be a script in dhclient-enter-hooks.d
> that redefines the shell function make_resolv_conf.  The DHCP protocol
> option dhcp-server-identifier seems to be almost right for this, except
> that it contains the IP address which will be 192.168.0.1 in this case
> (and also in other cases), not helpful.  Ideally I would have the MAC
> address of the server.  Well, I could put an arp command in the script.
> But that is getting really too hackish.
> 
> Hmm.  Since I control this particular DHCP server, maybe I can make it
> return a recognizable hostname and use that as the condition.
> Any other suggestions?
> 
> (Background: this is on a laptop that I use both at home and in other
> locations.  My ISP's name servers are buggy, they demonstrably ignore
> TTLs in some cases and cache stuff much longer.  So I want to avoid them.)

Looking over at least some of the documentation, and keeping prudent
programming practices in mind, etc., I come to at least approximately
the same conclusions.  At least for the ISC based DHCP client I have on
Debian GNU/Linux 3.1, dhclient-script(8) seems to indicate the likely
places to put such DHCP server specific client configurations.
I agree that using an RFC 1918 IP address of server as the conditional
(especially something as commonly used as 192.168.0.1) would be a poor
choice of conditional.  Determination by Ethernet MAC address might also
be a less-than ideal selector - e.g. if the network changes (such as
server gets replaced, or DHCP forwarding comes into play and server is
no longer on the subnet), that may not be a good selector.

What I'd suggest as a logical selector, would be the undesired DNS server IP
addresses that are being handed out by certain DHCP server(s) - particularly
if those are Internet IP addresses, and not RFC 1918 addresses.  By
using the non-desired IP addresses of DNS servers (which is the "problem"
to begin with), triggering on that to put in the desired DNS server addresses,
that would (or at least should?) reliably detect the undesired data, trigger
on it, and in response configure with the desired data, rather than the
undesired data.  It would seem based upon dhclient-script(8) that something
in/around make_resolv_conf would be the logical place to detect that
conditional and adjust to take the corrective action.  About the only
probable downside I can see with that approach, is if the offending DHCP
server switches to handing out different DNS server IP addresses that are
also undesired, that event might not be quite as predictable.  But that type
of change probably doesn't occur frequently - and one might also broaden
the check of offending DNS IP addresses (e.g. to all the IPs used/reserved
for the ISP's infrastructure).  Ethernet MAC addresses and/or IP address(es)
of DHCP server may also potentially change - but again, those probably
don't change all that often for the "offending" DHCP server.  Another
approach that might be possible, would be detecting some other parameters/data
offered by the "offending" DHCP server that make it uniquely identifiable
... at least if such can be easily found and identified.  Also, reverse
DNS lookup of the offending (or potentially offending) DNS server IPs
might be a pretty reliable check (e.g. if one looks them up against those
DNS servers themselves, do they resolve to something in the domain of the
offending ISP?).

Anyway, hope that helps (at least a bit) ... might give one some useful ideas
on various possible approaches and considerations, anyway.