[Beta] Asuswrt-Merlin 384.11 Beta is now available

[Swistheater]

note there is nothing more suspicious when cloudflare and your isp both have servers in your home town...

 

[chris2kari]

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?

 

[Swistheater]

no i just find it mildly suspicious, and makes you wonder what role your isp plays in that game.

 

[#TY]

CloudFlare in my experience so far has been nothing but a solid performer. I would trust them over my ISP any day. I'm also looking forward to their WarpVPN service. I wonder what innovation (if any) they will bring to the table.

 

[bbunge]

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.

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.

 

[Swistheater]

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.

perhaps maybe @themiron could touch on this topic for clarification.

 

[RMerlin]

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)

It was removed from the presets anyway, replaced by CleanBrowsing.

Neustar/Neutopia the best for me.

Note that these are officially "test servers", tho Stubby enables them by default. However there are no official "non-test" servers for port 443. I wanted at least one such option available, so I picked that one.

 

[RMerlin]

no i just find it mildly suspicious, and makes you wonder what role your isp plays in that game.

Cloudflare is a global CDN provider, so they have POPs all over the world. It's part of why their performance is generally so good.

https://www.cloudflare.com/network/

 

[RMerlin]

In your scenario a DNS request could bypass Dnsmasq and go directly to Stubby.

Only if you specify the proper IP address. Note that we use 127.0.1.1, NOT 127.0.0.1. To use it you have to explicitly provide that IP address, and it must also be done on the router itself. It't not something that can happen automatically.

And there are cases where you might need to do that. One potential example: when relying on DNS queries to test for online connectivity, and you need to bypass the dnsmasq cache.

The current design decisions were made for technical (and standard-compliance) reasons. You haven't provided me with one single technical reason why this was the wrong decision, just your personal preferences.

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.

You're free to reconfigure things as you want to. Just be warned that it might eventually create issues if further portions of the firmware are going to be tied to this design decision in the future.

 

[John Fitzgerald]

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?

 

[RMerlin]

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?

They might provide different answers. Not a big deal, except it might be confusing if a known-malicious site sometimes get blocked (when resolved by Quad9), and sometimes it doesn't (when resolved by Google).

 

[RMerlin]

perhaps maybe @themiron could touch on this topic for clarification.

Pretty much what I already said. And he already has a few scenarios in mind where being able to directly resolve through Stubby might be desirable. One scenario he mentioned is if your router didn't get any DNS server from your ISP yet. The current design would allow the router to use Stubby as a standard resolver, as it can be directly inserted into resolv.conf.

 

[themiron]

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 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.

If my ISP had native IPV6 I would test with DNSMASQ and Stubby listening on 0::1#5453.

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 additional ipv4-only loopback address and 53 port is 1) valid 2) possible 3) required, listening on ipv6 - 1) useless waste of ressources 2) impossible w/o port conflicts.

Regarding DNSSEC for router itself w/o using dnsmasq as caching resolver, yep, you're right, no DNSSEC magic will happen. But taking into account all the cases of poorly signed vpn zones and not signed ISP-local resources, it makes zero harm at the moment.
Anyway, for the future I hope getdns' DNSSEC support will be improved in a way to have split-DNSSEC disabled for dnsmasq and enabled for the rest router-local users.

 

[Swistheater]

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.

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.

 

[themiron]

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.

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

 

[skeal]

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

Is kdig available for Entware and if it is can you name the package it's in please sir?

 

[Swistheater]

dig -6 www.google.com

 

[skeal]

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.

kdig -d @1.1.1.1 +tls-ca +dnssec +tls-host=cloudflare-dns.com  example.com

 

[skeal]

It would be nice to be able to run this command from a ssh terminal on the router running DoT. Cloudflare recommends this test.

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/

 

[Swistheater]

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