Bug 2144521
Summary: | [RFE] The option to set no-aaaa in resolv.conf are not available in NetworkManager | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Josep <jfont> | ||||
Component: | NetworkManager | Assignee: | Fernando F. Mancera <ferferna> | ||||
Status: | CLOSED ERRATA | QA Contact: | Filip Pokryvka <fpokryvk> | ||||
Severity: | medium | Docs Contact: | Mayur Patil <maypatil> | ||||
Priority: | medium | ||||||
Version: | 8.7 | CC: | bdm, bgalvani, ferferna, fweimer, jomarque, lrintel, maypatil, myllynen, rkhan, sfaye, sukulkar, till, vbenes | ||||
Target Milestone: | rc | Keywords: | FutureFeature, Triaged | ||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | NetworkManager-1.40.16-4.el8 | Doc Type: | Enhancement | ||||
Doc Text: |
.`NetworkManager` supports the `no-aaaa` DNS option
You can now use the `no-aaaa` option to configure DNS settings on managed nodes by suppressing AAAA queries generated by the stub resolver. Previously, there was no option to suppress AAAA queries generated by the stub resolver, including AAAA lookups triggered by NSS-based interfaces such as `getaddrinfo`; only DNS lookups were affected. With this enhancement, you can disable IPv6 resolution by using the `nmcli` utility. After a restart of the `NetworkManager` service, the `no-aaaa` setting gets reflected in the `/etc/resolv.conf` file, with additional control over DNS lookups.
|
Story Points: | --- | ||||
Clone Of: | |||||||
: | 2176137 (view as bug list) | Environment: | |||||
Last Closed: | 2023-11-14 15:49:35 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 2176137, 2183216 | ||||||
Attachments: |
|
Description
Josep
2022-11-21 14:55:12 UTC
Thanks for working on this. I tried this quickly (NetworkManager-1.40.16-4.el8.x86_64.rpm) in a dnsmasq based DNS caching setup on an IPv4-only host with dns=dnsmasq. The no-aaaa option was accepted in the NIC nmconnection ini file (no warnings or errors) but it did not appear in /etc/resolv.conf. Perhaps this is a scenario which has not been considered so far and is now more relevant? Thanks. > The no-aaaa option was accepted in the NIC nmconnection ini file (no warnings or errors) but it did not appear in /etc/resolv.conf
The scenario you describe works fine in my test setup.
Please ensure that:
- you have restarted the service after the package upgrade
- if you modified the nmconnection file directly, you need to either call "nmcli connection reload" (preferred) or restart the service
- in any case, you need to reactivate the profile with "nmcli connection up $name" to have the new setting take effect.
If it still doesn't work, please show the output of:
cat /etc/resolv.conf
NetworkManager --print-config
and possibly attach a log at trace level.
I even rebooted the system earlier to no avail, here's what I see now after booting up the test VM: root@rhel-8-server:~# rpm -qa | grep NetworkManager | sort NetworkManager-1.40.16-4.el8.x86_64 NetworkManager-libnm-1.40.16-4.el8.x86_64 root@rhel-8-server:~# cat /etc/NetworkManager/conf.d/* [main] dns=dnsmasq root@rhel-8-server:~# cat /etc/NetworkManager/dnsmasq.d/* addn-hosts=/etc/hosts domain-needed bogus-priv local=/example.com/ local-ttl=10 min-cache-ttl=10 neg-ttl=10 root@rhel-8-server:~# cat /etc/resolv.conf # Generated by NetworkManager search example.com nameserver 127.0.0.1 options edns0 trust-ad root@rhel-8-server:~# cat /etc/NetworkManager/system-connections/net0.nmconnection [connection] id=net0 uuid=33e2dfe5-649b-21d9-4fc5-2feaad011ccc type=ethernet interface-name=net0 [ethernet] [ipv4] dns-options=no-aaaa;edns0;trust-ad method=auto [ipv6] addr-gen-mode=eui64 method=disabled [proxy] root@rhel-8-server:~# ip l 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: net0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:e7:11:6f brd ff:ff:ff:ff:ff:ff root@rhel-8-server:~# I'll also attach the requested travel level log. Thanks. Created attachment 1960127 [details]
nm-log-trace.txt
Hi, the problem is: <warn> [1682514298.2879] keyfile: load: "/etc/NetworkManager/system-connections/net0.nmconnection": failed to load connection: File permissions (100644) are insecure The connection file must only be accessible by root because it can contain secrets. In general the best way to add or modify connections is via nmcli because it takes care of everything. If you create files manually, you need to set the correct permissions or umask. See also: https://access.redhat.com/documentation/it-it/red_hat_enterprise_linux/8/html-single/configuring_and_managing_networking/index#assembly_manually-creating-networkmanager-profiles-in-keyfile-format_configuring-and-managing-networking Good catch, thanks for pointing it out, now it works! Earlier on this VM I did manually a one-time migration from RHEL 8 default ifcfg files to connection files and that caused this hiccup. Wrt the link, with connection files it looks like from RHEL 9 onwards using the network system role is a good choice when doing configurations with Ansible in scale. Thanks. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (NetworkManager bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2023:7118 |