Score:0

ip4.dns option ignores after updrade 20.04 to 22.04

me flag

I have few broadband connections with flag ipv4.ignore-auto-dns: yes in my NewtorkManager connections list. In 20.04 activation of such connection causes correct configuration of custom name serves, but after update to 22.04 I see empty list of resolver. If I set ipv4.ignore-auto-dns: no in 22.04 provider resolvers are correctly adds.

20.04 connection activation, you can see args="ipv4.dns" in log

mar 24 23:47:19 dell-7490 NetworkManager[1275]: <info>  [1679698039.7961] audit: op="connection-update" uuid="74cb2988-c284-46b2-a833-f6fac9848084" name="netia" args="ipv4.dns" pid=4974 uid=1000 result="success"
mar 24 23:47:25 dell-7490 NetworkManager[1275]: <info>  [1679698045.0280] device (cdc-wdm2): Activation: starting connection 'netia' (74cb2988-c284-46b2-a833-f6fac9848084)
mar 24 23:47:25 dell-7490 NetworkManager[1275]: <info>  [1679698045.0282] audit: op="connection-activate" uuid="74cb2988-c284-46b2-a833-f6fac9848084" name="netia" pid=4974 uid=1000 result="success"
mar 24 23:47:25 dell-7490 NetworkManager[1275]: <info>  [1679698045.0283] device (cdc-wdm2):

22.04 connection activation, no args= in log

mar 27 23:52:13 dell-7490 NetworkManager[1260]: <info>  [1679953933.5231] device (cdc-wdm2): Activation: starting connection 'netia' (74cb2988-c284-46b2-a833-f6fac9848084)
mar 27 23:52:13 dell-7490 NetworkManager[1260]: <info>  [1679953933.5235] audit: op="connection-activate" uuid="74cb2988-c284-46b2-a833-f6fac9848084" name="netia" pid=2504 uid=1000 result="success"
mar 27 23:52:13 dell-7490 NetworkManager[1260]: <info>  [1679953933.5238] device (cdc-wdm2): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
mar 27 23:52:13 dell-7490 NetworkManager[1260]: <info>  [1679953933.8775] device (cdc-wdm2): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')

dell-7490:~$ NetworkManager --version
1.36.6

dell-7490:~$ nmcli c s 74cb2988-c284-46b2-a833-f6fac9848084 | grep -E 'ipv4.dns|ipv4.ignore-auto-dns'
ipv4.dns:                               1.1.1.1,8.8.8.8
ipv4.dns-search:                        --
ipv4.dns-options:                       --
ipv4.dns-priority:                      0
ipv4.ignore-auto-dns:                   yes

dell-7490:~$ resolvectl status wwan0
Link 12 (wwan0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Looks like NetworkManager ignores args="ipv4.dns" for broadband connections.

Is it expected behavior? Or but in ubuntu\NetworkManager ?

ru flag
What's your current Network Manager configuration for your device? I see that it says `-DefaultRoute` so I'm wondering if your system is *not set* to use the broadband as a default route, and therefore another DHCP item is superseding the DNS config.
Nick avatar
me flag
If I change `ipv4.ignore-auto-dns: no` in my connection when provider resolvers are correctly adds, so no problems with default route
ru flag
I think then the core problem is your config. `ignore-auto-dns` *ignores* any DHCP DNS servers received by your broadband connection. I think in 20.04 that was ignored or broken but in 22.04 it was fixed and ResolveD is properly *ignoring* the DNS on the connection. What's your goal here, you *want* the custom DNS servers to show up? Then remove your `ipv4.ignore-auto-dns: yes` line
Nick avatar
me flag
@ThomasWard tank you for your suggestions, but as I wold like to skip providers DNS. In 20.04 I saw providers DNS+my own with `ipv4.ignore-auto-dns: no` and only my with DNS with `ipv4.ignore-auto-dns: yes` . In 22.04 NetworkManger even don't tries to add my own recursors to systemd-resolved. Also tested on fresh 22.04, behavior is same
ru flag
if you don't set DNS per interface manually in your network manager configuration, then you won't have DNS servers on the interface. That's normal. You have to add configurations for the DNS there, but Network Manager might not set it per interface. Just for kicks, can you share the total output of `resolvectl status` just as is? See if it's setting the DNS but might be superseded by another config.
Nick avatar
me flag
custom DNS configure in connection options `ipv4.dns: 1.1.1.1,8.8.8.8` https://pastebin.com/raw/z8En9a94
Nick avatar
me flag
and I found a way to boot from 20.04, same commands from old os https://pastebin.com/b2TWUgH8
Score:0
pk flag

I bump this I have a Sierra Wireless cellular modem

Connection config set with ipv4.ignore-auto-dns: yes ipv4.dns: 8.8.8.8

8.8.8.8 never gets assigned. Its also hit and miss if i get a DNS from the cellular networks hence wanting to assign one manually.

So it looks like the ignore-auto-dns option is ignored or just not compatible with cell modems?

The only work around i can see so far is to set "FallbackDNS=8.8.8.8" in the /etc/systemd/resolvd.conf file.

This hack/bodge would assign a global DNS if none are present keeping my server up.

Not had enough time to dig deeper but i am wondering if there is an underlying issue with DNS/systemd-resolv/network manager/modem manager and cellular modems. I notice that sometimes the Cellular Network assigned DNS just disappears from the Cellular connection.

I have not had a chance to see if the ignore-auto-dns has the same effects on Ethernet interfaces.

Interesting one this

Nick avatar
me flag
This issue caused by major refactoring in NetworkManager 1.22->1.36 here is my corresponding issue on FreeDesctop gitlab https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1261 With suggested patch the behavior is differ from 1.22, but usable for me
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.