Well, that blog post offers a solution, I believe. I haven’t seen anything else that could do it.
Whilst this is obviously related to kresd it seems that unbound is doing it out of the box and not being constrained to 4 upstream resolver addresses
I believe the randomly-selecting code from that blog isn’t restricted to four addresses.
I would concur, but how many of those nested tables are permitted for kresd? If it is max 4 nested tables with max each 4 ip addresses per table it would inrease the limit to 16 ip addresses indeed. The way it is setup in the blog it is 8 ip addresses covering total of 2 dns-o-tls providers.
In unbound I got 6 dns-o-tls providers covered with a total of 9 ip(v4) addresses being randomized.
That blog shows custom code addressing a table – and tables in lua are basically unlimited. Four is the limit count for a table passed as-is in one FORWARD/STUB/FORWARD_TLS action (i.e. when choosing the fastest one).
Is it possible to create documentation based on this blog? As a supplement in the Knot documentation? Maybe even with these two DNS providers. This blog has irritated me a little bit, I did not understand it correctly.
Best regards
Yes, that’s been my plan instead of “truly implementing” it.
Going back to the “option dns” for the wan section in /etc/config/network, if this isn’t explicitly set, then I would assume that this is set for you from the DHCP settings provided by your ISP.
I was somewhat curious to see what kind of DNS requests were still going out over port 53 using tcpdump:
tcpdump -i eth1 udp port 53
I found the results quite a bit smaller than I might expect, but there still was some traffic.
I’m a little disappointed that the kresd script only looks at resolv.conf.auto and doesn’t seem to honor my asking that /etc/resolv.conf should be read instead as set in /etc/config/dhcp.
I’ll set my “option dns” to 127.0.0.1 and see what kind of havoc that creates, but I was curious to know what others have done in this case.
I enabled Cloudfare (TLS) as forwarder in Foris on my TO3.11.
I tested my DNS on these website.
https://1.1.1.1/help/
Both of them report Cloudfare as DNS, but they states that TLS is disabled.
Is TLS working properly?
The test (TLS) results are not correct, seems that the test is flawed, or even biased with the intention to convince visitors to utilize their service. For instance it claims for all DNS servers:
This DNS has compatibility issues that may break some sites.
Which is just some BS.
I believe it’s good, by looking at verbose-mode log. Cloudflare’s own detection is badly designed and breaks with any validating resolver, and they haven’t fix it yet – apparently because that’s “a bit of a corner case” – surely true, in terms of the number of users 
I think their problem could be worked around on our end by CF-specific configuration… but they should just use something that doesn’t need everyone else to add hacks.
I have no idea what the other site uses.
Thank you for confirm it is a testing problem, not a misconfiguration on my router
1 Like