<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 1, 2024 at 6:57 AM 松藤 諒太 <<a href="mailto:r-matsufuji@intelligent-design.co.jp">r-matsufuji@intelligent-design.co.jp</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear contributers for systemd-resolved:<br>
<br>
Hello. I'm Ryota Matsufuji.<br>
<br>
Could I ask a question about the behavior of systemd-resolved?<br>
<br>
When being requested v4 and v6 address by application(such as wget with <br>
default option or firefox),<br>
depending on the interfaces' configuration, I watched multiple queries <br>
for both v4 and v6 address are launched through those interfaces.<br>
<br>
At this condition, I've found that systemd-resolved performed to return <br>
the result of those queries to application<br>
unless all queries are completed being resolved via one of multiple <br>
interfaces.<br>
<br>
I imagined that when A and AAAA record are received, disregarding any <br>
interface completed resolving queries through itself,<br>
resolved could return the result.<br>
(for instance, received A from eth0 and AAAA from eth1, and not received <br>
AAAA from eth0 and A from eth1)<br>
<br>
Actually, It seems not as above.<br>
<br>
If is there any reason or restriction that resolved should wait for <br>
completing all queries through one of interfaces to return the result,<br>
I'm afraid I would ask the question for why it is ?<br></blockquote><div><br></div><div>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.)<br></div><div><br></div><div>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.<br><div><br></div><div>(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.)</div>

<div><br></div></div><div>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.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Furthermore, does systemd provide the configuration to switch this <br>
behavior ?<br>
<br>
If so, could I get the information about the config option?<br></blockquote><div><br></div><div>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.<br></div></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div></div>