BIND9 9.21.21 DoT Forwarding Fails with Quad9 (9.9.9.9 etc) ; Cloudflare/Google/own unbound work OK

[Greg Choules]

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.
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

...
view one {
   forwarders port 853 tls vm-dot {
        a:b:c::d;
        127.0.0.1;
   };
view two {
   match-destinations {127.0.0.1;}
];
...

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".

This takes advantage of two features inherent in BIND:
- SRTT
- v6-bias

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.

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.

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.

In view "one" you may need to include the "v6-bias" statement to tune the
value for a balance between stability and agility.

That's the theory anyway. Please try it and let us know if it works for you.
Cheers, Greg


On Sun, 3 May 2026 at 19:52, pgnd <pgnd at dev-mail.net> wrote:

> i'm doing some comparative performance checking for Bind9 DoT forwarding
> from my local bind 9.21.21
>
> for config
>
>         ...
>         tls vm-dot         { remote-hostname "example.com"; };
>         tls quad9-dot      { remote-hostname "dns.quad9.net"; };
>         tls cloudflare-dot { remote-hostname "one.one.one.one"; };
>         tls google-dot     { remote-hostname "dns.google"; };
>         ...
>         forward first;
>         ...
>
> with fwd from my local Bind9 instance to my VM unbound instance
>
>         forwarders port 853 tls vm-dot {
>                 10.10.10.53;
>         };
>
> all's good; dns leak test from local browsers shows my VM as IP source for
> the DNS queries
>
> similarly, with Cloudflare
>
>         forwarders port 853 tls cloudflare-dot {
>                 1.1.1.2;
>                 1.0.0.2;
>                 2606:4700:4700::1112;
>                 2606:4700:4700::1002;
>         };
>
> also works, and shows CF IPs as source.
>
> same with Google.
>
> but, with Quad9,
>
>         forwarders port 853 tls quad9-dot {
>                 9.9.9.9;
>                 149.112.112.112;
>                 2620:fe::fe;
>                 2620:fe::9;
>         };
>
> seems NO forwarding; dnsleak test shows Comcast & WoodyNet IPs :-/
> which is annoying.
>
> looking for errors -- not finding them, yet.  or a published reason/bug
> re: Bind9 forwarding 'vs' Quad9 DoT.
>
> still digging, but ...
>
>         ... any _known_ issues with Quad9?
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20260503/2120006e/attachment.htm>