Menu
What's new
By:
Filters Better Search

[Beta] Asuswrt-Merlin 384.11 Beta is now available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

RMerlin said:
On the other hand, lack of EDNS support means Cloudflare can potentially degrade your overall network performance by pointing you at non-optimal CDN servers.

It's one of the reasons why, personally, after I'm done implementing and testing DoT, I intend to disable it, and go back to my ISP DNS.
Click to expand...
I have yet to experience this issue but once I do , I am sure I will be looking else where for dns resolver
 
EmeraldDeer said:
Perhaps things have improved since I was testing a few months back, but neither CleanBrowsing or Quad9 DNS over TLS were reliable, only Cloudflare.

Also the server side timeouts of CleanBrowsing and Quad9 were 2 seconds as opposed to Cloudflare's 10 seconds, so you need the following in stubby.yml:
Code: 
idle_timeout: 1900
If you neglect to do this and have nvram stubby_debug set, you will see incrementing Conn_shuts. Here are normal results:
Code: 
=================================================================================================================================================================
[00:55:01.541371] STUBBY: 1.1.1.1                                  : Verify passed : TLS
[00:55:11.518171] STUBBY: 1.1.1.1                                  : Conn closed: TLS - Resps=     1, Timeouts  =     0, Curr_auth =Success, Keepalive(ms)=  9900
[00:55:11.518224] STUBBY: 1.1.1.1                                  : Upstream   : TLS - Resps=  1236, Timeouts  =     0, Best_auth =Success
[00:55:11.518246] STUBBY: 1.1.1.1                                  : Upstream   : TLS - Conns=   444, Conn_fails=     0, Conn_shuts=      2, Backoffs     =     0
=================================================================================================================================================================
[00:56:01.713815] STUBBY: 1.0.0.1                                  : Verify passed : TLS
[00:56:11.695165] STUBBY: 1.0.0.1                                  : Conn closed: TLS - Resps=     1, Timeouts  =     0, Curr_auth =Success, Keepalive(ms)=  9900
[00:56:11.695213] STUBBY: 1.0.0.1                                  : Upstream   : TLS - Resps=  1236, Timeouts  =     0, Best_auth =Success
[00:56:11.695245] STUBBY: 1.0.0.1                                  : Upstream   : TLS - Conns=   444, Conn_fails=     0, Conn_shuts=      2, Backoffs     =     0
=================================================================================================================================================================
[00:56:14.756647] STUBBY: 2606:4700:4700::1111                     : Verify passed : TLS
[00:56:24.728211] STUBBY: 2606:4700:4700::1111                     : Conn closed: TLS - Resps=     1, Timeouts  =     0, Curr_auth =Success, Keepalive(ms)=  9900
[00:56:24.728260] STUBBY: 2606:4700:4700::1111                     : Upstream   : TLS - Resps=  1235, Timeouts  =     1, Best_auth =Success
[00:56:24.728281] STUBBY: 2606:4700:4700::1111                     : Upstream   : TLS - Conns=   441, Conn_fails=     0, Conn_shuts=      2, Backoffs     =     0
=================================================================================================================================================================
[00:56:14.795690] STUBBY: 2606:4700:4700::1001                     : Verify passed : TLS
[00:56:24.757123] STUBBY: 2606:4700:4700::1001                     : Conn closed: TLS - Resps=     1, Timeouts  =     0, Curr_auth =Success, Keepalive(ms)=  9900
[00:56:24.757168] STUBBY: 2606:4700:4700::1001                     : Upstream   : TLS - Resps=  1236, Timeouts  =     0, Best_auth =Success
[00:56:24.757187] STUBBY: 2606:4700:4700::1001                     : Upstream   : TLS - Conns=   442, Conn_fails=     0, Conn_shuts=      2, Backoffs     =     0
=================================================================================================================================================================
Click to expand...
Same here. I had dropouts with CB, Q9 wouldn't pass any DoT test, only CF works well accross the board here.
 
EmeraldDeer said:
Perhaps things have improved since I was testing a few months back, but neither CleanBrowsing or Quad9 DNS over TLS were reliable, only Cloudflare.

