anycast.dns1.nextdns.io - error (anycast1)
https://nextdns.io/diag/f8d7a7c0-7a05-11eb-85b8-d5408bac8cf9
Olivier Poitrey The resolution issues are happening again. When this happens, dns on the network stops working, forcing me to have to switch to cloudflare off and on. This is happening intermittently.
I waited 5 min, and it was working again...
-
And it stops working again. I don't remember ever having as many stability issues using NextDNS as I have over the past few weeks. Are you doing something larger in the background that we are perhaps just experiencing teething issues with?
-
Hans Geiblinger no we don't have any stability issue. Nothing stands out in your diag, you have low latency access to many different PoPs. I'm not sure what is going on here. Did you try one of the official NextDNS clients?
-
-
I use dnsmasq+stubby on my openwrt router. I have tried your openwrt package, but in the past I never had success with it, as well, with it being written in GO it adds a tremendous size into my builds, so I just do it by hand.
-
Olivier Poitrey I had an issue again today, and I used your tool to run a diagnostic. However as soon as I hit Y for my email it closed, so I never got the link. Can you check to see if the error report arrived?
-
Olivier Poitrey here is the latest issue again today. If you don't have really anymore ideas, then I will have to quit NextDNS, this is really a daily, every other day occurrence. I really don't want to leave..... Back to cloud flare for the moment.
-
Hans Geiblinger please try again.
-
Olivier Poitrey , Understood, and usually after I wait some time, it works again. My issue, and was the reason I asked 2 weeks ago if there were any backend stability issues. At least to me, I see this type of temporary issue as frequent as a few times a week. While it may not take long to start working again, while the service is not responding, nothing on my network is responding either. Devices disconnect, everything stops resolving, and even if just for minutes it's extremely frustrating. Then I have to modify/restart stubby every time, it's quite frustrating.
Do you have any ideas why this happens? To me, it seems not reliable. I don't mean that in an offensive way, but a simple way of looking at it. When I temporarily switch back to cloudflare, I have 0 issues, but of course lose all the magic that NextDNS provides.
-
Hans Geiblinger Can you please tell me more about your setup? How did you setup nextdns?
-
Olivier Poitrey absolutely!!!
It's an OpenWrt installation using dnsmasq-full and stubby. Basic step-by-step setup is detailed here: https://github.com/openwrt/packages/blob/master/net/stubby/files/README.md
/etc/stubby/stubby.yml (I have NextDNS commented out at the moment, since I had to switch back to Cloudflare. Also I edited out my NextDNS ID for this post.):
# Note: by default on OpenWRT stubby configuration is handled via # the UCI system and the file /etc/config/stubby. If you want to # use this file to configure stubby, then set "option manual '1'" # in /etc/config/stubby. resolution_type: GETDNS_RESOLUTION_STUB #dnssec_return_status: GETDNS_EXTENSION_TRUE round_robin_upstreams: 0 appdata_dir: "/var/lib/stubby" tls_authentication: GETDNS_AUTHENTICATION_REQUIRED tls_query_padding_blocksize: 128 edns_client_subnet_private: 1 idle_timeout: 10000 listen_addresses: - 127.0.0.1@5453 - 0::1@5453 dns_transport_list: - GETDNS_TRANSPORT_TLS upstream_recursive_servers: # - address_data: 45.90.28.0 # tls_auth_name: "f7xxxx.dns1.nextdns.io" # - address_data: 45.90.30.0 # tls_auth_name: "f7xxxx.dns2.nextdns.io" - address_data: 1.1.1.2 tls_auth_name: "cloudflare-dns.com" - address_data: 1.0.0.2 tls_auth_name: "cloudflare-dns.com"/etc/config/dhcp (relevant section):
config dnsmasq option domainneeded '1' option localise_queries '1' option local '/lan/' option domain 'lan' option expandhosts '1' option authoritative '1' option readethers '1' option leasefile '/tmp/dhcp.leases' option localservice '1' option ednspacket_max '1232' list server '127.0.0.1#5453' option noresolv '1' option dnssec '1' option rebind_protection '0' config dhcp 'lan' option interface 'lan' option start '100' option limit '150' option leasetime '12h' config dhcp 'wan' option interface 'wan' option ignore '1' -
Hans Geiblinger please disable DNSSEC. It will create all sorts of issues with a DNS filter like us.
-
Olivier Poitrey Okay, thanks for the suggestion, I've disabled local DNSSEC and will test.
root@OpenWrt:~# cat /etc/stubby/stubby.yml # Note: by default on OpenWRT stubby configuration is handled via # the UCI system and the file /etc/config/stubby. If you want to # use this file to configure stubby, then set "option manual '1'" # in /etc/config/stubby. resolution_type: GETDNS_RESOLUTION_STUB round_robin_upstreams: 0 appdata_dir: "/var/lib/stubby" tls_authentication: GETDNS_AUTHENTICATION_REQUIRED tls_query_padding_blocksize: 128 edns_client_subnet_private: 1 idle_timeout: 10000 listen_addresses: - 127.0.0.1@5453 dns_transport_list: - GETDNS_TRANSPORT_TLS upstream_recursive_servers: - address_data: 45.90.28.0 tls_auth_name: "f7xxxx.dns1.nextdns.io" - address_data: 45.90.30.0 tls_auth_name: "f7xxxx.dns2.nextdns.io" # - address_data: 1.1.1.2 # tls_auth_name: "cloudflare-dns.com" # - address_data: 1.0.0.2 # tls_auth_name: "cloudflare-dns.com" root@OpenWrt:~# cat /etc/config/dhcp config dnsmasq option domainneeded '1' option localise_queries '1' option local '/lan/' option domain 'lan' option expandhosts '1' option authoritative '1' option readethers '1' option leasefile '/tmp/dhcp.leases' option localservice '1' option ednspacket_max '1232' list server '127.0.0.1#5453' option noresolv '1' option rebind_protection '0' option dnsseccheckunsigned '0'
-
