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!

Xentrk

Xentrk

Part of the Furniture
Stubby is an application that acts as a local DNS Privacy stub resolver using DNS-over-TLS. Stubby encrypts DNS queries sent from a client machine to a DNS Privacy resolver increasing end user privacy.

Since Stubby is in the early stages of development, it may not be suitable for non-technical users. To assist users to implement Stubby, I wrote a Stubby installer script to make the process easier.

The install script defaults to Cloudflare (1.1.1.1) DNS-over-TLS on port 853. You can change to other supported public or test resolvers by updating the Stubby configuration file located in /opt/etc/stubby/stubby.yml.

All Asus models supported by Asuswrt-Merlin, should be supported by this script. To date, I have received confirmation that it works on the following models:
  • RT-AC66U_B1
  • RT-AC68U
  • RT-AC87U
  • RT-AC88U
  • RT-AC3100
  • RT-AC3200
  • RT-AC5300
  • RT-AC86U
  • RT-AX88U
  • GT-AC5300
For information on Stubby, including how to install and validate, visit the Stubby-Installer-Asuswrt-Merlin GitHub Repository.

For information on how the settings were derived at, see my blog post DNS over TLS with DNSMASQ and Stubby on Asuswrt-Merlin.

Installation
Using your preferred SSH client/terminal, copy and paste the following command, then press Enter:

Code: 
/usr/sbin/curl --retry 3 "https://raw.githubusercontent.com/Xentrk/Stubby-Installer-Asuswrt-Merlin/master/install_stubby.sh" -o "/jffs/scripts/install_stubby.sh" && chmod 755 /jffs/scripts/install_stubby.sh && sh /jffs/scripts/install_stubby.sh

Then, select the install option from the menu. You may also install Stubby using amtm - the SNBForum Asuswrt-Merlin Terminal Menu
 
Last edited:
Thanks for your efforts @Xentrk and for the opportunity to test the installer over the last weeks. Stubby has been running great on my RT-AC68U for days now!
 
Haven’t test the installer.

Just checking.
Does Cloudflare help page ok with dnssec validation enabled via stubby?

It works if I enable dnssec validation via firmware with check unsigned off.
 
DonnyJohnny said:
Haven’t test the installer.

Just checking.
Does Cloudflare help page ok with dnssec validation enabled via stubby?

It works if I enable dnssec validation via firmware with check unsigned off.
Click to expand...
I was wondering when that question was going to come up :) DNSSEC is not enabled on the Cloudflare test page. Here is my journey regarding Stubby + 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.
Click to expand...

I am still troubled that I have no root anchor files appearing in the appdata_dir. Yet, the DNSSEC test sites all work. I saw several posts on other forums were others reported the same behavior.

This Firefox add-on will add an indicator on the browser to let you know if the site you are visiting supports DNSSEC.
https://addons.mozilla.org/en-US/firefox/addon/dnssec/
 
M@rco said:
The installer script disables the DNSSEC firmware setting and it should remain off. That way DNSSEC tests will succeed. If manually enabled in the UI, it will cause trouble as your tests will fail. See the Github page for more info: https://github.com/Xentrk/Stubby-Installer-Asuswrt-Merlin#dnssec
Click to expand...
Understand and the dnssec validation on firmware already been turn off before I enable it via stubby.
So question is how is it different from turning off via webgui vs disable via the installer script.

I added the following to enable dnssec via stubby.yml
dnssec_return_status: GETDNS_EXTENSION_TRUE

So did u get the AD flag when u use the following command?
dig pir.org +dnssec +multi

Link on how to test if dnssec is working
https://docs.menandmice.com/display/MM/How+to+test+DNSSEC+validation
 
Xentrk said:
I was wondering when that question was going to come up :) DNSSEC is not enabled on the Cloudflare test page. Here is my journey regarding Stubby + DNSSEC:



I am still troubled that I have no root anchor files appearing in the appdata_dir. Yet, the DNSSEC test sites all work. I saw several posts on other forums were others reported the same behavior.

This Firefox add-on will add an indicator on the browser to let you know if the site you are visiting supports DNSSEC.
https://addons.mozilla.org/en-US/firefox/addon/dnssec/
Click to expand...

The root anchor file will be loaded automatically when U load the dnssec validation via stubby. I check the appdata_dir before I enable dnssec validation and yes it is empty. Once I load up the dnssec validation via stubby, the files are there. As this are just temporary folder and it will be cleared once router restart unless stubby with dnssec validation load them back.

Question here is the dnssec validation via stubby (cloudflare) seems not working not only in the cloudflare help page. When i use the dig command to check for AD flag. It is not present too.
 