Also the server side timeouts of CleanBrowsing and Quad9 were 2 seconds as opposed to Cloudflare's 10 seconds, so you need the following in stubby.yml:
Code: 
idle_timeout: 1900
If you neglect to do this and have nvram stubby_debug set, you will see incrementing Conn_shuts. Here are normal results:
Code: 
=================================================================================================================================================================
[00:55:01.541371] STUBBY: 1.1.1.1                                  : Verify passed : TLS
[00:55:11.518171] STUBBY: 1.1.1.1                                  : Conn closed: TLS - Resps=     1, Timeouts  =     0, Curr_auth =Success, Keepalive(ms)=  9900
[00:55:11.518224] STUBBY: 1.1.1.1                                  : Upstream   : TLS - Resps=  1236, Timeouts  =     0, Best_auth =Success
[00:55:11.518246] STUBBY: 1.1.1.1                                  : Upstream   : TLS - Conns=   444, Conn_fails=     0, Conn_shuts=      2, Backoffs     =     0
=================================================================================================================================================================
[00:56:01.713815] STUBBY: 1.0.0.1                                  : Verify passed : TLS
[00:56:11.695165] STUBBY: 1.0.0.1                                  : Conn closed: TLS - Resps=     1, Timeouts  =     0, Curr_auth =Success, Keepalive(ms)=  9900
[00:56:11.695213] STUBBY: 1.0.0.1                                  : Upstream   : TLS - Resps=  1236, Timeouts  =     0, Best_auth =Success
[00:56:11.695245] STUBBY: 1.0.0.1                                  : Upstream   : TLS - Conns=   444, Conn_fails=     0, Conn_shuts=      2, Backoffs     =     0
=================================================================================================================================================================
[00:56:14.756647] STUBBY: 2606:4700:4700::1111                     : Verify passed : TLS
[00:56:24.728211] STUBBY: 2606:4700:4700::1111                     : Conn closed: TLS - Resps=     1, Timeouts  =     0, Curr_auth =Success, Keepalive(ms)=  9900
[00:56:24.728260] STUBBY: 2606:4700:4700::1111                     : Upstream   : TLS - Resps=  1235, Timeouts  =     1, Best_auth =Success
[00:56:24.728281] STUBBY: 2606:4700:4700::1111                     : Upstream   : TLS - Conns=   441, Conn_fails=     0, Conn_shuts=      2, Backoffs     =     0
=================================================================================================================================================================
[00:56:14.795690] STUBBY: 2606:4700:4700::1001                     : Verify passed : TLS
[00:56:24.757123] STUBBY: 2606:4700:4700::1001                     : Conn closed: TLS - Resps=     1, Timeouts  =     0, Curr_auth =Success, Keepalive(ms)=  9900
[00:56:24.757168] STUBBY: 2606:4700:4700::1001                     : Upstream   : TLS - Resps=  1236, Timeouts  =     0, Best_auth =Success
[00:56:24.757187] STUBBY: 2606:4700:4700::1001                     : Upstream   : TLS - Conns=   442, Conn_fails=     0, Conn_shuts=      2, Backoffs     =     0
=================================================================================================================================================================
Click to expand...

what do you have in your config file for optimal setup with cloudflare?
 
Can anyone with IPv6 support confirm that the IPv6 Quad9 servers also work properly with DoT?

2620:fe::fe
2620:fe::9
 
Gar said:
Same here. I had dropouts with CB, Q9 wouldn't pass any DoT test, only CF works well accross the board here.
Click to expand...

A DoT test has to be specifically tailored for a specific server. The CF test will only work properly with the CF DoT servers.
 
Swistheater said:
I have yet to experience this issue but once I do , I am sure I will be looking else where for dns resolver
Click to expand...

Lack of EDNS support by CF was intentional, for privacy reasons.

Check how's your Akamai routing for example. Maybe just being pointed at a local CF cache might already provide localized enough information to no tend up using an Akamai server at the other end of the country.
 
RMerlin said:
Can anyone with IPv6 support confirm that the IPv6 Quad9 servers also work properly with DoT?

2620:fe::fe
2620:fe::9
Click to expand...

I have checked them they do work. I can add them real quick and show you the stubby -l if you like
 
EmeraldDeer said:
Perhaps things have improved since I was testing a few months back, but neither CleanBrowsing or Quad9 DNS over TLS were reliable, only Cloudflare.

Also the server side timeouts of CleanBrowsing and Quad9 were 2 seconds as opposed to Cloudflare's 10 seconds, so you need the following in stubby.yml:
Code: 
idle_timeout: 1900
If you neglect to do this and have nvram stubby_debug set, you will see incrementing Conn_shuts.
Click to expand...
Boy, this does conjure memories of the growing pains with Stubby on John's fork. The conn_shuts are certainly undesirable and it's supposed to be better to let Stubby timeout the connection instead of the remote server. There's an open issue for stubby on github concerning this.

I can see this becoming a support issue going forward, depending on how many preset servers have timeouts less than 9000 ms.
 
Swistheater said:
I have checked them they do work. I can add them real quick and show you the stubby -l if you like
Click to expand...

