[systemd-devel] Question about the behavior of systemd (when requesting A/AAAA via multiple interfaces)

[Mantas Mikulėnas]

On Mon, Jul 1, 2024 at 6:57 AM 松藤 諒太 <r-matsufuji at intelligent-design.co.jp>
wrote:

> Dear contributers for systemd-resolved:
>
> Hello. I'm Ryota Matsufuji.
>
> Could I ask a question about the behavior of systemd-resolved?
>
> When being requested v4 and v6 address by application(such as wget with
> default option or firefox),
> depending on the interfaces' configuration, I watched multiple queries
> for both v4 and v6 address are launched through those interfaces.
>
> At this condition, I've found that systemd-resolved performed to return
> the result of those queries to application
> unless all queries are completed being resolved via one of multiple
> interfaces.
>
> I imagined that when A and AAAA record are received, disregarding any
> interface completed resolving queries through itself,
> resolved could return the result.
> (for instance, received A from eth0 and AAAA from eth1, and not received
> AAAA from eth0 and A from eth1)
>
> Actually, It seems not as above.
>
> If is there any reason or restriction that resolved should wait for
> completing all queries through one of interfaces to return the result,
> I'm afraid I would ask the question for why it is ?
>

Not 100% sure about this, but as far as I know, it's because
systemd-resolved deliberately tries to avoid mixing address information
from different sources, in order to support "split-view DNS" or
"split-horizon DNS" that is commonly used with corporate VPNs. (But the
logic is general and applied to all interfaces, not only to VPN interfaces;
see `scope` and `DnsScope` in the source code.)

For example, if you're connected through VPN to an IPv6-capable workplace
network, the same server might be seen as having an IPv4 NAT address
through public DNS (eth0) but direct IPv6 through internal DNS (vpn0), and
it would not be correct to merge the public A and internal AAAA records
with the same priority, because the former might have different firewall
restrictions than the latter, etc. – instead, *all of* vpn0:IPvX gets
priority over eth0:IPvX.

(The same also applies if different interfaces provide different records of
the same type; e.g. if both public DNS and internal DNS provide different A
records for the same server, you would still want to prioritize one answer
instead of merging both.)

So instead of handling each record type independently, the high-level
ResolveHostname() varlink call treats the [IPv4+IPv6] group of answers from
the same interface as an indivisible [IPvX] unit, which means it must wait
for both A and AAAA replies from eth0 in order to produce the full
eth0:[IPvX] answer.


> Furthermore, does systemd provide the configuration to switch this
> behavior ?
>
> If so, could I get the information about the config option?
>

I don't think there is an option to disable it if you are using the
'resolve' module in /etc/nsswitch.conf (which uses the high-level
ResolveHostname call), but I suspect that switching to the traditional
'dns' module (which makes low-level A/AAAA queries to 127.0.0.53) would
bypass this logic.

-- 
Mantas Mikulėnas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20240701/6a132100/attachment.htm>