<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
We would certainly take patches to accomplish something like this.
I'm not sure how easy it would be to work the internals of c-ares to
understand parallel nameservers for the same query, it would
probably be a substantial change though. <br>
<br>
Also, I'm also not sure how "friendly" it is to actually perform the
requests in parallel at all times. <br>
<br>
Infact, happyeyeballs itself doesn't always do parallel connection
attempts, its an implementation-defined delay before also attempting
the next address in the list. It also has you maintain a feedback
loop in order to sort known bad addresses to be least prefered. It
would be much easier to stay closer to happy eyeballs and just sort
the dns server list using prior result success/fail (even upfront
sorting using some algorithm to interleave ipv6/ipv4 in a pattern
would help, maybe with using logic such as from RFC6724 sec 2.1 like
we do in ares_getaddrinfo for returned addresses, but instead of the
nameservers themselves). <br>
<br>
Obviously, if you're using something that isn't maintaining state,
the feedback loop won't help, but maybe the pre-sorting suggestion
would. Assuming you're using libcurl, and not a stateless command
line curl, I think it would ultimately accomplish your goal.<br>
<br>
-Brad<br>
<br>
<div class="moz-cite-prefix">On 1/18/22 4:23 PM, Dmitry Karpov via
c-ares wrote:<br>
</div>
<blockquote type="cite"
cite="mid:BYAPR01MB5606F69336B7D6DE71C4B2E8C3589@BYAPR01MB5606.prod.exchangelabs.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}div.WordSection1
{page:WordSection1;}ol
{margin-bottom:0in;}ul
{margin-bottom:0in;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">Hello,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Using libcurl with c-ares for dual-stack
scenarios, I observed that c-ares doesn’t distinguish between
IPv4 and IPv6 nameservers in the name server list (i.e. listed
in resolv.conf on Linux systems) and iterates through them
sequentially.<br>
Such approach creates problems for dual-stack systems, when
one stack is either not fully functional or have not
responding/reachable name servers put on top of the list.
<br>
<br>
In such scenarios, problems with one stack (i.e. IPv6) may
create name resolution delays and timeouts for the other fully
functional stack (i.e. IPv4) if name servers from the not
functioning stack go before the good stack like:<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal">[IPv6 - BAD]<o:p></o:p></p>
<p class="MsoNormal">2001:4860:4860::8888<o:p></o:p></p>
<p class="MsoNormal">2001:4860:4860::8844<br>
[IPv4 - GOOD]<o:p></o:p></p>
<p class="MsoNormal">8.8.8.8<o:p></o:p></p>
<p class="MsoNormal">8.8.4.4<br>
<br>
In this scenario, it will take two resolution timeouts for bad
IPv6 name servers before good IPv4 name servers are reached,
and this negatively impacts Happy Eyeball implementations in
client applications (i.e. libcurl) which have to wait for too
long before they can start dual-stack connections.<br>
<br>
So here is the feature request which should help dual-stack
client applications to work more efficiently when name servers
from not functioning stack are listed before name servers from
a good stack:<o:p></o:p></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l0 level1 lfo1">Split the
flat name server list for both stacks into two lists for
each stack.<o:p></o:p></li>
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l0 level1 lfo1">Execute
parallel DNS queries for each stack list, iterating each
stack list sequentially as it is currently done for the
whole dual-stack list.<o:p></o:p></li>
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l0 level1 lfo1">Return the
result whichever comes first.<o:p></o:p></li>
</ul>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This feature request can be also considered
in a broader scope:<o:p></o:p></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l0 level1 lfo1">Run parallel
queries for each name server in the dual-stack list
regardless of whether it is IPv4 or IPv6 address.<o:p></o:p></li>
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l0 level1 lfo1">Return the
result whichever comes first.<o:p></o:p></li>
</ul>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Such broader scope will also allow to skip
over bad name servers and get host resolution results much
more quickly even for the same stack (i.e. when name server
list for a single stack contains some not responding name
servers at the top).<br>
But in this case, it should be probably controlled by some new
c-ares option, so the current sequential approach may be
enforced if needed.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks,<br>
Dmitry Karpov<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
</blockquote>
<br>
</body>
</html>