Stubby-Installer-Asuswrt-Merlin

[Marin]

View attachment 16543

So does this setting get changed when installing stubby?

and do these settings also look correct?
View attachment 16544

The reason why I ask is because whenever the router reboots I am noticing a delay in establishing connection to the internet after router reboots?

Yes, this is what is supposed to happen. When you install Stubby your router’s IP is automatically added to DNS 1 line.

Your DNSSEC section in GUI is deactivated automatically but it is activated in Stubby so no concerns there. Leave that setting in GUI as is.

Also, consider changing the “Rebind Protection” setting to Yes (on your last pic).






Sent from my iPhone using Tapatalk

 

[PeterV]

View attachment 16543
The reason why I ask is because whenever the router reboots I am noticing a delay in establishing connection to the internet after router reboots?

I can propose a solution for such case, mostly - to dns resolving before stubby will start.

Two steps - insert a post command to the stubby start script - i.e. /opt/etc/init.d/S61stubby.
Configure appropriate commands in the /jffs/scripts/dnsmasq.postconf
S61stubby:
Insert

POSTCMD="/sbin/service restart_dnsmasq"

in between

PREARGS="nohup"
DESC=$PROCS

, the full file will be equal to:

#!/bin/sh
# Wait for NTP before starting
ntptimer=0
while [ "$(nvram get ntp_ready)" = "0" ] && [ "$ntptimer" -lt "300" ]; do
ntptimer=$((ntptimer+1))
sleep 1
done
if [ "$ntptimer" -ge "300" ]; then logger -st S61stubby "[*] NTP Failed To Start After 5 Minutes - Please Fix Immediately!"; echo; exit 1; fi
logger -t S61stubby "$1 Stubby DNS over TLS $0"
# set environment PATH to system binaries
export PATH=/sbin:/bin:/usr/sbin:/usr/bin:$PATH
export TZ=$(cat /etc/TZ)
ENABLED=yes
PROCS=stubby
ARGS="-g -v 5 -C /opt/etc/stubby/stubby.yml 2>/opt/var/log/stubby.log"
PREARGS="nohup"
POSTCMD="/sbin/service restart_dnsmasq"
DESC=$PROCS
PATH=/opt/sbin:/opt/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
. /opt/etc/init.d/rc.func

/jffs/scripts/dnsmasq.postconf

#!/bin/sh
SERVICE="${0##*/}"
CONFIG=$1
DEFAULT_DNS="server=8.8.8.8"
DEFAULT_OPTIONS="$(cat <<EOFD
#
EOFD
)"
STUBBY_RC="/opt/etc/init.d/S61stubby"
STUBBY_DNS="server=127.0.0.1#5453"
STUBBY_OPTIONS="$(cat <<EOFS
# Enable proxying DNSSEC.
proxy-dnssec
EOFS
)"
. /usr/sbin/helper.sh
pc_append "##"  $CONFIG
pc_append "# Default DNS server directives #"  $CONFIG
pc_append "#"  $CONFIG
[ -x ${STUBBY_RC} ] && ${STUBBY_RC} check
if [ $? -eq 0 ] ; then
    logger -t $SERVICE "Stubby is installed and running. Applying forward via stubby."
    pc_append "# Forward rule for stubby #"  $CONFIG
    pc_append "${STUBBY_DNS}" $CONFIG
    pc_append "${STUBBY_OPTIONS}" $CONFIG
else
    logger -t $SERVICE "Stubby is not installed or not is running. Applying forward via default DNS."
    pc_append "${DEFAULT_DNS}" $CONFIG
    pc_append "${DEFAULT_OPTIONS}" $CONFIG
fi
pc_append "#"  $CONFIG
pc_append "# End of Default DNS server directives #"  $CONFIG
pc_append "##"  $CONFIG

If you are using Diversion - you can add everything from this file (except first line) at the end of existing.
Otherwise - create new file and make it executable.

How it works :
On first dnsmasq start it will be configured to forward all requests to the DEFAULT_DNS, in this example -to google. You can change the ip by what you prefer (cloudflare, for example).
After the stubby will start, the postcmd will be executed, and dnsmasq will be reconfigured to use stubby.

 

[Swistheater]

Yes, this is what is supposed to happen. When you install Stubby your router’s IP is automatically added to DNS 1 line.

Your DNSSEC section in GUI is deactivated automatically but it is activated in Stubby so no concerns there. Leave that setting in GUI as is.

