<div dir="ltr"><div>Firstly, that is the way BIND works. If you are forwarding, it will try all forwarders, with a variable timeout (based on response time), plus retries and only when all of them fail will it fallback to iteration, assuming "forward first", the default.</div><div>However, a trick you might try is something like this. You may need to tweak it a bit for suitable local addresses and Dot configuration</div><div><br></div><div>...</div><div>view one {</div><div> forwarders port 853 tls vm-dot {<br></div><div> a:b:c::d;</div><div> 127.0.0.1;</div><div> }; </div><div>view two {</div><div> match-destinations {127.0.0.1;}</div><div>];</div><div>...</div><div><br></div><div>The idea is to give your Unbound forwarder a v6 address and use that (I'll explain why in a moment) and put that in the first view, which I have called "one" in this example. But also you include a second, new forwarder, for which I have used the IPv4 loopback address, matched in view "two".</div><div><br></div><div>This takes advantage of two features inherent in BIND:</div><div>- SRTT</div><div>- v6-bias</div><div><br></div><div>SRTT is a cost value associated with every address, calculated from its measured response time. BIND will always send queries to the address with the lowest SRTT. If there is only one address, then it's not relevant, except for calculating how long to wait when retrying. But with two addresses (as in view "one"), both become equally eligible, except for the second feature.</div><div><br></div><div>v6-bias (default 50ms) gives v6 addresses preference - a head start - over v4 addresses, hence as long as your Unbound VM responds promptly the v6 address will always have the lowest SRTT and so the v4 address won't be used as it is penalised.</div><div><br></div><div>But if Unbound stops responding its SRTT will climb rapidly, the v4 address will suddenly be favourite and queries are forwarded to view "two". In this view you can do nothing, so it will iterate. Or you could do anything else you like.</div><div><br></div><div>In view "one" you may need to include the "v6-bias" statement to tune the value for a balance between stability and agility.</div><div><br></div><div><div>That's the theory anyway. Please try it and let us know if it works for you.</div><div>Cheers, Greg</div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sun, 3 May 2026 at 19:52, pgnd <<a href="mailto:pgnd@dev-mail.net">pgnd@dev-mail.net</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">i'm doing some comparative performance checking for Bind9 DoT forwarding from my local bind 9.21.21<br>
<br>
for config<br>
<br>
...<br>
tls vm-dot { remote-hostname "<a href="http://example.com" rel="noreferrer" target="_blank">example.com</a>"; };<br>
tls quad9-dot { remote-hostname "<a href="http://dns.quad9.net" rel="noreferrer" target="_blank">dns.quad9.net</a>"; };<br>
tls cloudflare-dot { remote-hostname "one.one.one.one"; };<br>
tls google-dot { remote-hostname "<a href="http://dns.google" rel="noreferrer" target="_blank">dns.google</a>"; };<br>
...<br>
forward first;<br>
...<br>
<br>
with fwd from my local Bind9 instance to my VM unbound instance<br>
<br>
forwarders port 853 tls vm-dot {<br>
10.10.10.53;<br>
};<br>
<br>
all's good; dns leak test from local browsers shows my VM as IP source for the DNS queries<br>
<br>
similarly, with Cloudflare<br>
<br>
forwarders port 853 tls cloudflare-dot {<br>
1.1.1.2;<br>
1.0.0.2;<br>
2606:4700:4700::1112;<br>
2606:4700:4700::1002;<br>
};<br>
<br>
also works, and shows CF IPs as source.<br>
<br>
same with Google.<br>
<br>
but, with Quad9,<br>
<br>
forwarders port 853 tls quad9-dot {<br>
9.9.9.9;<br>
149.112.112.112;<br>
2620:fe::fe;<br>
2620:fe::9;<br>
};<br>
<br>
seems NO forwarding; dnsleak test shows Comcast & WoodyNet IPs :-/<br>
which is annoying.<br>
<br>
looking for errors -- not finding them, yet. or a published reason/bug re: Bind9 forwarding 'vs' Quad9 DoT.<br>
<br>
still digging, but ...<br>
<br>
... any _known_ issues with Quad9?<br>
<br>
-- <br>
Visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list.<br>
</blockquote></div>