Menu
What's new
By:
Filters Better Search

Stubby-Installer-Asuswrt-Merlin

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

Marin said:
There is a some info in the forums regarding DNS rebind attacks...and why the need to protect agains them. It is not an easy concept to understand unless you read more about it. Consider searching the forums for specific cases and also the web for general info but you could start by looking at the links below and you could even test your network by going to: http://rebind.network/rebind/index.html

or
https://en.wikipedia.org/wiki/DNS_rebinding
https://crypto.stanford.edu/dns/dns-rebinding.pdf
https://www.wired.com/story/chromecast-roku-sonos-dns-rebinding-vulnerability/
https://apps.dtic.mil/dtic/tr/fulltext/u2/a508892.pdf
https://www.usenix.org/system/files/conference/woot13/woot13-dai.pdf
https://www.adambarth.com/papers/2009/jackson-barth-bortz-shao-boneh-tweb.pdf
Click to expand...
not that I don't take rebind attacks seriously, but I have to say that the "test site was dead off". I feel that was for entertainment purposes.
 
My recommendation is to continue using dnsmasq proxy-dnssec and to not enable the stubby dnssec getdns extension.
 
bbunge said:
Stubby.yml is the config file for Stubby. It is the right place to add the DNSSEC entry. Be sure to restart stubby after.

Sent from my SM-T380 using Tapatalk
Click to expand...
@bbunge,

Thank you, I have decided to give this a shot. On my:

Code: 
nano /opt/etc/stubby/stubby.yml

I added to this section:

Code: 
tls_ca_file: "/rom/etc/ssl/certs/ca-certificates.crt"
resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
dnssec_return_status: GETDNS_EXTENSION_TRUE
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 128
edns_client_subnet_private : 1
round_robin_upstreams: 1
idle_timeout: 2000
tls_connection_retries: 5
tls_backoff_time: 900
timeout: 2000
appdata_dir: "/opt/var/cache/stubby"
listen_addresses:
  - 127.0.0.1@5453
  - 0::1@5453

and then I did restarted Stubby:

Code: 
/opt/etc/init.d/S61stubby restart

The Cloudflare 1.1.1.1/help test fails as mentioned:

upload_2019-3-13_21-55-22.png



This shows DNSSEC validation as ON:

Code: 
29F0:/tmp/home/root# stubby -l
[02:57:59.247175] STUBBY: Read config from file /opt/etc/stubby/stubby.yml
[02:57:59.247773] STUBBY: DNSSEC Validation is ON
[02:57:59.247801] STUBBY: Transport list is:
[02:57:59.247816] STUBBY:   - TLS
[02:57:59.247832] STUBBY: Privacy Usage Profile is Strict (Authentication required)
[02:57:59.247848] STUBBY: (NOTE a Strict Profile only applies when TLS is the ONLY transport!!)
[02:57:59.247863] STUBBY: Starting DAEMON....

and this: https://dnssec.vs.uni-due.de shows that DNSSEC validation is OK

Then I ran this as well:

Code: 
29F0:/tmp/home/root# stubby -i | grep -i dnssec
[03:06:16.655350] STUBBY: Read config from file /opt/etc/stubby/stubby.yml
Result: Config file syntax is valid.
    "dnssec": GETDNS_EXTENSION_FALSE,
    "dnssec_allowed_skew": 0,
    "dnssec_return_all_statuses": GETDNS_EXTENSION_FALSE,
    "dnssec_return_full_validation_chain": GETDNS_EXTENSION_FALSE,
    "dnssec_return_only_secure": GETDNS_EXTENSION_FALSE,
    "dnssec_return_status": GETDNS_EXTENSION_TRUE,
    "dnssec_return_validation_chain": GETDNS_EXTENSION_FALSE,
    "trust_anchors_verify_email": <bindata of "dnssec@iana.org">

