Using dns over tls or https

If you create your own user account, you will be able to participate in community section.
Link to the registration page is here (in Czech) or here (in English)

I am registered there as “Jirka”, I edited some of created pages in history, but I just cant find create page (within public en/namespace) button or link…

Then perhaps edit https://doc.turris.cz/doc/en/public/dns_knot_misc ? It would seem a suitable place to me.

seems good, done. However, it doesnt propagate content of tricks (or type of tricks) to the main community page. Anyway, I would like to know how is it with rights anyway (for possible future purposes), but thats offtopic.

Perhaps one addition? I found I needed to install wget as the version within BusyBox wouldn’t allow download via https.

Didnt you have problem with certificates? Turris OS 3.9.6:

root@Doma:~# wget https://www.digicert.com/CACerts/DigiCertECCSecureServerCA.crt
--2018-05-20 14:02:55--  https://www.digicert.com/CACerts/DigiCertECCSecureServerCA.crt
Resolving www.digicert.com... 45.60.123.229
Connecting to www.digicert.com|45.60.123.229|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 944
Saving to: 'DigiCertECCSecureServerCA.crt'

DigiCertECCSecureServerCA.crt      100%[================================================================>]     944  --.-KB/s    in 0s

2018-05-20 14:02:56 (5.16 MB/s) - 'DigiCertECCSecureServerCA.crt' saved [944/944]

(and I am not aware touching wget/curl/etc on my Omnia)

Yes, wget was complaining about it not being a http or ftp address. Downloaded OK when I changed the address to http. Also fine through regular terminal via https.
My Omnia setup is quite vanilla and all the latest updates had been installed (Turris OS 3.10), wget package wasn’t installed previously.

Would anyone know how to randomize DNS (over TLS) resolver selection for the Omnia as done in the following article? https://www.ctrl.blog/entry/kresd-random-dns-forwarding

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 :roll_eyes: 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