NM in systemd-resolved mode pushes default domain routes when no search paths exist
This is a variant on #47 (closed), which isn't fixed by the systemd patch that is linked there.
When NetworkManager uses dns=systemd-resolved (I tested on Ubuntu 20.10), and brings up a DHCP connection that returns no search domains, it pushes a config into resolved with the "~." route-only domain set, in addition to the normal "DNS default route" flag.
This should be unnecessary for correct operation, and breaks VPN clients that speak to resolved directly rather than NetworkManager, because they can no longer install a "~." resolver to mask local default resolvers (since all resolvers registered as "~." receive queries).
I haven't traced exactly how this behavior happens in the code, but it seems that the resolved plugin might not be generating the correct config for resolved when there are no DNS search paths. I also didn't find any evidence in the bug tracker or code that this is a deliberate behavior to work around some other issues, so I think this is a bug that's just a bit unusual to trigger because most VPNs either replace /etc/resolv.conf completely or configure themselves via NetworkManager?...
If someone can confirm that the expected behavior in this scenario should be that NetworkManager registers a resolver with just DNS default route, I'm happy to dig more and send a patch.