Stubby needs extra Start after Restart of Router

Installing and Using OpenWrt
1

Hi everybody!
I need a little help with a Stubby issue. For an unknown reason Stubby needs an extra restart via Startup after the Booting of the rooter. Otherwise connection to the internet fails. Is there a way to automatise this via Scheduled Tasks? Is it a common issue?

nano /etc/config/qos

       # option tls_connection_retries '2'
       # option tls_backoff_time '3600'
       # option timeout '5000'
       # option dnssec_return_status '1'
       option appdata_dir '/var/lib/stubby'
       # option trust_anchors_backoff_time 2500
       # option dnssec_trust_anchors '/var/lib/stubby/getdns-root.key'
       option edns_client_subnet_private '1'
       option idle_timeout '10000'
       option round_robin_upstreams '1'
       list listen_address '127.0.0.1@5453'
       list listen_address '0::1@5453'
       # option log_level '7'
       # option command_line_arguments ''
       # option tls_cipher_list 'EECDH+AESGCM:EECDH+CHACHA20'
       # option tls_ciphersuites 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256'
       # option tls_min_version '1.2'
       # option tls_max_version '1.3'

# Upstream resolvers are specified using 'resolver' sections.
config resolver  
        option address '116.203.32.217'  
        option tls_auth_name 'fdns1.dismail.de'  
        list spki 'sha256/MMi3E2HZr5A5GL+badqe3tzEPCB00+OmApZqJakbqUU='

config resolver         
        option address '46.182.19.48' 
        option tls_auth_name 'dns2.digitalcourage.de'    
        list spki 'sha256/v7rm6OtQQD3x/wbsdHDZjiDg+utMZvnoX3jq3Vi8tGU='

config resolver
    option address '2a01:4f8:251:554::2'
    option tls_auth_name 'dns3.digitalcourage.de'
    list spki 'sha256/2WFzfO2/56HpeR+v/l25NPf5dacfxLrudH5yZbWCfdo='

config stubby 'global'
        [..]
        option tls_min_version '1.2'

dnssec: GETDNS_EXTENSION_TRUE

Thanks in advance and best wishes
Friedrich

2

Add it to rc.local ?
Race condition, perhaps.

3

Check

logread -e stubby

while it is not started.

no chance it ever reads config/qos

4

Just set a suitable network trigger plus trigger delay, see the readme for reference: https://github.com/openwrt/packages/tree/master/net/stubby/files#option-trigger

Any odd rc.local workarounds/restarts are not required.

3 Likes
5

Yes, I remember we had a similar discussion back in a day

6

Everything SSL related is dependant on time.
If you have no RTC you might need to use a regular insecure DNS for your NTP server(s).

2 Likes
7

This was really weird. I havent ever used /qos so this is some strange automatic referral from cat /etc/config/stubby.

/edit
Really strange. As I now see the config file it looks it was missing lines before

cat /etc/config/stubby
config stubby 'global'
       option manual '0'
       option trigger 'wan'
       # option triggerdelay '2'
       list dns_transport 'GETDNS_TRANSPORT_TLS'
       option tls_authentication '1'
       option tls_query_padding_blocksize '128'
       # option tls_connection_retries '2'
       # option tls_backoff_time '3600'
       # option timeout '5000'
       # option dnssec_return_status '1'
       option appdata_dir '/var/lib/stubby'
       # option trust_anchors_backoff_time 2500
       # option dnssec_trust_anchors '/var/lib/stubby/getdns-root.key'
       option edns_client_subnet_private '1'
       option idle_timeout '10000'
       option round_robin_upstreams '1'
       list listen_address '127.0.0.1@5453'
       list listen_address '0::1@5453'
       # option log_level '7'
       # option command_line_arguments ''
       # option tls_cipher_list 'EECDH+AESGCM:EECDH+CHACHA20'
       # option tls_ciphersuites 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256'
       # option tls_min_version '1.2'
       # option tls_max_version '1.3'

