1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
  2. 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!

    Dismiss Notice
Dismiss Notice

Welcome To SNBForums

SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.

If you'd like to post a question, simply register and have at it!

While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!

Stubby-Installer-Asuswrt-Merlin

Discussion in 'Asuswrt-Merlin' started by Xentrk, Oct 22, 2018.

  1. DonnyJohnny

    DonnyJohnny Very Senior Member

    Joined:
    Dec 17, 2017
    Messages:
    742
    Understand about the iptables divert but coz the dig command specifically asking it to resolve via 1.1.1.1
    Anyway currently only way is use firmware dnssec validation with strict unsigned validation set to NO.

    Technically, we should use strict unsigned validation to YES to maximum the objective of DNSSEC, as by setting strict validation to no mean unsigned dnssec will still still pass thru as insecure but valid.

    I am wondering if this is Cloudflare specific problem with dnssec validation.
    Maybe u can just try do some testing with other resolvers with strict validation set to YES
    https://dnsprivacy.org/wiki/plugins/servlet/mobile?contentId=1277971#content/view/1277971
     
    bbunge likes this.
  2. Xentrk

    Xentrk Part of the Furniture

    Joined:
    Jul 21, 2016
    Messages:
    2,635
    Location:
    The Land of Smiles
    (1) I did another test. I set dnssec_return_status: GETDNS_EXTENSION_TRUE in stubby.yml. I changed appdata_dir to point to the backup location containing the root key files. I bounced stubby. https://1.1.1.1/help fails the test. I do pass the DNSSEC tests on http://dnssec.vs.uni-due.de/ and https://rootcanary.org/test.html.

    No "ad" flag appears when I do a drill -D asuswrt.lostrealm.ca @127.0.0.1

    (2)I then commented out dnssec_return_status: GETDNS_EXTENSION_TRUE and kept the reference to the appdata_dir. https://1.1.1.1/help passes the test. I also pass the DNSSEC tests on http://dnssec.vs.uni-due.de/ and https://rootcanary.org/test.html.

    No "ad" flag appears when I do a drill -D asuswrt.lostrealm.ca @127.0.0.1

    (3) dnssec_return_status: GETDNS_EXTENSION_TRUE in no longer commented out. I changed the reference to the appdata_dir to /opt/var/cache/stubby (no root anchor files). https://1.1.1.1/help passes the test. I fail the DNSSEC tests on http://dnssec.vs.uni-due.de/ and https://rootcanary.org/test.html.

    No "ad" flag appears when I do a drill -D asuswrt.lostrealm.ca @127.0.0.


     
    Last edited: Oct 22, 2018
  3. thelonelycoder

    thelonelycoder Part of the Furniture

    Joined:
    Jan 23, 2014
    Messages:
    6,360
    Location:
    Switzerland
    Congrats @Xentrk for your release.
    This sure will make it into amtm as soon as the RT-AC86U problem is solved. I will also rejoin the testing once you have figured out what's causing the stoppages.
     
  4. DonnyJohnny

    DonnyJohnny Very Senior Member

    Joined:
    Dec 17, 2017
    Messages:
    742
    I have tested securedns.eu
    Using strict dnssec validation = YES.
    The result is good with AD flag.
    It seems like both Quad9 and Cloudflare has some misconfigurations causing them not about to have the strict dnssec validation.
     
    Xentrk likes this.
  5. bbunge

    bbunge Very Senior Member

    Joined:
    Aug 11, 2014
    Messages:
    1,022
    Location:
    Pennsylvania USA
    I had to reinstall Entware and Stubby after a thumb drive failure Saturday night. As of now I'm not running the changes that were made just before the release other than my modifications.
    I had noticed that the root.key seemed to update frequently when dnssec_return_status: GETDNS_EXTENSION_TRUE is enabled so I created /jffs/cache/stubby and set appdata_dir: "/jffs/cache/stubby" I seem to remember something about minimizing writes to thumb drives. May be just "old guy" thinking... Reads and writes are also faster to /jffs.

    Ah, I should also add that I've set my NTP Server to an IP address (as I am close to NIST I am using 129.6.15.28). In testing we discovered the router would not get a time sync on reboot with dnssec_return_status: GETDNS_EXTENSION_TRUE enabled. Using an IP is one workaround. However, you should use a time server IP that has a high probability of being up when you reboot your router! You can get an IP of a time server with a ping or nslookup but keep in mind that services like ntp;pool.org rotate the load among many servers so the IP's used change.

    Here is my stubby.yml:
    Code:
    # stubby.yml configuration file created by Xentrk
    # version 1.0.0
    tls_ca_file: "/opt/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: 0
    idle_timeout: 2000
    tls_connection_retries: 5
    tls_backoff_time: 900
    timeout: 2000
    appdata_dir: "/jffs/cache/stubby"
    listen_addresses:
      - [email protected]
    
    upstream_recursive_servers:
    # 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"
    
     
    Last edited: Oct 22, 2018
  6. Xentrk

    Xentrk Part of the Furniture

    Joined:
    Jul 21, 2016
    Messages:
    2,635
    Location:
    The Land of Smiles
    Probably best to change it back to use the USB drive. Per the Wiki, the recommendation is to use the USB for frequent read and writes to avoid wearing out /jffs partition.

     
    HuskyHerder likes this.
  7. I think the issue with Cloudflare is, or might be, related to getdns currently not yet being build against openssl 1.1.1. See this github issue: https://github.com/getdnsapi/stubby/issues/132 (near the end, posts from the last few weeks). A new version is likely to be released this week. However, openssl in entware is at 1.0.2 and it might take some time to get the latest release of stubby in entware repositories as well.
     
  8. bbunge

    bbunge Very Senior Member

    Joined:
    Aug 11, 2014
    Messages:
    1,022
    Location:
    Pennsylvania USA
    Believe that rational has been changed for modern routers. If it were true why would Asus and Merlin use /jffs for logs , lists, and etc. ?
     
  9. I think it's mainly syslog. Probably mostly because Asuswrt-Merlin needs to be able to run without a USB drive inserted. As /jffs is non-replaceable and a usb drive is, I prefer a usb drive as well.
     
  10. What's currently working for me is setting Enable DNSSEC support to Yes and setting DNSSEC: strict unsigned validation to No. This way CF DoT validation works as well as DNSSEC validation directly on the router using dig:

    Code:
    # 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: 13794
    ;; 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.   300 IN A 72.55.186.51
    asuswrt.lostrealm.ca.   300 IN RRSIG A 13 3 300 (
                                    20181023150920 20181021130920 35273 lostrealm.ca.
                                    E5wpzoQIAjT/YaxfYy4Tqm96BzArop95LQirTyh4yplQ
                                    YFY2JeLL3qpu5bmUXCprPxQqK30lfsAOOmPpzn9qLw== )
    
    ;; Query time: 136 msec
    ;; SERVER: 127.0.0.1#53(127.0.0.1)
    ;; WHEN: Mon Oct 22 14:09:20 UTC 2018
    ;; MSG SIZE  rcvd: 213
    
    I will try other DNS servers later today, as others are using the network currently.
     
  11. RMerlin

    RMerlin Super Moderator

    Joined:
    Apr 14, 2012
    Messages:
    32,069
    Location:
    Canada
    But it means that anyone can forge a DNS reply and simply not sign it, and your router will blindly accept it, making DNSSEC completely useless. If you can't use DNSSEC with strict unsigned validation, then you should not be using DNSSEC at all.
     
    Quoc Huynh and Treadler like this.
  12. I'm aware of that, thanks. Any suggestions why enabling DNSSEC (with or without strict unsigned validation) seems to break DoT? As soon as DNSSEC is enabled, https://1.1.1.1/help fails to validate being connected to 1.1.1.1 and fails in validating DoT.
     
  13. skeal

    skeal Part of the Furniture

    Joined:
    Apr 30, 2016
    Messages:
    3,786
    Location:
    Riderville, SK
    I disabled the line the .yml file and then enabled dnssec. Works like a charm. http://1.1.1.1/help correctly identifies my dns set to be 1.1.1.1 and 1.0.0.1 as well it says it's in YVR which is BC Canada and it says cloudflare number.

    Connected to 1.1.1.1 No
    Using DNS over HTTPS (DoH) No
    Using DNS over TLS (DoT) No
    AS Name Cloudflare
    AS Number 13335
    Cloudflare Data Center YVR

    Connectivity to Resolver IP Addresses
    1.1.1.1 Yes
    1.0.0.1 Yes

    2606:4700:4700::1111 No
    2606:4700:4700::1001 No
     
  14. skeal

    skeal Part of the Furniture

    Joined:
    Apr 30, 2016
    Messages:
    3,786
    Location:
    Riderville, SK
    As far as breaking DoT I say not. I have re-ran that kdig command from cloudflare and it works every time. With dnssec enabled in the webui.
     
  15. RMerlin

    RMerlin Super Moderator

    Joined:
    Apr 14, 2012
    Messages:
    32,069
    Location:
    Canada
    I have no idea how that test works or what it's actually testing.
     
  16. Sebastien Bougie

    Sebastien Bougie Regular Contributor

    Joined:
    Feb 23, 2017
    Messages:
    89
    Hello,

    Everything seems to work properly on my AC3100 except this error

    /tmp/home/root# echo | openssl s_client -verify on -CApath /opt/etc/ssl/certs -connect 1.1.1.1:853
    verify depth is 0
    CONNECTED(00000003)
    depth=1 C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA
    verify error:num=20:unable to get local issuer certificate
    717190064:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1269:

    ---
    no peer certificate available
    ---
    No client certificate CA names sent
    ---
    SSL handshake has read 2074 bytes and written 7 bytes
    ---
    New, (NONE), Cipher is (NONE)
    Secure Renegotiation IS supported
    Compression: NONE
    Expansion: NONE
    No ALPN negotiated
    SSL-Session:
    Protocol : TLSv1.2
    Cipher : 0000
    Session-ID: 6FF18E17D5A9FBFBC9BF3A747C41CBCA6CD5523D54B012683D913EDC3144BA0E
    Session-ID-ctx:
    Master-Key:
    Key-Arg : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1540308994
    Timeout : 300 (sec)
    Verify return code: 0 (ok)
     
  17. That's caused by a last-minute change. Earlier in testing we used the entware package ca-certificates, but @Xentrk is now using the certificates which come with the firmware. If you want to run the check, install ca-certificates from entware:

    Code:
    opkg update && opkg install ca-certificates
    It should return something like this:

    Code:
    # echo | openssl s_client -verify on -CApath /opt/etc/ssl/certs -connect 1.1.1.1:853
    verify depth is 0
    CONNECTED(00000003)
    depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
    verify return:1
    depth=1 C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA
    verify return:1
    depth=0 C = US, ST = CA, L = San Francisco, O = "Cloudflare, Inc.", CN = *.cloudflare-dns.com
    verify return:1
    ---
    Certificate chain
     0 s:/C=US/ST=CA/L=San Francisco/O=Cloudflare, Inc./CN=*.cloudflare-dns.com
       i:/C=US/O=DigiCert Inc/CN=DigiCert ECC Secure Server CA
     1 s:/C=US/O=DigiCert Inc/CN=DigiCert ECC Secure Server CA
       i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
    ---
    Server certificate
    -----BEGIN CERTIFICATE-----
    MIID9DCCA3qgAwIBAgIQBWzetBRl/ycHFsBukRYuGTAKBggqhkjOPQQDAjBMMQsw
    CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMSYwJAYDVQQDEx1EaWdp
    Q2VydCBFQ0MgU2VjdXJlIFNlcnZlciBDQTAeFw0xODAzMzAwMDAwMDBaFw0yMDAz
    MjUxMjAwMDBaMGwxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMN
    U2FuIEZyYW5jaXNjbzEZMBcGA1UEChMQQ2xvdWRmbGFyZSwgSW5jLjEdMBsGA1UE
    AwwUKi5jbG91ZGZsYXJlLWRucy5jb20wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNC
    AASyRQsxrFBjziHmfDQjGsXBU0WWl3oxh7vg6h2V9f8lBMp18PY/td9R6VvJPa20
    AwVzIJI+dL6OSxviaIZEbmK7o4ICHDCCAhgwHwYDVR0jBBgwFoAUo53mH/naOU/A
    buiRy5Wl2jHiCp8wHQYDVR0OBBYEFN+XTeVDs7BBp0LykM+Jf64SV4ThMGMGA1Ud
    EQRcMFqCFCouY2xvdWRmbGFyZS1kbnMuY29thwQBAQEBhwQBAAABghJjbG91ZGZs
    YXJlLWRucy5jb22HECYGRwBHAAAAAAAAAAAAERGHECYGRwBHAAAAAAAAAAAAEAEw
    DgYDVR0PAQH/BAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjBp
    BgNVHR8EYjBgMC6gLKAqhihodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vc3NjYS1l
    Y2MtZzEuY3JsMC6gLKAqhihodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vc3NjYS1l
    Y2MtZzEuY3JsMEwGA1UdIARFMEMwNwYJYIZIAYb9bAEBMCowKAYIKwYBBQUHAgEW
    HGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwCAYGZ4EMAQICMHsGCCsGAQUF
    BwEBBG8wbTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEUG
    CCsGAQUFBzAChjlodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRF
    Q0NTZWN1cmVTZXJ2ZXJDQS5jcnQwDAYDVR0TAQH/BAIwADAKBggqhkjOPQQDAgNo
    ADBlAjEAjoyy2Ogh1i1/Kh9+psMc1OChlQIvQF6AkojZS8yliar6m8q5nqC3qe0h
    HR0fExwLAjAueWRnHX4QJ9loqMhsPk3NB0Cs0mStsNDNG6/DpCYw7XmjoG3y1LS7
    ZkZZmqNn2Q8=
    -----END CERTIFICATE-----
    subject=/C=US/ST=CA/L=San Francisco/O=Cloudflare, Inc./CN=*.cloudflare-dns.com
    issuer=/C=US/O=DigiCert Inc/CN=DigiCert ECC Secure Server CA
    ---
    No client certificate CA names sent
    Peer signing digest: SHA512
    Server Temp Key: ECDH, P-256, 256 bits
    ---
    SSL handshake has read 2660 bytes and written 421 bytes
    ---
    New, TLSv1/SSLv3, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384
    Server public key is 256 bit
    Secure Renegotiation IS supported
    Compression: NONE
    Expansion: NONE
    No ALPN negotiated
    SSL-Session:
        Protocol  : TLSv1.2
        Cipher    : ECDHE-ECDSA-AES256-GCM-SHA384
        Session-ID: 439723CFC92EE025EBAAA050CB1F7369CA6A96E0D424D4BFD261F3DA0FD508B7
        Session-ID-ctx:
        Master-Key: 5C9326448166902D380EA53AF30A99C14C87F18D95545069A3DF2DA07D70956DB0BCCC84C471A8C5CBB3C826FA9BF79A
        Key-Arg   : None
        PSK identity: None
        PSK identity hint: None
        SRP username: None
        TLS session ticket lifetime hint: 21600 (seconds)
        TLS session ticket:
        0000 - 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
        0010 - 67 77 68 4a 60 f0 26 8c-b8 7b e7 b8 45 87 59 75   gwhJ`.&..{..E.Yu
        0020 - 01 30 11 6a 11 19 98 f3-ae cb 8a 15 fa 1c cb b4   .0.j............
        0030 - 46 4e a8 2d dd 76 ee 3c-25 b4 b5 a9 81 11 a2 ab   FN.-.v.<%.......
        0040 - da e0 a4 03 2c 00 f7 a9-f3 da 18 df e5 73 2b 8d   ....,........s+.
        0050 - fe 7b e0 ab fe 45 c0 08-2d 4a f4 bb b5 50 91 57   .{...E..-J...P.W
        0060 - 01 23 96 bc 5e 53 3f fb-1a 6f 47 39 f9 72 bc 02   .#..^S?..oG9.r..
        0070 - 90 e2 03 40 61 29 da d4-11 12 ce 83 30 7c 5b ae   [email protected])......0|[.
        0080 - 96 f9 36 66 e8 6a 1b 3e-59 f0 fe c2 55 5e 6b ca   ..6f.j.>Y...U^k.
        0090 - 7e b9 62 bd bb 80 cc 8c-49 ba 0e be 1c 1e 5b 2d   ~.b.....I.....[-
        00a0 - 1c 3d d1 91 7f 28 bb 7b-68 b4 ab 30 33 04 dc 18   .=...(.{h..03...
        00b0 - 02 16 3c ed cc 49 a1 c4-01 71 70 13 69 44 c3 a3   ..<..I...qp.iD..
        00c0 - cb 9f 25 b3 5f 18 d7 fe-f3 d9 3d 75 18 3f 76 db   ..%._.....=u.?v.
        00d0 - 19 3a 96 de 0e f9 27 6d-6b c2 19 05 2e 72 0e 22   .:....'mk....r."
        00e0 - 64 4b 4a bb ae 66 10 4a-5a ab 54 20 2c e6 2d 2d   dKJ..f.JZ.T ,.--
        00f0 - ae eb de 99 a1 2c 8d 87-d7 8c b0 31 66 e6 ab 2d   .....,.....1f..-
        0100 - 26 89 c7 ce 88 21 77 4e-d7 28 d2 da 62 91 bb b2   &....!wN.(..b...
        0110 - 89 cb 6a 6d 4f 3b 3e 31-d9 7e 83 49 3f 51 b8 6c   ..jmO;>1.~.I?Q.l
        0120 - 77 a6 14 18 06 b4 0c 0e-df 73 05 52 f8 1d 86 9d   w........s.R....
        0130 - 17 03 bb 51 53 39 21 b3-77 bc b7 00 c6 3a b6 50   ...QS9!.w....:.P
        0140 - 63 8c 6e 95 b3 34 fd 12-08 d3 ac c4 e4 99 6c bd   c.n..4........l.
        0150 - 2b 52 01 2f cb 3c ff 08-23 59 c8 2a 43 5d e1 27   +R./.<..#Y.*C].'
        0160 - 4c 39 c9 96 8e 96                                 L9....
    
        Start Time: 1540314870
        Timeout   : 300 (sec)
        Verify return code: 0 (ok)
    ---
    DONE
    You can remove ca-certificates afterwards, it is currently not needed to run stubby. To remove, execute:

    Code:
    opkg remove ca-certificates
    @Xentrk: This should probably be removed from the README.md, as it appears not to work with the certificate stored in /rom/etc/ssl/certs.
     
    Last edited by a moderator: Oct 23, 2018
    skeal likes this.
  18. Xentrk

    Xentrk Part of the Furniture

    Joined:
    Jul 21, 2016
    Messages:
    2,635
    Location:
    The Land of Smiles
    @[email protected] and @Sebastien Bougie
    README.md updated to use CA cert path in rom. It worked for me:
    Code:
    echo | openssl s_client -verify on -CApath /rom/etc/ssl/certs -connect 1.1.1.1:853
    

    Let me know your results.
     
    Last edited: Oct 24, 2018
  19. Sebastien Bougie

    Sebastien Bougie Regular Contributor

    Joined:
    Feb 23, 2017
    Messages:
    89
    Hello,

    This is what i'm getting

    :/tmp/home/root# echo | openssl s_client -verify on -CApat
    h /rom/etc/ssl/certs -connect 1.1.1.1:853
    verify depth is 0
    CONNECTED(00000003)
    depth=1 C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA
    verify error:num=20:unable to get local issuer certificate
    717304752:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1269:
    ---
    no peer certificate available
    ---
    No client certificate CA names sent
    ---
    SSL handshake has read 2074 bytes and written 7 bytes
    ---
    New, (NONE), Cipher is (NONE)
    Secure Renegotiation IS supported
    Compression: NONE
    Expansion: NONE
    No ALPN negotiated
    SSL-Session:
    Protocol : TLSv1.2
    Cipher : 0000
    Session-ID: 06FD8C929548B1245AD0F306A14BE174E12E1E6DE2E6CAA2149AEA2B3BCAF2D1
    Session-ID-ctx:
    Master-Key:
    Key-Arg : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1540378998
    Timeout : 300 (sec)
    Verify return code: 0 (ok)
     
  20. Xentrk

    Xentrk Part of the Furniture

    Joined:
    Jul 21, 2016
    Messages:
    2,635
    Location:
    The Land of Smiles
    Please check the directory /rom/etc/ssl/certs/ and see if you have a file called ca-certificates.crt in the folder.

    If still a problem, try installing ca-certificates and change the path reference to /opt/etc/ssl/certs.

    Check OpenSSL version:
    Code:
    /tmp/home/root:#openssl version
    OpenSSL 1.0.2p  14 Aug 2018
    
    What router model and firmware version are you using?

    Also, please paste code snip in the code brackets. You can use the upload_2018-10-24_18-31-35.png icon. Helps with the formatting and readability. Thanks!
     
    Last edited: Oct 24, 2018