What's new

[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!

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.
I have yet to experience this issue but once I do , I am sure I will be looking else where for dns resolver
 
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
=================================================================================================================================================================
Same here. I had dropouts with CB, Q9 wouldn't pass any DoT test, only CF works well accross the board here.
 
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
=================================================================================================================================================================

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
 
Same here. I had dropouts with CB, Q9 wouldn't pass any DoT test, only CF works well accross the board here.

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

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.
 
Can anyone with IPv6 support confirm that the IPv6 Quad9 servers also work properly with DoT?

2620:fe::fe
2620:fe::9

I have checked them they do work. I can add them real quick and show you the stubby -l if you like
 
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.
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.
 
I have checked them they do work. I can add them real quick and show you the stubby -l if you like

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

My implementation has round robin enabled however, which apparently should be less problematic.
 
My implementation has round robin enabled however, which apparently should be less problematic.
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
 
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

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?
 
what do you have in your config file for optimal setup with cloudflare?
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
 
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.

For me if No is selected, and I refresh / change page or tab, it goes back to Yes no mater what...?
 
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
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.
 
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.
Didn't expect to read that.
 

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!
Top