# Upstream resolvers are specified using 'resolver' sections.
config resolver  
        option address '116.203.32.217'  
        option tls_auth_name 'fdns1.dismail.de'  
        list spki 'sha256/MMi3E2HZr5A5GL+badqe3tzEPCB00+OmApZqJakbqUU='

config resolver         
        option address '46.182.19.48' 
        option tls_auth_name 'dns2.digitalcourage.de'    
        list spki 'sha256/v7rm6OtQQD3x/wbsdHDZjiDg+utMZvnoX3jq3Vi8tGU='

config resolver
    option address '2a01:4f8:251:554::2'
    option tls_auth_name 'dns3.digitalcourage.de'
    list spki 'sha256/2WFzfO2/56HpeR+v/l25NPf5dacfxLrudH5yZbWCfdo='

config stubby 'global'
        [..]
        option tls_min_version '1.2'

dnssec: GETDNS_EXTENSION_TRUE

So a decent trigger is set. This was the config all the time

/edit2
Here is what the log reads wenn stubby is disabled and stopped

Sun Nov 24 17:16:57 2024 daemon.err stubby[26094]: [16:16:57.794536] STUBBY: Read config from file /var/etc/stubby/stubby.yml[16:16:57.795581] STUBBY: Stubby version: Stubby 0.4.3
Sun Nov 24 17:16:57 2024 daemon.err stubby[26094]: [16:16:57.796550] STUBBY: DNSSEC Validation is OFF
Sun Nov 24 17:16:57 2024 daemon.err stubby[26094]: [16:16:57.797226] STUBBY: Transport list is:
Sun Nov 24 17:16:57 2024 daemon.err stubby[26094]: [16:16:57.797657] STUBBY:   - TLS
Sun Nov 24 17:16:57 2024 daemon.err stubby[26094]: [16:16:57.798145] STUBBY: Privacy Usage Profile is Strict (Authentication required)
Sun Nov 24 17:16:57 2024 daemon.err stubby[26094]: [16:16:57.798695] STUBBY: (NOTE a Strict Profile only applies when TLS is the ONLY transport!!)
Sun Nov 24 17:16:57 2024 daemon.err stubby[26094]: [16:16:57.799163] STUBBY: Starting DAEMON.

There is an hour difference in time? Might this be the reason?

8

Well WAN was set as the trigger and caused she issue. I can try using "Lan" but does it make it any better? Are there other options? The "list xx" version in the linked thread would mean I could link it to both lan and wan? Or how my this help?

9

Most of the time you should link to your wan(s) only, because this is how you reach your DNS and NTP servers.
However, there is a possibility that your wan is up, but your local time is still wrong.
There is also another possibility that your wan is up but there is no Internet access for whatever reason (no credit, portal redirect, etc.).

10

Yep, set/raise the option 'triggerdelay' as well (next paragraph in the readme). Default is only 2 seconds and that might be not enough, e.g. on pppoe interfaces ...

11

So 30 sec are not enough. Is there something I need to correct with the discrepancy in time which occurs in the log?

12

Sorry to get the topic up again but I have not yet found a solution. I guess the discrepancy in time (between the router and Stubby?) might cause the issue with Stubby as you pointed out. What servers might work as regular insecure DNS? Now it is configured with the default openwrt NTP servers. Thanks again for any help.
Best
Friedrich

13

If you need correct time before DNS but configured the default OpenWrt server (i.e., a hostname), then you'll have the same issue.

Use an NTP server that permits you to setup its IP address. Then you'd no longer have the chicken-or-the-egg paradox of neeing correct time before your first secure DNS queries (i.e
which needs correct time) to reach the NTP servers by name (i.e. needing secure DNS with correct time).

Common ones are:

  • 1.1.1.1 (CloudFlare)
  • 8.8.8.8 (Google)
  • 9.9.9.9 (Quad9)
14

You can use any public DNS (you have a list already) for your NTP domain as shown in Secure DNS problem - #41 by AndrewZ

1 Like