No need to, thanks. Will add them to the presets.

This is what the updated preset list looks like now:

Code: 
# Layout:
# Name,IP_Address,Port,TLS_Hostname,SPKI
# Single entry = group label
# Empty lines are ignored

IPv4
CleanBrowsing 1 (security),185.228.168.9,,security-filter-dns.cleanbrowsing.org,
CleanBrowsing 2 (security),185.228.169.9,,security-filter-dns.cleanbrowsing.org,
CleanBrowsing 1 (family),185.228.168.168,,family-filter-dns.cleanbrowsing.org,
CleanBrowsing 2 (family),185.228.168.168,,family-filter-dns.cleanbrowsing.org,
CleanBrowsing 1 (adult filter),185.228.168.10,,adult-filter-dns.cleanbrowsing.org,
CleanBrowsing 2 (adult filter),185.228.169.10,,adult-filter-dns.cleanbrowsing.org,
Cloudflare 1.1.1.1,1.1.1.1,,cloudflare-dns.com,
Cloudflare 1.0.0.1,1.0.0.1,,cloudflare-dns.com,
Google 8.8.8.8,8.8.8.8,,dns.google,
Google 8.8.4.4,8.8.4.4,,dns.google,
Quad9 (secure),9.9.9.9,,dns.quad9.net,
Quad9 (insecure),9.9.9.10,,dns.quad9.net,

IPv4 (port 443)
Neutopia,89.234.186.112,443,dns.neutopia.org,wTeXHM8aczvhRSi0cv2qOXkXInoDU+2C+M8MpRyT3OI=
Surfnet/Sinodun 1,145.100.185.15,443,dnsovertls.sinodun.com,62lKu9HsDVbyiPenApnc4sfmSYTHOVfFgL3pyB+cBL4=
Surfnet/Sinodun 2,145.100.185.16,443,dnsovertls1.sinodun.com,cE2ecALeE5B+urJhDrJlVFmf38cJLAvqekONvjvpqUA=

IPv6
CleanBrowsing 1 (security),2a0d:2a00:1::2,,security-filter-dns.cleanbrowsing.org,
CleanBrowsing 2 (security),2a0d:2a00:2::2,,security-filter-dns.cleanbrowsing.org,
CleanBrowsing 1 (family),2a0d:2a00:1::,,family-filter-dns.cleanbrowsing.org,
CleanBrowsing 2 (family),2a0d:2a00:2::,,family-filter-dns.cleanbrowsing.org,
CleanBrowsing 1 (adult filter),2a0d:2a00:1::1,,adult-filter-dns.cleanbrowsing.org,
CleanBrowsing 2 (adult filter),2a0d:2a00:2::1,,adult-filter-dns.cleanbrowsing.org,
Cloudflare :1111,2606:4700:4700::1111,,cloudflare-dns.com,
Cloudflare :1001,2606:4700:4700::1001,,cloudflare-dns.com,
Google :8888,2001:4860:4860::8888,,dns.google,
Google :8844,2001:4860:4860::8844,,dns.google,
Quad9 (secure),2620:fe::fe,,dns.quad9.net,
Quad9 (insecure),2620:fe::10,,dns.quad9.net,

IPv6 (port 443)
Neutopia,2a00:5884:8209::2,443,dns.neutopia.org,wTeXHM8aczvhRSi0cv2qOXkXInoDU+2C+M8MpRyT3OI=
Surfnet/Sinodun 1,2001:610:1:40ba:145:100:185:15,443,dnsovertls.sinodun.com,62lKu9HsDVbyiPenApnc4sfmSYTHOVfFgL3pyB+cBL4=
Surfnet/Sinodun 2,2001:610:1:40ba:145:100:185:16,443,dnsovertls1.sinodun.com,cE2ecALeE5B+urJhDrJlVFmf38cJLAvqekONvjvpqUA=

As mentioned before, the only test servers kept on the list are for port 443, as none of the main production resolvers support port 443.
 