DNSSEC validation works for me:

Code: 
# dig asuswrt.lostrealm.ca @1.1.1.1 +dnssec +multi

; <<>> DiG 9.11.3 <<>> asuswrt.lostrealm.ca @1.1.1.1 +dnssec +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48040
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1452
;; QUESTION SECTION:
;asuswrt.lostrealm.ca.  IN A

;; ANSWER SECTION:
asuswrt.lostrealm.ca.   71 IN A 72.55.186.51
asuswrt.lostrealm.ca.   71 IN RRSIG A 13 3 300 (
                                20181023100445 20181021080445 35273 lostrealm.ca                                                                                                             .
                                JK2E4hS9CFtgV7osOXDMlxzkBKX/BQY7ih116SXlGhaN
                                Mb5YNE0xpELApdWHMKlRIYi+ZMsUCBQ92MebyzO2OQ== )

;; Query time: 12 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Mon Oct 22 09:08:34 UTC 2018
;; MSG SIZE  rcvd: 173
 
DonnyJohnny said:
The root anchor file will be loaded automatically when U load the dnssec validation via stubby. I check the appdata_dir before I enable dnssec validation and yes it is empty. Once I load up the dnssec validation via stubby, the files are there. As this are just temporary folder and it will be cleared once router restart unless stubby with dnssec validation load them back.

Question here is the dnssec validation via stubby (cloudflare) seems not working not only in the cloudflare help page. When i use the dig command to check for AD flag. It is not present too.
Click to expand...
When I add the parameter dnssec_return_status: GETDNS_EXTENSION_TRUE, all of the DNSSEC tests fail. Perhaps you can post your stubby.yml? I have been trying to recreate the scenario when I saw root anchor files in the appdata_dir with no luck. Luckily, I saved a backup to prove I had them at one time.

Perhaps this parameter was required in an earlier version of getdns that required the use of Unbound to specify the root anchors. Just a theory.

Code: 
 #drill -D asuswrt.lostrealm.ca @1.1.1.1
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 53236
;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; asuswrt.lostrealm.ca.        IN      A

;; ANSWER SECTION:
asuswrt.lostrealm.ca.   300     IN      A       72.55.186.51
asuswrt.lostrealm.ca.   300     IN      RRSIG   A 13 3 300 20181023100206 20181021080206 35273 lostrealm.ca. Vyo6xNB3ViMZhv/VhBURt6UaHdA5jfAH4VSzDB7bWITYbZVl6+5vzQUxPvSTa783WNE2WWPJ8rP1L0Ox4e7x9g==

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 17 msec
;; EDNS: version 0; flags: do ; udp: 4096
;; SERVER: 1.1.1.1
;; WHEN: Mon Oct 22 09:02:06 2018
;; MSG SIZE  rcvd: 173
 
DonnyJohnny said:
Understand and the dnssec validation on firmware already been turn off before I enable it via stubby.
So question is how is it different from turning off via webgui vs disable via the installer script.
Click to expand...
I use a nvram set command to turn off DNSSEC on the firmware:
Code: 
# Turn off DNSSEC setting in firmware
nvram set dnssec_enable="0"
nvram commit
 
Xentrk said:
When I add the parameter dnssec_return_status: GETDNS_EXTENSION_TRUE, all of the DNSSEC tests fail. Perhaps you can post your stubby.yml? I have been trying to recreate the scenario when I saw root anchor files in the appdata_dir with no luck. Luckily, I saved a backup to prove I had them at one time.
Click to expand...
That’s the problem. When u go directly via cloudflare, yes dnssec works. But not via stubby with dnssec validation enabled.

Don’t think we have difference in the yml
https://pastebin.com/raw/0T7GP7mS
 
Xentrk said:
I use a nvram set command to turn off DNSSEC on the firmware:
Code: 
# Turn off DNSSEC setting in firmware
nvram set dnssec_enable="0"
nvram commit
Click to expand...
Not think there make the difference.
So just to confirm if u get AD flag when using stubby dnssec validation enable?
 
M@rco said:
DNSSEC validation works for me:

Code: 
# dig asuswrt.lostrealm.ca @1.1.1.1 +dnssec +multi

; <<>> DiG 9.11.3 <<>> asuswrt.lostrealm.ca @1.1.1.1 +dnssec +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48040
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1452
;; QUESTION SECTION:
;asuswrt.lostrealm.ca.  IN A