Also, consider changing the “Rebind Protection” setting to Yes (on your last pic).






Sent from my iPhone using Tapatalk

New question, I am testing out

I want to know what it means when it says it may prevent upstream browser from resolving queries from any nonroutable ip.

 

[bbunge]

Your DNSSEC section in GUI is deactivated automatically but it is activated in Stubby so no concerns there. Leave that setting in GUI as is.

No, DNSSEC is not automatically enabled in Stubby. You can use the Enable DNSSEC support in the Merlin GUI or add this to syubby.yml:

dnssec_return_status: GETDNS_EXTENSION_TRUE

Either method works, although some resolvers do not fully support DNSSEC. I have the best results by adding the entry to stubby.yml with Cloudflare resolvers. Have tested this with Quad9 and CleanBrowsing and have had connection failures from time to time.

 

[Marin]

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

 

[bbunge]

I want to know what it means when it says it may prevent upstream browser from resolving queries from any nonroutable ip.

https://en.wikipedia.org/wiki/DNS_rebinding

 

[Marin]

No, DNSSEC is not automatically enabled in Stubby. You can use the Enable DNSSEC support in the Merlin GUI or add this to syubby.yml:

dnssec_return_status: GETDNS_EXTENSION_TRUE

Either method works, although some resolvers do not fully support DNSSEC. I have the best results by adding the entry to stubby.yml with Cloudflare resolvers. Have tested this with Quad9 and CleanBrowsing and have had connection failures from time to time.

Mine installed automatically after installing Stubby and one in the GUI was unchecked during the installation process. Never had to do what you describe separately.

 

[Marin]

From: https://github.com/Xentrk/Stubby-Installer-Asuswrt-Merlin

DNSSEC
The install_stubby.sh script turns off the DNSSEC setting on the firmware to avoid conflicts with DNSSEC built into Stubby. Stubby uses getdns to manage DNSSEC. getdns uses a form of built-in trust-anchor management modeled on RFC7958, named Zero configuration DNSSEC. If you turn on the firmware DNSSEC, the Cloudflare Help Page test page will not work. Early in my testing, I had root anchor files in the appdata_dir directory /opt/var/cache/stubby. Later in my testing, no root anchor files appeared in the appdata_dir directory. I created an issue with the Stubby support team. However, I did not receive a reply from my updates. Since the DNSSEC test sites worked, I closed the issue

 

[EmeraldDeer]

From: https://github.com/Xentrk/Stubby-Installer-Asuswrt-Merlin

DNSSEC
The install_stubby.sh script turns off the DNSSEC setting on the firmware to avoid conflicts with DNSSEC built into Stubby. Stubby uses getdns to manage DNSSEC. getdns uses a form of built-in trust-anchor management modeled on RFC7958, named Zero configuration DNSSEC. If you turn on the firmware DNSSEC, the Cloudflare Help Page test page will not work. Early in my testing, I had root anchor files in the appdata_dir directory /opt/var/cache/stubby. Later in my testing, no root anchor files appeared in the appdata_dir directory. I created an issue with the Stubby support team. However, I did not receive a reply from my updates. Since the DNSSEC test sites worked, I closed the issue

If I recall correctly about the default Stubby configuration:

• DNSSEC as managed by the router is indeed disabled as described above
• DNSSEC does work by default and it is by proxy to Cloudflare
• Cloudflare is doing all of the DNSSEC traffic and verification and setting a bit in the DNS replies
• If you look in dnsmasq.log there is no DNSSEC traffic yet DNSSEC test sites say you're good. For example, http://dnssec.vs.uni-due.de/

# grep proxy /etc/dnsmasq.conf
proxy-dnssec

It does not appear to depend upon getdns_extension. Hmm.

# stubby -i | grep -i dnssec
[23:20:22.561267] 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_FALSE,
    "dnssec_return_validation_chain": GETDNS_EXTENSION_FALSE,
    "trust_anchors_verify_email": <bindata of "dnssec@iana.org">,

 

[bbunge]

Folks, we have been over this time and time again.

1. DNSSEC resolver tests such as http://dnssec.vs.uni-due.de/ only test if the resolver (DNS server) is capable of doing DNSSEC. Does not test if DNSSEC validation is working on your end. You need to use Dig to test this (and I have suspisions if Dig really proves your end works!).

2. To enable DNSSEC in Stubby:

