NetworkManager + unbound: do not resolve AAAA records for VPNs with no v6 connectivity
Let's suppose a scenario:
-
base connection supports dual-stack networking so we have default v6 route (
::/0 via some_v6_ip
) -
we have active VPN connection that supports just v4 connection:
12: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1360 qdisc fq_codel state UNKNOWN group default qlen 100 link/none inet 10.40.204.50/22 brd 10.40.207.255 scope global noprefixroute tun0 valid_lft forever preferred_lft forever inet6 fe80::ec73:db80:bca8:a09a/64 scope link stable-privacy valid_lft forever preferred_lft forever
-
DNS is handled by unbound (+ dnssec-trigger) locally, allowing to check VPN's ‘Use DNS server only for resources in this network’
-
the DNS server for VPN connection returns both A and AAAA records
What happens then is that apps such as ssh
time out. The reason is that when app wants to connect to some host in VPN, the AAAA record takes priority, app (or more precisely libc) sees nothing wrong as the v6 host fits in default route ‒ but as it's firewalled from general internet and reachable only over VPN that doesn't provide v6 connectivity, the connection attempt times out (after quite long time when app or user gives up).
A clean solution would be to tell unbound
when adding forwarding record that responses for this zone should filter out v6 results (the same would go for v4 results for v6-only VPN hosted also on dual-stack generic connection). I didn't find how to do that with unbound-control forward_add
so if it's not possible using API, I'll write a bug there as well.
OS: Fedora 31
Packages:
- NetworkManager-1.20.4-1.fc31.x86_64
- NetworkManager-openvpn-1.8.10-1.fc31.1.x86_64
- unbound-1.9.3-2.fc31.x86_64