Using supersede domain-search in dhclient+resolvconf appears to append?

Question

On my Ubuntu 16.04 machine, I'm using DHCP to get an IP address from my ISP's router. It replies with DNS servers and DNS search domains I want to override.

/etc/dhcp/dhclient.conf:

option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;

send host-name = "my.hostname";

request subnet-mask, broadcast-address, routers, interface-mtu;

supersede domain-name-servers 10.1.2.3;
supersede domain-search "mydomain.tld";

Here I've configured the DHCP client to:

not request domain nameservers and/or search domain
override both domain-name-servers and domain-search if provided anyway.

However, what happens with resolvconf now:

/etc/resolv.conf:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 10.1.2.3
search home mydomain.tld

Notice the home entry there? That's what my crappy ISP router is sending me despite I'm not requesting it (confirmed with tcpdump see below). So, apparently, dhclient is appending instead of overriding, as if I had used append instead of supersede.

What am I doing wrong? I want dhclient to ignore the bogus non-configurable DNS search domain.

I would consider this a security issue, since I don't want it to search a spooky domain for every DNS query I do on my host. Also, why is dhclient even bothering to parse reply options it didn't ask for?

Software version information (all stock Ubuntu 16.04):

ii  isc-dhcp-client                        4.3.3-5ubuntu12.7
ii  resolvconf                             1.78ubuntu4

tcpdump:

01:09:35.629136 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 52:54:00:23:86:a8, length 300, xid 0x9e3d912a, Flags [none] (0x0000)
          Client-Ethernet-Address 52:54:00:23:86:a8
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Request
            Requested-IP Option 50, length 4: 192.168.999.24
            Hostname Option 12, length 27: "my.hostname"
            Parameter-Request Option 55, length 4: 
              Subnet-Mask, BR, Default-Gateway, MTU
01:09:35.642166 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 576)
    192.168.999.1.67 > 192.168.999.24.68: [udp sum ok] BOOTP/DHCP, Reply, length 548, xid 0x9e3d912a, Flags [none] (0x0000)
          Your-IP 192.168.999.24
          Server-IP 192.168.999.1
          Client-Ethernet-Address 52:54:00:23:86:a8
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: ACK
            Server-ID Option 54, length 4: 192.168.999.1
            Lease-Time Option 51, length 4: 3600
            Hostname Option 12, length 27: "my.hostname"
            Subnet-Mask Option 1, length 4: 255.255.255.0
            Default-Gateway Option 3, length 4: 192.168.999.1
            Domain-Name-Server Option 6, length 8: 1.2.3.4,4.5.6.7
            Domain-Name Option 15, length 4: "home"
            TTL Option 23, length 1: 64

score 1 · Answer 1 · answered Jul 07 '17 at 23:42

I was superseding the wrong dhcp-option.

Instead of domain-name-search option, my ISP router responded with a domain-name option. The latter is the option to supersede.

It seems that the dhclient-resolvconf combination merges the information from both the primary domain name (home here) with the search domains.

Still open for thought: why does dhclient bother to parse and process the option domain-name? I did not request it. Apparently, I need to supersede all the answers I didn't ask for this untrusted device is sending me? Sounds like a nice attack vector here...

score 0 · Answer 2 · answered Mar 20 '20 at 09:34

Some of your question regarding why domain-name is returned by the DHCPD server is addressed in the manpage for dhclient.conf:

The request statement causes the client to request that any server responding to the client send the client its values for the specified options. Only the option names should be specified in the request statement - not option parameters. By default, the DHCPv4 client requests the subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-search, domain-name-servers, host-name, nis-domain, nis-servers, ntp-servers and interface-mtu options. The DHCPv6 client requests by default name-servers and domain-search. Note that if you enter a 'request' statement, you over-ride this default and these options will not be requested.

The request; asks for a default set:

By default, the DHCPv4 client requests the subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-search, domain-name-servers, host-name, nis-domain, nis-servers, ntp-servers and interface-mtu options

As you can read in the question, I override the `request` setting in my DHCP client, so this is not really a solution. In the meantime I have migrated to systemd-networkd, by the way. (And apologies for the late reply.) — gertvdijk, Nov 22 '21 at 22:12

Using supersede domain-search in dhclient+resolvconf appears to append?

What am I doing wrong? I want dhclient to ignore the bogus non-configurable DNS search domain.

2 Answers2

I was superseding the wrong dhcp-option.