############################### DNSSEC SETTINGS ################################
# Require DNSSEC validation. This will withhold answers with BOGUS DNSSEC
# status and answers that could not be validated (i.e. with DNSSEC status
# INDETERMINATE). Beware that if no DNSSEC trust-anchor is provided, or if
# stubby is not able to fetch and validate the DNSSEC trust-anchor itself,
# (using Zero configuration DNSSEC) stubby will not return answers at all.
# If DNSSEC validation is required, a trust-anchor is also required.
# dnssec: GETDNS_EXTENSION_TRUE

See: https://github.com/getdnsapi/stubby/blob/develop/stubby.yml.example.

 

[vesalius]

@EmeraldDeer and @Marin

Here, https://www.snbforums.com/threads/stubby-installer-asuswrt-merlin.49469/page-34#post-459644 , is the concise answer to your DNSSEC questions.

So manually adding "dnssec: GETDNS_EXTENSION_TRUE" to your stubby.yml forces your Router to also validate dnssec. The ASUS stubby installer will not in it's current form make this addition to the Stubby.yml

- DNS resolver and Router both independently validate DNSSEC

Answering "yes" to Enable proxying DNSSEC during the ASUS STubby installers runtime or reconfiguration menu will accept your resolvers DNSSEC validation without the router validating the last mile

- DNS resolver (for example Cloudflare) validates DNSSEC and router blindly accepts the answer.

 

[Xentrk]

Disabling DSNSEC in the GUI was a decision I made before going live with the installer script. Here is the issue: with DNSSEC enabled, the validation test using https://1.1.1.1/help will report that DNS over TLS is not working. This issue is the https://1.1.1.1/help site does not support DNSSEC. My concern is there would then be many posts on the site complaining that Stubby DNS over TLS is not working when in reality it is working.

Note the red DNS in the URL bar. This is the DNSSEC plug-in available in Firefox. If the color is red, the site does not support DNSSEC. If the color is green, then the site supports DNSSEC.

I just added DNSSEC support to my blog site. Note the green color for DNS! After adding the plug-in, I was surprised that many of the sites I use DO NOT support DNSSEC.

Perhaps we can modify the installer script and prompt the user if they want the DNSSEC setting in Stubby enabled followed by a message that the https://1.1.1.1/help site will report a false DNS over TLS status. I am open to suggestions. I will see if there is a way to create a support request with Cloudflare to see if they can enable DNSSEC on their help site.

For stats on the number of sites that support DNSSEC https://www.internetsociety.org/deploy360/dnssec/statistics/

Another good article Why DNSSEC deployment remains so low

 

[L&LD]

Xentrk, if you do give us the option to enable DNSSEC via the Stubby installer, please include the last paragraph too so that people can't complain!

 

[bbunge]

Xentrk, if you do give us the option to enable DNSSEC via the Stubby installer, please include the last paragraph too so that people can't complain!

Ah... but people will complain even if you hang them with a new rope!

Sent from my SM-T380 using Tapatalk

 

[L&LD]

bbunge, lol...

 

[Marin]

So....and until a decision is made on updating the script or not, what is the verdict on adding the:

dnssec_return_status: GETDNS_EXTENSION_TRUE

?

Add it to:

/jffs/configs/dnsmasq.conf.add (along with proxy-dnssec)

or

/opt/etc/stubby/stubby.yml (anywhere in the script?)

Some folks have mentioned doing this on the yml.file; github info talks about the config file

What tests can we use (with both proxy-dnssec and above dnssec_return_status: GETDNS_EXTENSION_TRUE) to validate what we are doing?

 

[bbunge]

So....and until a decision is made on updating the script or not, what is the verdict on adding the:

dnssec_return_status: GETDNS_EXTENSION_TRUE

?

Add it to:

/jffs/configs/dnsmasq.conf.add (along with proxy-dnssec)

or

/opt/etc/stubby/stubby.yml (anywhere in the script?)

Some folks have mentioned doing this on the yml.file; github info talks about the config file

What tests can we use (with both proxy-dnssec and above dnssec_return_status: GETDNS_EXTENSION_TRUE) to validate what we are doing?

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

 

[Xentrk]

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.

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:

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.

 

[L&LD]

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.

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:

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.

I found the drill package here https://gist.github.com/dvessel/5230459

How do I install it?

 

[Xentrk]

I found the drill package here https://gist.github.com/dvessel/5230459

How do I install it?

Install from entware using the command opkg install drill

The name drill is a pun on dig. With drill you should be able get even more information than with dig. dig is not included in entware.

See https://linux.die.net/man/1/drill for usage information.