;; ANSWER SECTION:
asuswrt.lostrealm.ca.   71 IN A 72.55.186.51
asuswrt.lostrealm.ca.   71 IN RRSIG A 13 3 300 (
                                20181023100445 20181021080445 35273 lostrealm.ca                                                                                                             .
                                JK2E4hS9CFtgV7osOXDMlxzkBKX/BQY7ih116SXlGhaN
                                Mb5YNE0xpELApdWHMKlRIYi+ZMsUCBQ92MebyzO2OQ== )

;; Query time: 12 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Mon Oct 22 09:08:34 UTC 2018
;; MSG SIZE  rcvd: 173
Click to expand...
Wrong test as u are not testing via stubby but via cf dns via port 53.

Try changing the @1.1.1.1 to @127.0.0.1 (assuming u using stubby/dnscrypt-proxy)
 
DonnyJohnny said:
Not think there make the difference.
So just to confirm if u get AD flag when using stubby dnssec validation enable?
Click to expand...

Yep, when I use the 127.0.0.1 there is no AD flag.

Code: 
drill -D asuswrt.lostrealm.ca @127.0.0.1
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 51894
;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; asuswrt.lostrealm.ca.        IN      A

;; ANSWER SECTION:
asuswrt.lostrealm.ca.   300     IN      A       72.55.186.51
asuswrt.lostrealm.ca.   300     IN      RRSIG   A 13 3 300 20181023100453 20181021080453 35273 lostrealm.ca. 2L9xcKA2PjvntO73GPtdfe05wIebCb1O88+TI038uK6iLji1OcC+q/n6R5gUUTAJQm4j6FuLkYQtFMJTFEqLMA==

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 97 msec
;; EDNS: version 0; flags: do ; udp: 1452
;; SERVER: 127.0.0.1
;; WHEN: Mon Oct 22 09:04:53 2018
;; MSG SIZE  rcvd: 213
Give me a few minutes to try your config. Don't see any thing different from what I have tried in the past.
 
I recognized that config from the other thread. dnssec_return_status: GETDNS_EXTENSION_TRUE is commented out in your stubby.yml!

Code: 
#dnssec_return_status: GETDNS_EXTENSION_TRUE
When I enable in stubby.yml, http://dnssec.vs.uni-due.de/ returns
upload_2018-10-22_16-39-53.png


The stubby devs told me not to use the SPKI in the stubby.yml file:
I would recommend NOT using SPKI pins for Cloudflare because they do not guarantee that they will not change and if they do change then this configuration will break.
Click to expand...
 

Attachments

  • upload_2018-10-22_16-39-45.png
    upload_2018-10-22_16-39-45.png
    69.2 KB · Views: 638
@DonnyJohnny.....BTW, thanks for posting the solution of using the LAN IP address for DNS1. I first used 127.0.0.1 but this prevents users from applying changes to the WAN gui page. I nicknamed the use of the LAN IP address for DNS1 "the DonnyJohnny method"! :D
 