all other validation tests here (https://github.com/Xentrk/Stubby-Installer-Asuswrt-Merlin) seem Ok. Aside from Cloudflare Help that breaks Stubby, are there any other tests to run to show that is working as it should?
 
Xentrk said:
To validate, you can install the entware package drill and type the command followed by a "-D" and the domain name. If the site supports DNSSEC, you will see an "ad" flag in the response.

Code: 
drill -D x3mtek.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 7760
;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
<snip>

Vaidation in Stubby:
Code: 
stubby -l
[02:47:14.825381] STUBBY: Read config from file /opt/etc/stubby/stubby.yml
[02:47:14.826535] STUBBY: DNSSEC Validation is ON
[02:47:14.826582] STUBBY: Transport list is:
[02:47:14.826594] STUBBY:   - TLS
[02:47:14.826606] STUBBY: Privacy Usage Profile is Strict (Authentication required)
[02:47:14.826618] STUBBY: (NOTE a Strict Profile only applies when TLS is the ONLY transport!!)
[02:47:14.826628] STUBBY: Starting DAEMON....

https://www.cloudflare.com/ssl/encrypted-sni/ will tell you if you are using encrypted DNS. But it does not specify if you are using DoH or DoT protocols. Will also confirm if DNSSEC is enabled.
Click to expand...

I also use the ISC Dig app on my phone that help reveal the “ad” flags


Sent from my iPhone using Tapatalk
 
Myself I follow @bbunge advice on using the getdns dnssec extension instruction in the .yml. Works good and is predictable. Thanks @bbunge for your continued testing. ;):)
 
Marin said:
@bbunge,

Thank you, I have decided to give this a shot. On my:

Code: 
nano /opt/etc/stubby/stubby.yml

I added to this section:

Code: 
tls_ca_file: "/rom/etc/ssl/certs/ca-certificates.crt"
resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
dnssec_return_status: GETDNS_EXTENSION_TRUE
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 128
edns_client_subnet_private : 1
round_robin_upstreams: 1
idle_timeout: 2000
tls_connection_retries: 5
tls_backoff_time: 900
timeout: 2000
appdata_dir: "/opt/var/cache/stubby"
listen_addresses:
  - 127.0.0.1@5453
  - 0::1@5453

and then I did restarted Stubby:

Code: 
/opt/etc/init.d/S61stubby restart

The Cloudflare 1.1.1.1/help test fails as mentioned:

View attachment 16561


This shows DNSSEC validation as ON:

Code: 
29F0:/tmp/home/root# stubby -l
[02:57:59.247175] STUBBY: Read config from file /opt/etc/stubby/stubby.yml
[02:57:59.247773] STUBBY: DNSSEC Validation is ON
[02:57:59.247801] STUBBY: Transport list is:
[02:57:59.247816] STUBBY:   - TLS
[02:57:59.247832] STUBBY: Privacy Usage Profile is Strict (Authentication required)
[02:57:59.247848] STUBBY: (NOTE a Strict Profile only applies when TLS is the ONLY transport!!)
[02:57:59.247863] STUBBY: Starting DAEMON....

and this: https://dnssec.vs.uni-due.de shows that DNSSEC validation is OK

Then I ran this as well:

Code: 
29F0:/tmp/home/root# stubby -i | grep -i dnssec
[03:06:16.655350] STUBBY: Read config from file /opt/etc/stubby/stubby.yml
Result: Config file syntax is valid.
    "dnssec": GETDNS_EXTENSION_FALSE,
    "dnssec_allowed_skew": 0,
    "dnssec_return_all_statuses": GETDNS_EXTENSION_FALSE,
    "dnssec_return_full_validation_chain": GETDNS_EXTENSION_FALSE,
    "dnssec_return_only_secure": GETDNS_EXTENSION_FALSE,
    "dnssec_return_status": GETDNS_EXTENSION_TRUE,
    "dnssec_return_validation_chain": GETDNS_EXTENSION_FALSE,
    "trust_anchors_verify_email": <bindata of "dnssec@iana.org">

