[dns]: queries might fail for VPNs that leverage virtual interfaces with packet filtering

[legomushroom]

DNS queries for local machine with VPNs that create virtual network interfaces with network packet filtering fail with NXDOMAIN responses. Such VPN setup has a common pattern:

1. The VPN client modifies the /etc/resolv.conf by adding users' default (local) gateway as a nameserver, for instance:

search legomushroom.github.com.hello.net hello.net service.reducted.hello.net lan
nameserver 192.168.86.1

2. They setup a linklocal virtual TUN network interface and set it as a default gateway in the routing table:

Destination        Gateway            Flags           Netif Expire
default            192.168.86.1       UGScg             en0            
default            link#24            UCSIg           utun8
100.100.100.100/32 link#24            UCS             utun8       
100.100.100.100    link#24            UHWIi           utun8       
100.103.31.91      100.103.31.91      UH              utun8       
100.104.250.112/32 link#24            UCS             utun8       
100.123.212.62/32  link#24            UCS             utun8    

3. They setup network packet filters to filter out VPN-related traffic so it never reaches the real default gateway interface.

This setup fails for DNS resolvers that use the specified DNS server directly and do not perform getaddrinfo(3) sys call to resolve the address. Hence even common tools like dig, host or nslookup fail in this case.

Expected behavior

DNS queries work as expected.

Desktop:

• OS: Mac OSx 12.3.1 Monterey
• Intel chip

Known VPN clients affected:

• Tailscale
• Viscosity

Temporary Workarounds:

• Either add ip hostname mapping to /etc/hosts inside Codespace:

100.100.1.127 sub.legomushroom.github.com.hello.net

• Or add additional nameserver to the /etc/resolv.conf (just after the nameserver 127.0.0.53 one):

nameserver 100.100.100.100
options timeout:10 attempts:5

cc @chrisbloom7