Code: 
[01:50:25.762946] STUBBY: 2620:fe::9                               : Conn opene                                                                              d: TLS - Strict Profile
[01:50:25.854067] STUBBY: 2620:fe::9                               : Verify pas                                                                              sed : TLS
[01:50:25.956761] STUBBY: 2620:fe::fe                              : Conn opene                                                                              d: TLS - Strict Profile
[01:50:26.050073] STUBBY: 2620:fe::fe                              : Verify pas                                                                              sed : TLS
[01:50:26.114718] STUBBY: 2620:fe::fe:9                            : Conn opene                                                                              d: TLS - Strict Profile
[01:50:26.210824] STUBBY: 2620:fe::fe:9                            : Verify pas                                                                              sed : TLS
[01:50:28.116775] STUBBY: 2620:fe::fe                              : Conn closed: TLS - Resps=     1, Timeouts  =     0, Curr_auth =Success, Keepalive(ms)=  9000
[01:50:28.117036] STUBBY: 2620:fe::fe                              : Upstream   : TLS - Resps=     1, Timeouts  =     0, Best_auth =Success
[01:50:28.117241] STUBBY: 2620:fe::fe                              : Upstream   : TLS - Conns=     2, Conn_fails=     0, Conn_shuts=      1, Backoffs     =     0
[01:50:28.147511] STUBBY: 2620:fe::9                               : Conn closed: TLS - Resps=     2, Timeouts  =     0, Curr_auth =Success, Keepalive(ms)=  9000
[01:50:28.147738] STUBBY: 2620:fe::9                               : Upstream   : TLS - Resps=     2, Timeouts  =     0, Best_auth =Success
[01:50:28.148299] STUBBY: 2620:fe::9                               : Upstream   : TLS - Conns=     1, Conn_fails=     0, Conn_shuts=      1, Backoffs     =     0
[01:50:28.272520] STUBBY: 2620:fe::fe:9                            : Conn closed: TLS - Resps=     1, Timeouts  =     0, Curr_auth =Success, Keepalive(ms)=  9000
[01:50:28.272741] STUBBY: 2620:fe::fe:9                            : Upstream   : TLS - Resps=     1, Timeouts  =     0, Best_auth =Success
[01:50:28.272924] STUBBY: 2620:fe::fe:9                            : Upstream   : TLS - Conns=     2, Conn_fails=     0, Conn_shuts=      1, Backoffs     =     0
 
dave14305 said:
Boy, this does conjure memories of the growing pains with Stubby on John's fork. The conn_shuts are certainly undesirable and it's supposed to be better to let Stubby timeout the connection instead of the remote server. There's an open issue for stubby on github concerning this.

I can see this becoming a support issue going forward, depending on how many preset servers have timeouts less than 9000 ms.
Click to expand...

My implementation has round robin enabled however, which apparently should be less problematic.
 
RMerlin said:
My implementation has round robin enabled however, which apparently should be less problematic.
Click to expand...
IMHO, CloudFlare is winning the (small) battle for DoT supremacy, so as long as your defaults work well with it, most people will be fine.

Me? I use Quad9 instead of CloudFlare. Firefox instead of Chrome. Butter instead of margarine. :p
 
dave14305 said:
IMHO, CloudFlare is winning the (small) battle for DoT supremacy, so as long as your defaults work well with it, most people will be fine.

Me? I use Quad9 instead of CloudFlare. Firefox instead of Chrome. Butter instead of margarine. :p
Click to expand...

DoT is still young. Once the kinks get ironed out and server admins have a better idea of the type of increase in server/network load it involves, we might see more providers supporting it. It will require a fairly significant critical mass for it to be supported by ISP unfortunately, as I suspect their existing DNS servers would require CPU and RAM upgrade to handle the extra load involved.
 
idk if it is good for isp to support it though because some users simply use it to avoid isp's keeping record.
 
how would one go about detecting if their port 53 was being redirected via their ISP?
 
Swistheater said:
what do you have in your config file for optimal setup with cloudflare?
Click to expand...
Code: 
# cat /tmp/etc/stubby/stubby.yml
resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_ca_file: "/etc/ssl/certs/ca-certificates.crt"
appdata_dir: "/var/lib/misc"
resolvconf: "/tmp/resolv.conf"
edns_client_subnet_private: 1
listen_addresses:
  - 127.0.1.1@53
upstream_recursive_servers:
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 1.0.0.1
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 2606:4700:4700::1111
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 2606:4700:4700::1001
    tls_auth_name: "cloudflare-dns.com"
idle_timeout: 9900
Code: 
# cat /jffs/scripts/stubby.postconf
#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh
#
pc_delete "tls_query_padding_blocksize" $CONFIG
pc_delete "round_robin_upstreams" $CONFIG
pc_delete "tls_connection_retries" $CONFIG
pc_delete "tls_backoff_time" $CONFIG
pc_delete "timeout" $CONFIG
#
pc_append "idle_timeout: 9900" $CONFIG
#
 
Has anyone noticed that /jffs/configs/profile.add is not working?
Code: 
# cat /jffs/configs/profile.add
alias freshjr="sh /jffs/scripts/FreshJR_QOS -menu"
alias freshjrqos="sh /jffs/scripts/FreshJR_QOS -menu"
alias freshjr_qos="sh /jffs/scripts/FreshJR_QOS -menu"
alias FreshJR_QOS="sh /jffs/scripts/FreshJR_QOS -menu"

