nss-resolve returns an IPv6 address even when IPv6 is disabled

[mrc0mmand]

systemd version the issue has been seen with

251

Used distribution

Fedora 36

Linux kernel version used

No response

CPU architectures issue was seen on

No response

Component

No response

Expected behaviour you didn't see

nss-resolve should return an IPv4 address when net.ipv6.conf.all.disable_ipv6=1.

Unexpected behaviour you saw

nss-resolve return an IPv6 address with net.ipv6.conf.all.disable_ipv6=1

Steps to reproduce the problem

# cat /etc/hosts
10.0.0.1               ns1.unsigned.test
fd00:dead:beef:cafe::1 ns1.unsigned.test
# sysctl -w net.ipv6.conf.all.disable_ipv6=0
net.ipv6.conf.all.disable_ipv6 = 0
# getent -s resolve hosts ns1.unsigned.test
fd00:dead:beef:cafe::1 ns1.unsigned.test

# sysctl -w net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.all.disable_ipv6 = 1
# getent -s resolve hosts ns1.unsigned.test
fd00:dead:beef:cafe::1 ns1.unsigned.test

Additional program output to the terminal or log subsystem illustrating the issue

No response

[yuwata]

I cannot find it, but IIRC, I opened a PR which tries to fix the similar issue but it was refused by @poettering.
@poettering Do you remember that??

[pemensik]

I think resolved should still deliver IPv6 address if requested explicitly by -t AAAA. It might just not start AAAA queries when requested by getaddrinfo call with AF_UNSPEC.

[flokli]

This works as intended - see #14125 for the rationale.

It's up to clients (implementing RFC6724) to determine how to reach a given destination, whether to consider the v6 records returned or not. The resolver trying to be smart about it is almost always wrong.

[pemensik]

@flokli your MR were fixing a bit different issue. I agree resolver should not REMOVE some records from answers. Or make queries only based on route present. But it is not necessary to start queries for address family explicitly disabled on the system. It should avoid A queries when IPv4 is disabled and it similarly avoid AAAA queries when IPv6 is disabled on whole system. Unless they were requested explicitly. Which is depends on what AF were specified by call to getaddrinfo(), responsible for contacting nss-resolve. I think it does not need to start AAAA query with AF_UNSPEC, when IPv6 is disabled on the system. But it MUST start AAAA query with AF_INET6 specified in hints. Regardless of system configuration.

If nss-resolve creates two separate queries for A and AAAA records, then one can be avoided if the whole protocol is disabled on the system level. If it did ANY type query, then it should return all results received. But it does not need to ask unless explicitly specified it should. I agree all applications should be able to handle any valid responses.

[flokli]

You have a point. I'd still err on the side of caution.

resolved can speak UDP on port 53, and DNS lookups popping up there might come from systems with IPv6 enabled in the kernel (think about local (firecracker) VMs, which bring their own kernel).

Sure, it's highly unlikely that such a VM then has v6 connectivity over a L2, while IPv6 is explicitly disabled in the host kernel, but still…

--

It feels like adding this complexity in resolved doesn't gain us a lot, except saving some DNS requests that are usually cached anyways.

I'd rather have some SkipAAAAOnAFUnspec= config knob in resolved.conf that sysadmins can set to yes if they really care. I'd argue most browsers etc. doing happy eyeballs do explicit requests anyways.

Disabling IPv4 kernel-wide is not really a thing anyways unfortunately, so we don't really need a knob for that.

[pemensik]

Yes, but what RR type was queried on port 53, that type should be asked on forwarder. There is no AF_UNSPEC equivalent on unicast DNS. QType ANY does not have well-defined behaviour on unicast DNS, unlike MDNS. It cannot be used to obtain both A and AAAA request reliably. systemd-resolved is failing to be good recursive cache in several way, but this is already implemented well and must not be modified. If I do dig -t AAAA example.net, then I must receive IPv6 answer if there is any.

Depends if we speak about VM, which has a kernel of its own. Then it has own setting of IPv6 disablement and should act appropriately. Containers sharing kernel with the host should have this setting shared with host I think. Sure, this autodetection may save few CPU bytes and network traffic. I would say it has low severity and is only nice to have feature.

SkipAAAAOnAFUnspec may help even on hosts just missing IPv6 route, but otherwise having local IPv6 connectivity working. If that is implemented, I think it still should default to yes if net.ipv6.conf.all.disable_ipv6=1. I would prefer ResolveIPv6OnUnspec=no variable name instead. If that is implemented, I think ResolveIPv4OnUnspec should be provided too.

[fuzzy7k]

I agree with pemensik, I have been searching for a way to turn off IPv6 responses to clients and gather that there is currently no way to do that.

See NM bug, https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1098
A couple of relevant issues here, in the case that the wwan connection provides no data, or metered data and resolved returns a AAAA record first, but the wlan connection only has routing for IPv4.
a) No Data, the client app tries to connect to the resource and routing is "successful", only it routes to a bit bucket.
b) Metered Data, since route metrics are not shared between IPv4/6, if the IPv6 address is tried first, it will be used no matter how much of a penalty the metered connection may have.

My hope was to patch NM to configure resolved correctly, in such a case that IPv6 is disabled in the manager. However, I would expect to be able to do that via resolvectl first.

As far as whether or not to initiate a AAAA query if IPv6 is disabled is a legitimate question. According to bug #19003, it matters if resolved is being used as a caching server that is serving clients with access to other networks. However, not all use cases are created equal and if we are on a mobile, saving CPU cycles and metered bandwidth from an extra query count.

It would be nice to have these features tunable so that a connection manager can set this up correctly depending on the use case or network configuration.

[pemensik]

There is a new not-yet documented option no-aaaa for resolv.conf, available since recent glibc. It seems to be backported even to RHEL 9. Check rhbz#2096191. I have requested something similar in rhbz#2182745, which should have something similar for IPv4 too. Implementing something similar on side of systemd-resolved would make sense too. As a daemon it can monitor availability of IPv6 connectivity much better than common userspace application.

[pemensik]

While #14125 has valid points, I think the main reason for its failures is wrong conditions used to test IPv6 availability.

It must not check default route only, but any route to non-link local addresses. Then it should work for any reasonable cases. Additionally only DNS protocol should be limited. Link local protocols (LLMNR or MDNS) and hosts db should still query AAAA records, because they can provide working link-local addresses even without any network infrastructure offering IPv6.

[pemensik]

I think the correct expectation would be to query AAAA records only if there were at least one not link-local route on whole system, excluding always present loopback addresses. Not related just to interface the server is received from, but on any other addresses. DNS server over IPv4 only VPN can provide me address to limited IPv6 connection on another interface. Similarly there is no reason to query A records on ipv6-only networks, if I have only 127.0.0.0/8 ipv4 route.

[yuwata]

See #28136 (comment).

[poettering]

Let's close this based on this comment:

#28136 (comment)