all other validation tests here (https://github.com/Xentrk/Stubby-Installer-Asuswrt-Merlin) seem Ok. Aside from Cloudflare Help that breaks Stubby, are there any other tests to run to show that is working as it should?
Click to expand...
Something is not right.
Code: 
stubby -i | grep -i dnssec
[03:06:16.655350] STUBBY: Read config from file /opt/etc/stubby/stubby.yml
Result: Config file syntax is valid.

Looks like an error in stubby.yml - Result: Config file syntax is valid. The test site should have passed the test as being connected to 1.1.1.1.

Try using the stubby.yml below

tls_ca_file: "/rom/etc/ssl/certs/ca-certificates.crt"
resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
- GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
dnssec_return_status: GETDNS_EXTENSION_TRUE
tls_query_padding_blocksize: 128
edns_client_subnet_private : 1
round_robin_upstreams: 1
idle_timeout: 2000
tls_connection_retries: 5
tls_backoff_time: 900
timeout: 2000
appdata_dir: "/opt/var/cache/stubby"
listen_addresses:
- 127.0.0.1@5453
- 0::1@5453

upstream_recursive_servers:
# Quad 9 Secure Primary
# - address_data: 9.9.9.9
# tls_auth_name: "dns.quad9.net"
# Quad 9 Secure Primary
# - address_data: 2620:fe::fe
# tls_auth_name: "dns.quad9.net"
# Cloudflare Primary IPv4
- address_data: 1.1.1.1
tls_auth_name: "cloudflare-dns.com"
# Cloudflare Secondary IPv4
- address_data: 1.0.0.1
tls_auth_name: "cloudflare-dns.com"
# Cloudflare Primary IPv6
- address_data: 2606:4700:4700::1111
tls_auth_name: "cloudflare-dns.com"
# Cloudflare Secondary IPv6
- address_data: 2606:4700:4700::1001
tls_auth_name: "cloudflare-dns.com"
 
The stubby installer enables both the IPv4 and IPv6 address for Cloudflare DNS in /opt/etc/stubby/stubby.yml. If you don't use IPv6, then extra noise is created by stubby when trying to handshake with the IPv6 resolver address as shown below.

Code: 
 stubby -l
[01:04:12.802077] STUBBY: Read config from file /opt/etc/stubby/stubby.yml
[01:04:12.803507] STUBBY: DNSSEC Validation is ON
[01:04:12.803558] STUBBY: Transport list is:
[01:04:12.803572] STUBBY:   - TLS
[01:04:12.803586] STUBBY: Privacy Usage Profile is Strict (Authentication required)
[01:04:12.803598] STUBBY: (NOTE a Strict Profile only applies when TLS is the ONLY transport!!)
[01:04:12.803609] STUBBY: Starting DAEMON....
[01:04:14.434282] STUBBY: --- SETUP(TLS): : Verify locations loaded
[01:04:14.434785] STUBBY: 1.1.1.1                                  : Conn opened: TLS - Strict Profile
[01:04:14.502958] STUBBY: 1.1.1.1                                  : Verify passed : TLS
[01:04:14.516541] STUBBY: 1.0.0.1                                  : Conn opened: TLS - Strict Profile
[01:04:14.516665] STUBBY: 2606:4700:4700::1111                     : Conn closed: TLS - Resps=     0, Timeouts  =     0, Curr_auth =   None, Keepalive(ms)=     0
[01:04:14.516691] STUBBY: 2606:4700:4700::1111                     : Upstream   : TLS - Resps=     0, Timeouts  =     0, Best_auth =   None
[01:04:14.516705] STUBBY: 2606:4700:4700::1111                     : Upstream   : TLS - Conns=     0, Conn_fails=     1, Conn_shuts=      0, Backoffs     =     0
[01:04:14.516743] STUBBY: 2606:4700:4700::1001                     : Conn closed: TLS - Resps=     0, Timeouts  =     0, Curr_auth =   None, Keepalive(ms)=     0
[01:04:14.516763] STUBBY: 2606:4700:4700::1001                     : Upstream   : TLS - Resps=     0, Timeouts  =     0, Best_auth =   None
[01:04:14.516776] STUBBY: 2606:4700:4700::1001                     : Upstream   : TLS - Conns=     0, Conn_fails=     1, Conn_shuts=      0, Backoffs     =     0

If you use IPv4, I recommend you comment out the Cloudflare IPv6 lines by adding a # sign in the front of the line or delete the lines entirely. Similarly, if you use IPv6, then comment out or delete the IPv4 lines. Remember to restart stubby after making the change. /opt/etc/init.d/S61stubby restart

Code: 
# Cloudflare Primary IPv4
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
# Cloudflare Secondary IPv4
  - address_data: 1.0.0.1
    tls_auth_name: "cloudflare-dns.com"
# Cloudflare Primary IPv6
#  - address_data: 2606:4700:4700::1111
#    tls_auth_name: "cloudflare-dns.com"
# Cloudflare Secondary IPv6
#  - address_data: 2606:4700:4700::1001
#    tls_auth_name: "cloudflare-dns.com"

May need to add a function to the installer script to detect what IP protocol the router is using and comment out or not include the IP protocol that is not being used.
 
Xentrk said:
Something is not right.
Code: 
stubby -i | grep -i dnssec
[03:06:16.655350] STUBBY: Read config from file /opt/etc/stubby/stubby.yml
Result: Config file syntax is valid.

Looks like an error in stubby.yml - Result: Config file syntax is valid. The test site should have passed the test as being connected to 1.1.1.1.

Try using the stubby.yml below

tls_ca_file: "/rom/etc/ssl/certs/ca-certificates.crt"
resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
- GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
dnssec_return_status: GETDNS_EXTENSION_TRUE
tls_query_padding_blocksize: 128
edns_client_subnet_private : 1
round_robin_upstreams: 1
idle_timeout: 2000
tls_connection_retries: 5
tls_backoff_time: 900
timeout: 2000
appdata_dir: "/opt/var/cache/stubby"
listen_addresses:
- 127.0.0.1@5453
- 0::1@5453

upstream_recursive_servers:
# Quad 9 Secure Primary
# - address_data: 9.9.9.9
# tls_auth_name: "dns.quad9.net"
# Quad 9 Secure Primary
# - address_data: 2620:fe::fe
# tls_auth_name: "dns.quad9.net"
# Cloudflare Primary IPv4
- address_data: 1.1.1.1
tls_auth_name: "cloudflare-dns.com"
# Cloudflare Secondary IPv4
- address_data: 1.0.0.1
tls_auth_name: "cloudflare-dns.com"
# Cloudflare Primary IPv6
- address_data: 2606:4700:4700::1111
tls_auth_name: "cloudflare-dns.com"
# Cloudflare Secondary IPv6
- address_data: 2606:4700:4700::1001
tls_auth_name: "cloudflare-dns.com"
Click to expand...

Tried this and after restarting Stubby it failed. Had to delete Stubby and reinstalled again.
 
This is from regular install. My DNSSEC validation remains OFF

Code: 
@RT-AX88U-29F0:/tmp/home/root# stubby -l
[01:24:27.580431] STUBBY: Read config from file /opt/etc/stubby/stubby.yml
[01:24:27.581042] STUBBY: DNSSEC Validation is OFF
[01:24:27.581071] STUBBY: Transport list is:
[01:24:27.581085] STUBBY:   - TLS
[01:24:27.581100] STUBBY: Privacy Usage Profile is Strict (Authentication required)
[01:24:27.581115] STUBBY: (NOTE a Strict Profile only applies when TLS is the ONLY transport!!)
[01:24:27.581129] STUBBY: Starting DAEMON....
[01:24:34.045393] STUBBY: --- SETUP(TLS): : Verify locations loaded
[01:24:34.045814] STUBBY: 1.1.1.1                                  : Conn opened: TLS - Strict Profile
[01:24:34.098634] STUBBY: 1.1.1.1                                  : Verify passed : TLS
[01:24:34.184136] STUBBY: 1.0.0.1
 
Ok, went back and added in stubby.yml

Code: 
dnssec_return_status: GETDNS_EXTENSION_TRUE

and now getting this (whew!!):

Code: 
RT-AX88U-29F0:/tmp/home/root# stubby -l
[01:32:32.790437] STUBBY: Read config from file /opt/etc/stubby/stubby.yml
[01:32:32.791485] STUBBY: DNSSEC Validation is ON
[01:32:32.791643] STUBBY: Transport list is:
[01:32:32.791764] STUBBY:   - TLS
[01:32:32.791791] STUBBY: Privacy Usage Profile is Strict (Authentication required)
[01:32:32.791807] STUBBY: (NOTE a Strict Profile only applies when TLS is the ONLY transport!!)
[01:32:32.791822] STUBBY: Starting DAEMON....
[01:32:33.924875] STUBBY: --- SETUP(TLS): : Verify locations loaded
[01:32:33.925261] STUBBY: 1.1.1.1                                  : Conn opened: TLS - Strict Profile
[01:32:33.925544] STUBBY: 1.0.0.1                                  : Conn opened: TLS - Strict Profile
[01:32:33.925709] STUBBY: 2606:4700:4700::1111                     : Conn clo
 
....and then :):

