[Fork] Asuswrt-Merlin 374.43 LTS - DNS over TLS Beta - CLOSED

[bbunge]

Hi John. Spoke too soon. I am still getting the "syslog: password for 'admin' changed" message when I have DoT configured. I have played around with killing processes and starting them up manually to replicate this (it is not my browser as the log messages are happening during the boot cycle for the router). I killed haveged (random number generator) manually and started it manually and no dice; cannot replicate. I have to be surprised if I am the only one seeing this as it is happening during the boot cycle and I don't have any crazy configuration whatsoever. Please check your log files colleagues and let's see why this message is happening!

Dec 31 18:00:30 stop_nat_rules: apply the redirect_rules!
Dec 31 18:00:30 stop_nat_rules: (/tmp/redirect_rules) success!
Dec 31 18:00:30 WAN_Connection: ISP's DHCP did not function properly.
Dec 31 18:00:30 haveged: haveged starting up
Dec 31 18:00:30 syslog: password for 'admin' changed
Dec 31 18:00:30 stubby-proxy: configured no-TLS mode
Dec 31 18:00:30 stubby-proxy: configured server 'Cloudflare' at address 1.1.1.1:853
Dec 31 18:00:30 stubby-proxy: configured server 'Cloudflare_alt' at address 1.0.0.1:853
Dec 31 18:00:30 stubby-proxy: configured server 'Quad 9' at address 9.9.9.9:853
Dec 31 18:00:32 stubby-proxy: start stubby (0)

Do not have syslog: password for 'admin' changed in my log file. RT-AC66U_B1 Could it be that I have changed my "admin" user?

 

[JWoo]

I changed my default admin user from "admin" to "stinky".

Dec 31 18:00:30 (none) kern.debug stop_nat_rules: apply the redirect_rules!
Dec 31 18:00:30 (none) kern.debug stop_nat_rules: (/tmp/redirect_rules) success!
Dec 31 18:00:30 (none) kern.debug WAN_Connection: ISP's DHCP did not function properly.
Dec 31 18:00:30 (none) daemon.notice haveged: haveged starting up
Dec 31 18:00:30 (none) user.err syslog: password for 'stinky' changed
Dec 31 18:00:31 (none) kern.debug stubby-proxy: configured no-TLS mode
Dec 31 18:00:31 (none) kern.debug stubby-proxy: configured server 'Cloudflare' at address 1.1.1.1:853
Dec 31 18:00:31 (none) kern.debug stubby-proxy: configured server 'Cloudflare_alt' at address 1.0.0.1:853
Dec 31 18:00:31 (none) kern.debug stubby-proxy: configured server 'Quad 9' at address 9.9.9.9:853
Dec 31 18:00:32 (none) kern.debug stubby-proxy: start stubby (0)
Dec 31 18:00:32 (none) daemon.info dnsmasq[602]: started, version 2.80test3 cachesize 1500

 

[ColinTaylor]

@JWoo Just a random idea, but try disabling the Protection Server (Firewall > General > Enable Telnet/SSH Protection Server).

 

[JWoo]

I also changed the logging to verbose. So this is now showing to be a error message "user.err syslog: password for 'stinky' changed" If I change the admin user back to admin, the message is "user.err syslog: password for 'admin' changed" Again, this is happening during the boot cycle for the router well before the system clock is set. So kind of a mystery as to why this is happening.

 

[Grisu]

try changeing PW to an easy one 8 character&digit only if it helps

 

[JWoo]

@JWoo Just a random idea, but try disabling the Protection Server (Firewall > General > Enable Telnet/SSH Protection Server).

Thanks Colin for the idea here. I just made this change and rebooted ye olde RT-AC68U. Still get the same message about "user.err syslog: password for 'admin' changed"

 

[JWoo]

try changeing PW to an easy one 8 character&digit only if it helps

Tried this but did not help. Thanks for the idea though.

 

[john9527]

Thanks Colin for the idea here. I just made this change and rebooted ye olde RT-AC68U. Still get the same message about "user.err syslog: password for 'admin' changed"

Think I figured this one out.....if you SSH enabled, the password is initialized during dropbear start, and you'll see a dropbear log instead. If SSH is not enabled, the system initializes the password during init and you get the password changed msg.

 

