Swistheater
Very Senior Member
note there is nothing more suspicious when cloudflare and your isp both have servers in your home town...
Not quite following old chap? I'm no fan of CF but they are a major player in shunting bits around the world. So I'm guessing you're saying that an ISP using CF to accelerate access is a bad thing?note there is nothing more suspicious when cloudflare and your isp both have servers in your home town...
I see a flaw in your "potential flexibility." Systems running in parallel provide great redunancy. However, the thrust of DoT/DNSSEC is security. DNSMASQ and Stubby should be in series especially if you are trying to do DNSSEC validation in Dnsmasq. In your scenario a DNS request could bypass Dnsmasq and go directly to Stubby. DNSSEC validation thwarted as well as the Dnsmasq cache.There's no reason to do so. Stubby listens to a loopback interface, so it won't clash with anything else. It's just an arbitrary port chosen between dnsmasq and Stubby. And as an added bonus, it means anything running locally on the router could also use Stubby as a resolver, so using port 53 only adds in potential flexibility.
And from a purist point of view, if you follow IANA's service port listing, port 53 is the proper port to use, since Stubby is receiving a DNS query fron dnsmasq. Port 853 is intended for receiving a TLS-secured DoT query - that is NOT what dnsmasq is sending Stubby at that time. So from a technical point of view, port 53 is the correct port to use here.
perhaps maybe @themiron could touch on this topic for clarification.I see a flaw in your "potential flexibility." Systems running in parallel provide great redunancy. However, the thrust of DoT/DNSSEC is security. DNSMASQ and Stubby should be in series especially if you are trying to do DNSSEC validation in Dnsmasq. In your scenario a DNS request could bypass Dnsmasq and go directly to Stubby. DNSSEC validation thwarted as well as the Dnsmasq cache.
I am writing this with 384.11 beta1 with DoT and DNSSEC enabled, Stubby listening on 127.0.0.1 port 5453 and Dnsmasq listening to server 127.0.0.1 port 5453. If my ISP had native IPV6 I would test with DNSMASQ and Stubby listening on 0::1#5453.
The Adguard TLS server is disappointingly very unreliable & slow from my location in New Zealand. (Unencrypted Adguard DNS is reasonably fast so I guess the problem lays with them)
Neustar/Neutopia the best for me.
no i just find it mildly suspicious, and makes you wonder what role your isp plays in that game.
In your scenario a DNS request could bypass Dnsmasq and go directly to Stubby.
I am writing this with 384.11 beta1 with DoT and DNSSEC enabled, Stubby listening on 127.0.0.1 port 5453 and Dnsmasq listening to server 127.0.0.1 port 5453. If my ISP had native IPV6 I would test with DNSMASQ and Stubby listening on 0::1#5453.
Are there any negative impacts from mixing different providers from the pre-select menu?
Should one pick only Cloudflare or only Q9 or only Google and their alternate?
Is mixing bad or can that lead to problems?
perhaps maybe @themiron could touch on this topic for clarification.
If you're looking for confirmation is your way to use it still ok - surely, it's pretty valid for your conditions, no worries. but nothing more than that.I am writing this with 384.11 beta1 with DoT and DNSSEC enabled, Stubby listening on 127.0.0.1 port 5453 and Dnsmasq listening to server 127.0.0.1 port 5453.
Sure, up to you but it would make zero sense.If my ISP had native IPV6 I would test with DNSMASQ and Stubby listening on 0::1#5453.
I am noticing with the routers stubby setup test that I am able to connect out via dns to ipv6 where as with stubby installer version I would always fail this.if you're looking for confirmation is your way to use it still ok - surely, it's pretty valid for your conditions, no worries. but nothing more than that.
sure, up to you but it would make zero sense.
dns protocol is transport-agnostic, you don't need to have ipv6 connection to get aaaa replies, and vice versa (ipv4/a.), so listening only on 127.0.1.1:53 does not harm. about redundancy - not the case, because both v4/v6 sockets will belong to the same app, on crash/broken upstreams you'll loose them all in the same time.
ipv4 loopback have 16777215 possible addresses, ipv6 loopback - only one ::1. so listening on *different* ipv4 address w/o port conflict is possible, on ipv6 loopback - is not.
I hope it should be clear now (taking into account multiple earlier explaining) that listening on ipv4-only loopback address is 1) valid 2) possible 3) required, listening on ipv6 - useless waste of ressources.
Regarding DNSSEC for router itself w/o using dnsmasq as caching resolver, yep, you're right, not DNSSEC magic will happen.
Taking into account all the cases of poorly signed vpn zones, and not signed ISP-local ressources it makes zero harm at the moment.
Anyway, for the future I hope getdns' DNSSEC support will be improved to have a way for split-DNSSEC disabled for dnsmasq and enabled for the rest local users.
not sure about...I am noticing with the routers stubby setup test that I am able to connect out via dns to ipv6 where as with stubby installer version I would always fail this.
Is kdig available for Entware and if it is can you name the package it's in please sir?not sure about...
installing dig/kdig from entware and making aaaa request to different endpoints would give some light on this, I guess.
examples:
dig aaaa google.com @127.0.0.1 # request dnsmasq
dig aaaa google.com @::1 # request dnsmasq
dig aaaa google.com @127.0.1.1 # request stubby
dig aaaa google.com @8.8.8.8 # request google
It would be nice to be able to run this command from a ssh terminal on the router running DoT. Cloudflare recommends this test.not sure about...
installing dig/kdig from entware and making aaaa request to different endpoints would give some light on this, I guess.
examples:
dig aaaa google.com @127.0.0.1 # request dnsmasq
dig aaaa google.com @::1 # request dnsmasq
dig aaaa google.com @127.0.1.1 # request stubby
dig aaaa google.com @8.8.8.8 # request google
kdig -d @1.1.1.1 +tls-ca +dnssec +tls-host=cloudflare-dns.com example.com
I got the above command from here: https://developers.cloudflare.com/1.1.1.1/dns-over-tls/It would be nice to be able to run this command from a ssh terminal on the router running DoT. Cloudflare recommends this test.Code:kdig -d @1.1.1.1 +tls-ca +dnssec +tls-host=cloudflare-dns.com example.com
not sure about...
installing dig/kdig from entware and making aaaa request to different endpoints would give some light on this, I guess.
examples:
dig aaaa google.com @127.0.0.1 # request dnsmasq
dig aaaa google.com @::1 # request dnsmasq
dig aaaa google.com @127.0.1.1 # request stubby
dig aaaa google.com @8.8.8.8 # request google
dig aaaa google.com @127.0.0.1
; <<>> DiG 9.12.3-P4 <<>> aaaa google.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61989
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1452
;; QUESTION SECTION:
;google.com. IN AAAA
;; ANSWER SECTION:
google.com. 259 IN AAAA 2607:f8b0:4008:803::200e
;; Query time: 35 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu May 02 16:03:54 UTC 2019
;; MSG SIZE rcvd: 77
; <<>> DiG 9.12.3-P4 <<>> aaaa google.com @::1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 680
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com. IN AAAA
;; ANSWER SECTION:
google.com. 245 IN AAAA 2607:f8b0:4008:803::200e
;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu May 02 16:04:08 UTC 2019
;; MSG SIZE rcvd: 67
dig aaaa google.com @127.0.1.1
; <<>> DiG 9.12.3-P4 <<>> aaaa google.com @127.0.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63829
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1452
;; QUESTION SECTION:
;google.com. IN AAAA
;; ANSWER SECTION:
google.com. 229 IN AAAA 2607:f8b0:4008:803::200e
;; Query time: 31 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Thu May 02 16:04:24 UTC 2019
;; MSG SIZE rcvd: 77
; <<>> DiG 9.12.3-P4 <<>> aaaa google.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26218
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com. IN AAAA
;; ANSWER SECTION:
google.com. 299 IN AAAA 2607:f8b0:4008:810::200e
;; Query time: 35 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu May 02 16:04:31 UTC 2019
;; MSG SIZE rcvd: 67
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!