upload_2019-3-14_20-41-10.png
 
Xentrk said:
The stubby installer enables both the IPv4 and IPv6 address for Cloudflare DNS in /opt/etc/stubby/stubby.yml. If you don't use IPv6, then extra noise is created by stubby when trying to handshake with the IPv6 resolver address as shown below.

Code: 
 stubby -l
[01:04:12.802077] STUBBY: Read config from file /opt/etc/stubby/stubby.yml
[01:04:12.803507] STUBBY: DNSSEC Validation is ON
[01:04:12.803558] STUBBY: Transport list is:
[01:04:12.803572] STUBBY:   - TLS
[01:04:12.803586] STUBBY: Privacy Usage Profile is Strict (Authentication required)
[01:04:12.803598] STUBBY: (NOTE a Strict Profile only applies when TLS is the ONLY transport!!)
[01:04:12.803609] STUBBY: Starting DAEMON....
[01:04:14.434282] STUBBY: --- SETUP(TLS): : Verify locations loaded
[01:04:14.434785] STUBBY: 1.1.1.1                                  : Conn opened: TLS - Strict Profile
[01:04:14.502958] STUBBY: 1.1.1.1                                  : Verify passed : TLS
[01:04:14.516541] STUBBY: 1.0.0.1                                  : Conn opened: TLS - Strict Profile
[01:04:14.516665] STUBBY: 2606:4700:4700::1111                     : Conn closed: TLS - Resps=     0, Timeouts  =     0, Curr_auth =   None, Keepalive(ms)=     0
[01:04:14.516691] STUBBY: 2606:4700:4700::1111                     : Upstream   : TLS - Resps=     0, Timeouts  =     0, Best_auth =   None
[01:04:14.516705] STUBBY: 2606:4700:4700::1111                     : Upstream   : TLS - Conns=     0, Conn_fails=     1, Conn_shuts=      0, Backoffs     =     0
[01:04:14.516743] STUBBY: 2606:4700:4700::1001                     : Conn closed: TLS - Resps=     0, Timeouts  =     0, Curr_auth =   None, Keepalive(ms)=     0
[01:04:14.516763] STUBBY: 2606:4700:4700::1001                     : Upstream   : TLS - Resps=     0, Timeouts  =     0, Best_auth =   None
[01:04:14.516776] STUBBY: 2606:4700:4700::1001                     : Upstream   : TLS - Conns=     0, Conn_fails=     1, Conn_shuts=      0, Backoffs     =     0

