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

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

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...