I ran the drill again using TD.
Code: 
drill -TD asuswrt.lostrealm.ca @127.0.0.1
Warning: No trusted keys were given. Will not be able to verify authenticity!
;; Domain: .
;; Signature ok but no chain to a trusted key or ds record
[S] . 172800 IN DNSKEY 256 3 8 ;{id = 2134 (zsk), size = 2048b}
. 172800 IN DNSKEY 257 3 8 ;{id = 19036 (ksk), size = 2048b}
. 172800 IN DNSKEY 257 3 8 ;{id = 20326 (ksk), size = 2048b}
Checking if signing key is trusted:
New key: .      172800  IN      DNSKEY  256 3 8 AwEAAdp440E6Mz7c+Vl4sPd0lTv2Qnc85dTW64j0RDD7sS/zwxWDJ3QRES2VKDO0OXLMqVJSs2YCCSDKuZXpDPuf++YfAu0j7lzYYdWTGwyNZhEaXtMQJIKYB96pW6cRkiG2Dn8S2vvo/PxW9PKQsyLbtd8PcwWglHgReBVp7kEv/Dd+3b3YMukt4jnWgDUddAySg558Zld+c9eGWkgWoOiuhg4rQRkFstMX1pRyOSHcZuH38o1WcsT4y3eT0U/SR6TOSLIB/8Ftirux/h297oS7tCcwSPt0wwry5OFNTlfMo8v7WGurogfk8hPipf7TTKHIi20LWen5RCsvYsQBkYGpF78= ;{id = 2134 (zsk), size = 2048b}
[S] ca. 86400 IN DS 2134 8 2 4b8475c0c0fe2afdfee1a71a237c91059098d12fc18265b290edb238a5f63582
;; Domain: ca.
;; Signature ok but no chain to a trusted key or ds record
[S] ca. 3600 IN DNSKEY 256 3 8 ;{id = 35433 (zsk), size = 1024b}
ca. 3600 IN DNSKEY 257 3 8 ;{id = 2134 (ksk), size = 2048b}
ca. 3600 IN DNSKEY 256 3 8 ;{id = 43854 (zsk), size = 1024b}
Checking if signing key is trusted:
New key: ca.    3600    IN      DNSKEY  256 3 8 AwEAAdv1tDhjeFHA6WYgNcxHxFLQAegMnIfy4Wo715kdVp2A6E+l/YvxvDq6Bdt8QBqwT0LyQiESwedlM/XN9qGgIWdJGWPzkmFs+qpiHgUGM/vEScUHj5GT4URssB1Vef7HO9Fz4Dysqa7rzVSmbQWpUDacTqd7rppBgZkYU7ltQlPx ;{id = 35433 (zsk), size = 1024b}
[S] lostrealm.ca. 86400 IN DS 2371 13 2 bb76fdbe44bc95b938f057665d9f94ff72e624078bfa8d067c00ebc6f6e93a42
;; Domain: lostrealm.ca.
[B] lostrealm.ca. 3600 IN DNSKEY 257 3 13 ;{id = 2371 (ksk), size = 0b}
lostrealm.ca. 3600 IN DNSKEY 256 3 13 ;{id = 35273 (zsk), size = 0b}
lostrealm.ca. 3600 IN DNSKEY 256 3 13 ;{id = 34505 (zsk), size = 0b}
[B] Error verifying denial of existence for asuswrt.lostrealm.ca. DS: Unknown cryptographic algorithm
;; No ds record for delegation
;; Domain: asuswrt.lostrealm.ca.
;; No DNSKEY record found for asuswrt.lostrealm.ca.
[B] asuswrt.lostrealm.ca.       300     IN      A       72.55.186.51
;; Error: Unknown cryptographic algorithm
;;[S] self sig OK; [B] bogus; [T] trusted

In this command, I specify the root key file that I had saved from earlier testing.
Code: 
drill -k /opt/var/cache/stubby-bkup/root.key -TD asuswrt.lostrealm.ca @127.0.0.1
;; Number of trusted keys: 4
;; Domain: .
[T] . 172800 IN DNSKEY 256 3 8 ;{id = 2134 (zsk), size = 2048b}
. 172800 IN DNSKEY 257 3 8 ;{id = 19036 (ksk), size = 2048b}
. 172800 IN DNSKEY 257 3 8 ;{id = 20326 (ksk), size = 2048b}
Checking if signing key is trusted:
New key: .      172800  IN      DNSKEY  256 3 8 AwEAAdp440E6Mz7c+Vl4sPd0lTv2Qnc85dTW64j0RDD7sS/zwxWDJ3QRES2VKDO0OXLMqVJSs2YCCSDKuZXpDPuf++YfAu0j7lzYYdWTGwyNZhEaXtMQJIKYB96pW6cRkiG2Dn8S2vvo/PxW9PKQsyLbtd8PcwWglHgReBVp7kEv/Dd+3b3YMukt4jnWgDUddAySg558Zld+c9eGWkgWoOiuhg4rQRkFstMX1pRyOSHcZuH38o1WcsT4y3eT0U/SR6TOSLIB/8Ftirux/h297oS7tCcwSPt0wwry5OFNTlfMo8v7WGurogfk8hPipf7TTKHIi20LWen5RCsvYsQBkYGpF78= ;{id = 2134 (zsk), size = 2048b}
        Trusted key: .  4521    IN      DNSKEY  256 3 8 AwEAAfaifSqh+9ItxYRCwuiY0FY2NkaEwd/zmyVvakixDgTOkgG/PUzlEauAiKzlxGwezjqbKFPSwrY3qHmbbsSTY6G8hZtna8k26eCwy59Chh573cu8qtBkmUIXMYG3fSdlUReP+uhBWBfKI2aGwhRmQYR0zSmg7PGOde34c/rOItK1ebJhjTAJ6TmnON7qMfk/lKvH4qOvYtzstLhr7Pn9ZOVLx/WUKQpU/nEyFyTduRbz1nZqkp6yMuHwWVsABK8lUYXSaUrDAsuMSldhafmR/A15BxNhv9M7mzJj7UH2RVME9JbYinBEzWwW9GpnY+ZmBWgZiRVTaDuemCTJ5ZJWLRs= ;{id = 41656 (zsk), size = 2048b}
        Trusted key: .  4521    IN      DNSKEY  257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= ;{id = 19036 (ksk), size = 2048b}
        Trusted key: .  4521    IN      DNSKEY  257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ;{id = 20326 (ksk), size = 2048b}