If you use IPv4, I recommend you comment out the Cloudflare IPv6 lines by adding a # sign in the front of the line or delete the lines entirely. Similarly, if you use IPv6, then comment out or delete the IPv4 lines. Remember to restart stubby after making the change. /opt/etc/init.d/S61stubby restart

Code: 
# Cloudflare Primary IPv4
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
# Cloudflare Secondary IPv4
  - address_data: 1.0.0.1
    tls_auth_name: "cloudflare-dns.com"
# Cloudflare Primary IPv6
#  - address_data: 2606:4700:4700::1111
#    tls_auth_name: "cloudflare-dns.com"
# Cloudflare Secondary IPv6
#  - address_data: 2606:4700:4700::1001
#    tls_auth_name: "cloudflare-dns.com"

May need to add a function to the installer script to detect what IP protocol the router is using and comment out or not include the IP protocol that is not being used.
Click to expand...

Or just a question or two with the possible choices instead?

It would also be ideal if this can be changed later on if anything changes on the ISP too, without re-installing Stubby.
 
I am noticing a lot better performance when I changed
idle_timeout: 60000
 
shhhhh don't jinx me
 
If someone interested in forwarding stubby logging to the syslog (to have possibility store it in the remote syslog) - I have a solutions. At least two.
Both are related on bash, so you have to install bash via
Code: 
opkg install bash
  1. Simpler one, but with some overhead in the log, from the startup script.
    1. At first change the first line of S61stubby in /opt/etc/init.d from
      Code: 
      #!/bin/sh
      to
      Code: 
      #!/opt/bin/bash
    2. Insert additional line
      Code: 
      exec 1> >(logger -t $PROCS) 2>&1
      before last line
      Code: 
      . /opt/etc/init.d/rc.func
      to have at the end of file the next
      Code: 
      ...