[ColinTaylor]

Think I figured this one out.....if you SSH enabled, the password is initialized during dropbear start, and you'll see a dropbear log instead. If SSH is not enabled, the system initializes the password during init and you get the password changed msg.

Ah. I was just looking at services.c and it looks like it does something similar if telnetd is enabled.

 

[john9527]

John, is it possible to configure a second Quad9 server in stubby?
149.112.112.112:853
2620:fe::9:853

Edit: There are Quad9 secure and insecure servers listed in the latest stubby config:
https://raw.githubusercontent.com/getdnsapi/stubby/develop/stubby.yml.example
I feel including all the Quad9 servers would give more options to the DoT as Quad9 does use DNSSEC.

Oh, this Beta is working well for me and it is fun to have something new that works to learn!

You've stumbled on to one of the current drawbacks of DoT, in that there really isn't a good consolidated list of verified DoT servers. The stubby.yml.example file is different from the web page listing at dnsprivacy.org.

I'm using a 'custom' list that I make in csv format (you can see it on the router at /rom/stubby-resolvers.csv). Why csv? I had already written a general csv parser for the dnscrypt v1 support that integrates with the gui..

For the beta, it was a quick list that I put together from dnsprivacy.org. I just finished adding a list update capability for the formal release and will be making another pass on updating that list. Right now, I'm going to host the update on my onedrive, but plan an opening an issue to see if I can get the stubby development team to pick it up

In the meantime, I'm also going to also depend on the user community to provide feedback on potential missing servers (just like you did.....thanks!)

 

[blueshark]

you can add this one to the list

https://blog.uncensoreddns.org

 

[ColinTaylor]

Edit: There are Quad9 secure and insecure servers listed in the latest stubby config:
https://raw.githubusercontent.com/getdnsapi/stubby/develop/stubby.yml.example
I feel including all the Quad9 servers would give more options to the DoT as Quad9 does use DNSSEC.

I'm confused. The stubby.yml file says:

## Quad 9 'insecure' service - No filtering, does DNSSEC, may send ECS (it is
## unclear if it honours the edns_client_subnet_private request from stubby)
# - address_data: 9.9.9.10
# tls_auth_name: "dns.quad9.net

## Quad 9 'insecure' service - No filtering, does DNSSEC, may send ECS (it is
## unclear if it honours the edns_client_subnet_private request from stubby)
# - address_data: 2620:fe::10
# tls_auth_name: "dns.quad9.net"

And yet the FAQ on Quad9's website says:

Unsecured IP: 9.9.9.10 Provides: No security blocklist, no DNSSEC, sends EDNS Client-Subnet. If your DNS software requires a Secondary IP address, please use the unsecured secondary address of 149.112.112.10

Unsecured IPv6 Primary: 2620:fe::10 No blocklist, no DNSSEC, send EDNS Client-Subnet
Unsecured IPv6 Secondary: 2620:fe::fe:10 No blocklist, no DNSSEC, send EDNS Client-Subnet

???

 

[bbunge]

I'm confused. The stubby.yml file says:

## Quad 9 'insecure' service - No filtering, does DNSSEC, may send ECS (it is
## unclear if it honours the edns_client_subnet_private request from stubby)
# - address_data: 9.9.9.10
# tls_auth_name: "dns.quad9.net

## Quad 9 'insecure' service - No filtering, does DNSSEC, may send ECS (it is
## unclear if it honours the edns_client_subnet_private request from stubby)
# - address_data: 2620:fe::10
# tls_auth_name: "dns.quad9.net"

And yet the FAQ on Quad9's website says:

Unsecured IP: 9.9.9.10 Provides: No security blocklist, no DNSSEC, sends EDNS Client-Subnet. If your DNS software requires a Secondary IP address, please use the unsecured secondary address of 149.112.112.10

Unsecured IPv6 Primary: 2620:fe::10 No blocklist, no DNSSEC, send EDNS Client-Subnet
Unsecured IPv6 Secondary: 2620:fe::fe:10 No blocklist, no DNSSEC, send EDNS Client-Subnet

???

Ah, the fine print we forget to read! I missed that 9.9.9.10 has no DNSSEC but again Cloudflare seems to not have DNSSEC either. Both should be able to use DoT? But there should be a different URL for 9.9.9.10...
Edit: 9.9.9.10 URL is dns-nosec.quad9.net

 