# freshjr_qos
-sh: freshjr_qos: not found
I created a workaround
Code: 
# ls -la /opt/bin/freshjr
-rwxr-xr-x    1 HdB34266 root            32 Apr 27 16:42 /opt/bin/freshjr

# cat /opt/bin/freshjr
/jffs/scripts/FreshJR_QOS -menu
 
RMerlin said:
There is no need for an Apply button, the change is applied asynchronously to the router when you change it. Using an Apply button would require a rewrite of a large portion of that page, and isn't worth it.

Asus uses the same async method with the redesigned Virtual Server page now.
Click to expand...

For me if No is selected, and I refresh / change page or tab, it goes back to Yes no mater what...?
 
EmeraldDeer said:
Has anyone noticed that /jffs/configs/profile.add is not working?
Code: 
# cat /jffs/configs/profile.add
alias freshjr="sh /jffs/scripts/FreshJR_QOS -menu"
alias freshjrqos="sh /jffs/scripts/FreshJR_QOS -menu"
alias freshjr_qos="sh /jffs/scripts/FreshJR_QOS -menu"
alias FreshJR_QOS="sh /jffs/scripts/FreshJR_QOS -menu"

# freshjr_qos
-sh: freshjr_qos: not found
I created a workaround
Code: 
# ls -la /opt/bin/freshjr
-rwxr-xr-x    1 HdB34266 root            32 Apr 27 16:42 /opt/bin/freshjr

# cat /opt/bin/freshjr
/jffs/scripts/FreshJR_QOS -menu
Click to expand...
yea i stopped using fresh once i noticed devices periodically losing connection. not because fresh has a bad idea on his setup, but because ASUS is horrible with properly identifying traffic and I think they have made it worse and this doesn't help his script out. If i felt like re-identifying traffic myself i would to correct it, but at the end of the day it is too much work.
 
RMerlin said:
On the other hand, lack of EDNS support means Cloudflare can potentially degrade your overall network performance by pointing you at non-optimal CDN servers.

It's one of the reasons why, personally, after I'm done implementing and testing DoT, I intend to disable it, and go back to my ISP DNS.
Click to expand...
Didn't expect to read that.
 
You must log in or register to reply here.

Similar threads

RMerlin
  • Locked
Beta Asuswrt-Merlin 3006.102.2 Beta is now available for Wifi 7 devices
2 3 4
Replies
70
Views
12K
RMerlin
RMerlin
RMerlin
  • Locked
Beta Asuswrt-Merlin 386.14 beta is now available
2
Replies
35
Views
9K
RMerlin
RMerlin
RMerlin
  • Locked
Beta Asuswrt-Merlin 3004.388.8 beta is now available
6 7 8
Replies
155
Views
31K
RMerlin
RMerlin
RMerlin
  • Locked
Beta Asuswrt-Merlin 3004.388.7 beta is now available
5 6 7
Replies
123
Views
17K
RMerlin
RMerlin
RMerlin
Release Asuswrt-Merlin 3006.102.2 is now available for Wifi 7 devices
3 4 5
Replies
97
Views
14K
nzwayne
nzwayne
Similar threads
Thread starter Title Forum Replies Date
RMerlin Beta Asuswrt-Merlin 3006.102.2 Beta is now available for Wifi 7 devices Asuswrt-Merlin 70
RMerlin Beta Asuswrt-Merlin 386.14 beta is now available Asuswrt-Merlin 35
RMerlin Beta Asuswrt-Merlin 3004.388.8 beta is now available Asuswrt-Merlin 155
RMerlin Beta Asuswrt-Merlin 3006.102.1 Beta is now available for WIfi 7 devices Asuswrt-Merlin 97
RMerlin Beta Asuswrt-Merlin 3004.388.7 beta is now available Asuswrt-Merlin 123
RMerlin Beta Asuswrt-Merlin 386.13 beta is now available for AC models Asuswrt-Merlin 32
RMerlin Beta Asuswrt-Merlin 3004.388.6 Beta is now available Asuswrt-Merlin 279
M Asuswrt-Merlin with Nextcloud's share folder functionality Asuswrt-Merlin 1
visortgw Asuswrt Merlin 3006.102.3 Alpha1 for GT-BE98 Pro Asuswrt-Merlin 38
A ASUSwrt-Merlin connection to modem as Access Point and/or Bridge Asuswrt-Merlin 6

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!

Members online

Total: 691 (members: 11, guests: 680)
Top