exec 1> >(logger -t $PROCS) 2>&1
. /opt/etc/init.d/rc.func
    3. Delete forwarding the logging into the /dev/null in rc.func.
      I.e. comment existing
      Code: 
      $PREARGS $PROC $ARGS > /dev/null 2>&1 &
      and add new one
      Code: 
      $PREARGS $PROC $ARGS &
      to have
      Code: 
          #$PREARGS $PROC $ARGS > /dev/null 2>&1 &
    $PREARGS $PROC $ARGS  &
    4. Restart and check the syslog.
    5. You have to see something like:
      Code: 
      2019-03-16T14:00:44+02:00 192.168.99.1 S61stubby: restart Stubby DNS over TLS /opt/etc/init.d/S61stubby
2019-03-16T14:00:44+02:00 192.168.99.1 stubby: .[1;37m Starting stubby... .[m[12:00:44.301631] STUBBY: Read config from file /opt/etc/stubby/stubby.yml
2019-03-16T14:00:44+02:00 192.168.99.1 stubby:             .[1;32m done. .[m
  • Other one:
  1. Add new configuration variable FORCESYSLOG in the S61stubby in /opt/etc/init.d from. For example - after line with
    Code: 
    ENABLED=yes
    .
    Code: 
    ...
ENABLED=yes
FORCESYSLOG=yes
...
  2. Replace
    Code: 
    $PREARGS $PROC $ARGS > /dev/null 2>&1 &
    in rc.func with next code
    Code: 
        if [ "$FORCESYSLOG" = "yes" ] && [ -x /opt/bin/bash ] ; then
        cat >/tmp/temp.start.$PROC.sh <<EOF
#!/opt/bin/bash
exec 1> >(logger -t $PROC) 2>&1
echo $PREARGS $PROC $ARGS
export TZ=$(cat /etc/TZ)
$PREARGS $PROC $ARGS &
EOF
        chmod o+x /tmp/temp.start.$PROC.sh
        /tmp/temp.start.$PROC.sh
        rm -f /tmp/temp.start.$PROC.sh
    else
        $PREARGS $PROC $ARGS > /dev/null 2>&1 &
    fi
  • Restart and check the syslog.
  • You have to see something like:
    Code: 
    2019-03-16T13:43:14+02:00 192.168.99.1 S62stubby: restart Stubby DNS over TLS /opt/etc/init.d/S62stubby
2019-03-16T13:43:14+02:00 192.168.99.1 stubby: [11:43:14.671496] STUBBY: Read config from file /opt/etc/stubby/stubby.yml
Important note - due to rc.func can be overwritten during opkg upgrade, I have to recommend to make a copy of it, name it rc.func.my (for example), and relay on it in the last line of your S61stubby.
There is a full list of my files, they are slightly different, taking an account the functionality to start dnsmasq with usual forward to usual dns, before the stubbly will be fully accessible.
P.S. Files uploaded with ".txt" extensions, due to regulation of the forum.
P.P.P.S. rc.func.my and S61stubby located in /opt/etc/init.d/, dnsmasq.postconf.my and dnsmasq.postconf.txt - in /jffs/scripts
 

Attachments

  • rc.func.my.txt
    3.3 KB · Views: 248
  • S61stubby.txt
    990 bytes · Views: 258
  • dnsmasq.postconf.my.txt
    967 bytes · Views: 249
  • dnsmasq.postconf.txt
    127 bytes · Views: 271
Does anybody have the same problem that with the 384.10_beta2 stubby is not starting anymore?
After flashing the new firmware and the reboot no dns resolving was possible anymore, also my router tells me that I am disconnected but I can see that I got an ip address. So I uninstalled stubby and after the reboot again dns was working. Installed it again over amtm and the installer told me that starting of stubby was not possible. Again dns did not work.
 
TheUntouchable said:
Does anybody have the same problem that with the 384.10_beta2 stubby is not starting anymore?
After flashing the new firmware and the reboot no dns resolving was possible anymore, also my router tells me that I am disconnected but I can see that I got an ip address. So I uninstalled stubby and after the reboot again dns was working. Installed it again over amtm and the installer told me that starting of stubby was not possible. Again dns did not work.
Click to expand...
Can you run this command please?
Code: 
stubby -C /opt/etc/stubby/stubby.yml -i
 
You must log in or register to reply here.

Similar threads

RMerlin
Release Asuswrt-Merlin 3006.102.1 is now available for Wifi 7 devices
4 5 6
Replies
106
Views
17K
jksmurf
J
RMerlin
ANNOUNCEMENT: Asuswrt-Merlin support underway for 3 Wifi 7 routers
5 6 7
Replies
130
Views
27K
scasapending
S
DMcD-EMS-USMC
  • Locked
3006.102 alpha 2 Build(s) Now Available
Replies
2
Views
1K
octopus
octopus
RMerlin
Release Asuswrt-Merlin 3006.102.2 is now available for Wifi 7 devices
2 3
Replies
55
Views
5K
FishBones
F
octopus
  • Locked
[ 3006.102 alpha Build(s) ] Testing available build(s)
2 3
Replies
59
Views
11K
octopus
octopus
Similar threads
Thread starter Title Forum Replies Date
RMerlin Release Asuswrt-Merlin 3006.102.2 is now available for Wifi 7 devices Asuswrt-Merlin 55
B Unable to establish VPN connection to my PiVPN (ovpn) from my Asus RT-AC86U running Asuswrt-Merlin 386.14 Asuswrt-Merlin 1
F Several Questions Re:Asuswrt-Merlin Feature Implementation Asuswrt-Merlin 2
Yota How to enable port randomization in Asuswrt-Merlin? Asuswrt-Merlin 4
RMerlin Beta Asuswrt-Merlin 3006.102.2 Beta is now available for Wifi 7 devices Asuswrt-Merlin 70
J Does Asuswrt-Merlin support AiMesh over Wifi? Asuswrt-Merlin 4
Siff Printing from Guest Network (ASUSWRT-Merlin 3004.388.8_2) Asuswrt-Merlin 5
Siff Setting dnsmasq on Asuswrt-Merlin Asuswrt-Merlin 8
Rob Bowlby fwupdate.asuswrt-merlin.net - diversion.ch Down? Asuswrt-Merlin 7
R Wireguard on Asuswrt-Merlin Asuswrt-Merlin 11

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: 678 (members: 28, guests: 650)
Top