I think it was a transient error, login.comcast.net does not return SERVFAIL anymore.
Yes, it looks like it works again. I think there have been other reports. Asus Merlin based release also mentions in the changelog that there are some issues with dnssec and cf on this path. (https://www.snbforums.com/threads/fork-asuswrt-merlin-374-43-lts-releases-v34e3.18914/)
I got stubby working yesterday on Asuswrt-Merlin 384.7 Beta 1. See my adventures to date on snbforums.com. entware did not create the /etc/init.d/stubby file. I am starting stubby using the command
stubby -g -v 5 -C /opt/etc/stubby/stubby.yml 2>/opt/var/log/stubby.log
This morning, stubby was not running. I restarted using the command above. I would like to create the equivalent /etc/init.d/stubby file in the /opt/etc/init.d/ folder on Asuswrt-Merlin so stubby starts and runs like the other packages I have installed. Can you please post the contents of /etc/init.d/stubby so I can use it as a starting point to create my own version on Asuswrt-Merlin? Thank you in advance for your help.
Update: This is working for me:
#!/bin/sh
ENABLED=yes
PROCS=stubby
ARGS="-g -v 5 -C /opt/etc/stubby/stubby.yml 2>/opt/var/log/stubby.log"
PREARGS="nohup"
DESC=$PROCS
PATH=/opt/sbin:/opt/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
. /opt/etc/init.d/rc.func
Hello, I followed this tutorial and successfully use DNS over TLS with three custom DNS servers that I configured inside my /etc/stubby/stubby.yml file.
My guess was, that the first listed DNS server is used as long it is available and that the second and third are only used, when the first DNS is unavailable. In my case it looks different, since my first listed DNS is only used for a few houts after a reboot of my OpenWRT 18.06.1 router. When it's uptime is more than 12 hours, my second listed DNS server is used. Since then, it won't use the first listed DNS anymore (securedns.eu was available all the time). Is this the normal behavior?
Could someone please tell me how to correctly configure the DNS server order for Stubby? I want my first DNS server (securedns.eu) to be used all the time and only change to second DNS when the first is unavailable.
This is how my stubby.yml looks, everything else matches the first post configuration (permanent installation):
stubby.yml:
resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
- GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 128
edns_client_subnet_private : 1
round_robin_upstreams: 0
idle_timeout: 10000
listen_addresses:
- 127.0.0.1@5453
- 0::1@5453
upstream_recursive_servers:
# The securedns.eu Server
- address_data: 146.185.167.43
tls_auth_name: "dot.securedns.eu"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: h3mufC43MEqRD6uE4lz6gAgULZ5/riqH/E+U+jE3H8g=
# The UncensoredDNS Server
- address_data: 89.233.43.71
tls_auth_name: "unicast.censurfridns.dk"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: wikE3jYAA6jQmXYTr/rbHeEPmC78dQwZbQp6WdrseEs=
# The Fondation RESTENA Server
- address_data: 158.64.1.29
tls_auth_name: "kaitain.restena.lu"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: 7ftvIkA+UeN/ktVkovd/7rPZ6mbkhVI7/8HnFJIiLa4=
Yes, for a round_robin value of '0' that is the expected behaviour, it will use the first that works until it fails then moves to the next until it fails, etc.(failing in this context might just be exceeding the timeout one time, noting serious, happens all the time, probably what happened after 12 hours).
For a value of '1' it would always change server, neither values can reproduce the specific behaviour you are looking for.
Securedns probably has a secondary IP address, you should use that as your 2nd server and remove all the others, this way it will always use Securedns.
1 Like
Hello, thanks for your reply.
Sadly securedns.eu doesn't offer a second DNS server. I configured three servers since I need a fallback.
Isn't the behavior I'm facing an issue of the configuration or Stubby? Why should the second DNS be used, when the first is available? Is a configuration change needed at dnsmasq.conf?
It would be nice if someone could reverse engineer the issue with me.
Best regards
No.
The behaviour you want is not possible in the configuration of stubby or dnsmasq. What you want is to set a preferred server, there is no such option, only an order of sequence or load balancing.
https://dnsprivacy.org/wiki/display/DP/Configuring+Stubby
round_robin_upstreams: Round robin queries across all the configured upstream servers. Without this option Stubby will use each upstream server sequentially until it becomes unavailable and then move on to use the next.
"Until it becaomes unavailable and then moves to the next": this is exactly what happened.
So securedns.eu was down between the time frame of the reboot of my router and the time I've seen that the DNS changed? This happened two times in a row, I did a reboot of my router when I recognized this first time.
When the first DNS is unvailable and changes, it will stay with the second DNS until it also goes down and moves to the third, and so on?
Thanks for the interesting insights.
Unlikely it was down, more likely a timeout, or it couldn't authenticate the server yet, since it was after reboot, maybe the internet connection wasn't up yet when stubby started, for instance.
Yes, this is exactly the intended behaviour.
nslookup aljazeera.com gives SERVFAIL. Reported in this thread:https://www.reddit.com/r/openwrt/comments/9fht0n/dnssec_being_done_but_by_what/. I am able to reproduce it. Others seeing it too ?
Yes, SERFAIL here on aljazeera with cloudfalre.
After reading this tutorial and the one directnupe provides I still have some questions though...
I have a Dir-860L-B1 router and there's some 10MB free memory to install.
- How can I monitor the size of the dns cache?
- How can I see the health of the installed certificates?
- If there's no internet after applying all these steps how can one revert to a working situation without flashing the stock again.
- can I use other dns providers than cloudfare
- is there a way to get an email that a jump in DNS provider took place so that I know that I'm at the end of the list.
- directnupe talks in step 14 about the spki, I guess he's warning that certificates can become invalid and needs to be checked from time to time
- Is your ram solution a good way to have always the latest certificates abroad or are we talking about other certificates?
- When all steps followed in your ram solution isn't that also a permanent solution. Will I still use stubby after a powerfailure or reboot?
Kind regards
GuyF
1 - killall -s USR1 dnsmasq && logread | grep dnsmasq | tail
2 - lol
3 - Script it
4 - Yes, if you read the guides you know this
5 - lol, script it
6 - I have no idea what step 14 is, I'm not going to jump back and forth and due all the work for you, but this guide does not need that you read his guide.
7 - The RAM solution is unrelated to certificates, it's because of limited flash storage, but that is explained here.
8 - Yes, because of the startup script.
My guide assumes some Linux knowledge (scripting), I'm sorry. I'm not available to make it more novice friendly, for various reasons, first lack of time and patience, but also because stubby is still experimental so if you are going to go this route you should know what you're doing and how to get yourself out if it messes up.
I set this but but how do I determine if this works? I use 1.0.0.1/help and it shows dns over tls/https as no. My connection is routing all dns entries and even 1.1.1.1 is blocked. I did setup to route to 1.0.0.1 only in stubby.yml
It is a known issue of Cloudflare's /help to not recognize it's own dns-over-tls.
Like I say in the initial post you can use http://www.dnsleaktest.com/ to deternine if it's using Cloudflare (the ISP name should appear as Cloudflare).
I should have mentioned I tried dnsleaktest as well and it does not seem to be able to working. If I set it to no-resolv I get no internet connection.
1.0.0.1/help does give somewhat weird results. If I use firefox the ipv6 is reachable. If go to chrome/opera/internet explorer the ipv6 is notreachable.
I don't know what this means, are you saying the ISP does not appear as Cloudflare?
Also in the 1.1.1.1/help, the AS Name should appear as Cloudflare if the DNS resolution is being made through Cloudflare, it's what appears in my case.
ISP does not appear as Cloudflare for me. Thanks for your work however.
That means your router is not using Cloudflare for resolving.
It's quite hard for me to troubleshoot your problem except to say that you probably missed something in my instructions.