[bbunge]

You've stumbled on to one of the current drawbacks of DoT, in that there really isn't a good consolidated list of verified DoT servers. The stubby.yml.example file is different from the web page listing at dnsprivacy.org.

I'm using a 'custom' list that I make in csv format (you can see it on the router at /rom/stubby-resolvers.csv). Why csv? I had already written a general csv parser for the dnscrypt v1 support that integrates with the gui..

For the beta, it was a quick list that I put together from dnsprivacy.org. I just finished adding a list update capability for the formal release and will be making another pass on updating that list. Right now, I'm going to host the update on my onedrive, but plan an opening an issue to see if I can get the stubby development team to pick it up

In the meantime, I'm also going to also depend on the user community to provide feedback on potential missing servers (just like you did.....thanks!)

Could this file go into /jffs/?? so we could edit it? Yes, I know the dangers but there could be a backup file in the read only area that could be copied over in the event of fumble fingers. Would be easy to update the list in lieu of an entire firmware upgrade.

 

[JWoo]

Thanks John. You are a rockstar. Confirmed that enabling Telnet causes this. So basically, this is a non-problem and you are a master detective and system guru with a lot of curiosity.

If only SSH is enabled, the log file looks as follows:

Dec 31 18:00:30 haveged: haveged starting up
Dec 31 18:00:30 dropbear[583]: Running in background

If Telnet is enabled, you get

Dec 31 18:00:30 haveged: haveged starting up
Dec 31 18:00:30 syslog: password for 'admin' changed

If you have both SSH and Telnet you get

Dec 31 18:00:30 haveged: haveged starting up
Dec 31 18:00:30 syslog: password for 'admin' changed
Dec 31 18:00:31 dropbear[593]: Running in background

 

[john9527]

Ah, the fine print we forget to read! I missed that 9.9.9.10 has no DNSSEC but again Cloudflare seems to not have DNSSEC either. Both should be able to use DoT? But there should be a different URL for 9.9.9.10...
Edit: 9.9.9.10 URL is dns-nosec.quad9.net

Well, here's a kick.....just tested the Quad 9 Insecure servers and they DO NOT appear to be DoT enabled.

 

[john9527]

If you have both SSH and Telnet you get

Dec 31 18:00:30 haveged: haveged starting up
Dec 31 18:00:30 syslog: password for 'admin' changed
Dec 31 18:00:31 dropbear[593]: Running in background

And this is just a result of the startup order.....telnetd starts before dropbear. If dropbear were to start first, you wouldn't see the password changed message from starting telnetd.

 

[bbunge]

You've stumbled on to one of the current drawbacks of DoT, in that there really isn't a good consolidated list of verified DoT servers. The stubby.yml.example file is different from the web page listing at dnsprivacy.org.

I'm using a 'custom' list that I make in csv format (you can see it on the router at /rom/stubby-resolvers.csv). Why csv? I had already written a general csv parser for the dnscrypt v1 support that integrates with the gui..

For the beta, it was a quick list that I put together from dnsprivacy.org. I just finished adding a list update capability for the formal release and will be making another pass on updating that list. Right now, I'm going to host the update on my onedrive, but plan an opening an issue to see if I can get the stubby development team to pick it up

In the meantime, I'm also going to also depend on the user community to provide feedback on potential missing servers (just like you did.....thanks!)

I asked Quad9 about the non-secure server. Currently it does use dns-nosec.quad9.net but they say that will change shortly to a "better non-English variant." For now I feel the stubby entries should be for just the "secure" Quad9 servers.

 

[john9527]

Could this file go into /jffs/?? so we could edit it? Yes, I know the dangers but there could be a backup file in the read only area that could be copied over in the event of fumble fingers. Would be easy to update the list in lieu of an entire firmware upgrade.

That's how the 'updater' works....

The framework is already in the beta if you want to experiment....
set the nvram variable
stubby_csv
to point to the full path/filename

 

[bluepoint]

John, is it possible to configure a second Quad9 server in stubby?
149.112.112.112:853
2620:fe::9:853

For Quad9, there is really no need to add a second server as it's an "anycast" dns server. If the one closest to you goes down, it'll use another available server on its own.