<snip>
 
observations i found during my own setup
1. CF's help page is useful to check that DoT is setup proper ONLY; this will require DNSSEC to be disabled
2. when DNSSEC is enabled, CF's help page will return failure for the debug information
3. for DIG queries to return AD flag proper, the router's DNSSEC must be turned on

Code: 
admin@RT-AC68U:/tmp/home/root# dig asuswrt.lostrealm.ca +dnssec +multi
; <<>> DiG 9.11.3 <<>> asuswrt.lostrealm.ca +dnssec +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11912
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;asuswrt.lostrealm.ca.  IN A
;; ANSWER SECTION:
asuswrt.lostrealm.ca.   291 IN A 72.55.186.51
asuswrt.lostrealm.ca.   291 IN RRSIG A 13 3 300 (
                                20181023110229 20181021090229 35273 lostrealm.ca.
                                IwPylutUIxLDkRNGVEX/+BPPlU2t3XuYsrUo09iI1GRU
                                /ulTv2i8IXI6YNjv5FjJHzuXsOhffiVRLt/bBadh+A== )
;; Query time: 21 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Oct 22 18:02:38 +08 2018
;; MSG SIZE  rcvd: 173

Code: 
Oct 22 17:59:48 dnsmasq[30921]: query[A] asuswrt.lostrealm.ca from 127.0.0.1
Oct 22 17:59:48 dnsmasq[30921]: forwarded asuswrt.lostrealm.ca to 127.0.0.1
Oct 22 17:59:48 dnsmasq[30921]: validation result is SECURE
Oct 22 17:59:48 dnsmasq[30921]: reply asuswrt.lostrealm.ca is 72.55.186.51
 
DonnyJohnny said:
Wrong test as u are not testing via stubby but via cf dns via port 53.

Try changing the @1.1.1.1 to @127.0.0.1 (assuming u using stubby/dnscrypt-proxy)
Click to expand...

These iptables to redirect everything to stubby are in place:

Code: 
# Force Client DNS requests to use Stubby
iptables -t nat -A PREROUTING -i br0 -p udp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)"
iptables -t nat -A PREROUTING -i br0 -p tcp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)"

However, running with @127.0.0.1 indeed fails:

Code: 
# dig asuswrt.lostrealm.ca @127.0.0.1 +dnssec +multi

; <<>> DiG 9.11.3 <<>> asuswrt.lostrealm.ca @127.0.0.1 +dnssec +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1950
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1452
;; QUESTION SECTION:
;asuswrt.lostrealm.ca.  IN A

;; ANSWER SECTION:
asuswrt.lostrealm.ca.   164 IN A 72.55.186.51
asuswrt.lostrealm.ca.   164 IN RRSIG A 13 3 300 (
                                20181023110146 20181021090146 35273 lostrealm.ca.
                                4d0TFNjIqkyCnOIZhc1sis9ElTT50mziKqFKZ1WNa1xm
                                wpEgJs+BrYltFNVvxWzONpydai5DqbQex758EHPylw== )

;; Query time: 13 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Oct 22 10:04:02 UTC 2018
;; MSG SIZE  rcvd: 213

Do you have a solution @DonnyJohnny?
 
Xentrk said:
I recognized that config from the other thread. dnssec_return_status: GETDNS_EXTENSION_TRUE is commented out in your stubby.yml!

Code: 
#dnssec_return_status: GETDNS_EXTENSION_TRUE
When I enable in stubby.yml, http://dnssec.vs.uni-due.de/ returns
View attachment 14871

The stubby devs told me not to use the SPKI in the stubby.yml file:
Click to expand...
Commented out coz I using firmware dnssec validation.

Regards the spki, I understand and I know it will work without specifying spki. Don’t really understand the need of SPKI but I read in the DOT paper, supposed need to specify SPKI.
 
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
16K
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
octopus
  • Locked
[ 3006.102 alpha Build(s) ] Testing available build(s)
2 3
Replies
59
Views
11K
octopus
octopus
RMerlin
  • Locked
Beta Asuswrt-Merlin 3006.102.1 Beta is now available for WIfi 7 devices
3 4 5
Replies
97
Views
14K
RMerlin
RMerlin
Similar threads
Thread starter Title Forum Replies Date
RMerlin Release Asuswrt-Merlin 3006.102.2 is now available for Wifi 7 devices Asuswrt-Merlin 28
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: 563 (members: 22, guests: 541)
Top