Setting DNS rewrote the connection profile and stopped there, so the running device kept resolving through whatever it had before. Nothing noticed while something else always activated the device afterwards: the profile was written first and NetworkManager picked the resolvers up when it got round to the interface on its own. Turning a DHCP client off now applies the profile when the device is not activated, which moved that activation ahead of the DNS write. A caller that sets an address, disables DHCP, and then sets resolvers -- the order a static configuration is naturally applied in -- ends with the device activated on a profile that had no DNS in it yet, and the write that follows never reaches the system. The profile carries the resolvers, resolv.conf carries none, and ipv4.ignore-auto-dns has by then ruled out the lease's resolvers as well: an interface holding an address, a route, and no way to resolve a name. Reapply the device after the change. Unlike turning a client off, this risks nothing for a caller connected over the interface -- reapply changes the device in place and does not tear the link down -- so it is not conditioned on the device being unactivated, which is exactly the case that needs it. |
||
|---|---|---|
| .. | ||
| results | ||
| nmcli | ||