search

getdnsapi / stubby

Stubby is the name given to a mode of using getdns which enables it to act as a local DNS Privacy stub resolver (using DNS-over-TLS).
https://dnsprivacy.org/dns_privacy_daemon_-_stubby/
BSD 3-Clause "New" or "Revised" License
1.2k stars 99 forks source link

Stubby + DNSSEC question #136

Closed Xentrk closed 6 years ago

Xentrk commented 6 years ago

I have written a Stubby installer script for Asuswrt-Merlin firmware. I have a few people helping me test.

With the following stubby.yml, DNSSEC test sites https://rootcanary.org/test.html and http://dnssec.vs.uni-due.de/ show that DNSSEC is not enabled.

# 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
dnssec_return_status: GETDNS_EXTENSION_TRUE
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
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
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 Primary IPv6
  - address_data: 2606:4700:4700::1111
    tls_auth_name: "cloudflare-dns.com"

I do not have any trust anchors in /opt/var/cache/stubby.

With the following stubby.yml, DNSSEC sites https://rootcanary.org/test.html and http://dnssec.vs.uni-due.de/ show that DNSSEC is enabled.

# version 1.0.1
tls_ca_file: "/opt/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: 0
idle_timeout: 2000
tls_connection_retries: 5
tls_backoff_time: 900
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"
# The 1.1.1.1 Cloudflare Servers
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=
  - address_data: 1.0.0.1
    tls_auth_name: "cloudflare-dns.com"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=

I see trust anchors in /opt/var/cache/stubby. However, the https://1.1.1.1/help site does not work.

Others have reported that the https://1.1.1.1/help site does not support DNSSEC.

Is DNSSEC working with the first stubby.yml config file I posted?

From https://dnsprivacy.org/wiki/display/DP/Configuring+Stubby#ConfiguringStubby-DNSSEC, dnssec_return_status: GETDNS_EXTENSION_TRUE will tell Stubby to use DNSSEC and getdns will create the trust anchors. But no trust anchors are found in /opt/var/cache/stubby.

Thank you!

saradickinson commented 6 years ago

Stubby uses HTTP to retrieve the trust anchors from ICANN (not from the configured resolver) and we have heard of issues with other setups where this fetch attempted is before the network is up and so fails (or fails for other reasons). We have an open issue to add a retry to fetch the trust anchor if the first attempt fails: https://github.com/getdnsapi/getdns/issues/408

My suspicion is that your first config failed due to this or a similar problem, the two configurations are identical in terms of the DNSSEC configuration.

Cloudlfare support DNSSEC as a validating resolver (see Monitoring) but that is a separate issue to stubby obtaining the trust anchor to perform DNSSEC validation locally as you have configured.

1.1.1.1 is DNSSEC signed, as shown by http://dnsviz.net/d/1.1.1.1.in-addr.arpa/dnssec/ so you should have no problems resolving it.

The only difference I see between the two is that the second one uses only IPV4 Cloudflare servers (which should make no difference) and that the second one includes SPKI pins. 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.

Xentrk commented 6 years ago

Thank you Sara for the reply.

I did some more testing with the first and second stubby.yml config files and find I can pass the DNSSEC test websites AND get a good status from https://1.1.1.1/help when I comment out the line

dnssec_return_status: GETDNS_EXTENSION_TRUE

I fail the DNSSEC test when I set to FALSE. When I do a stubby -i with the line commented out, the system defaults to dnssec_return_status": GETDNS_EXTENSION_FALSE

I'll test it again tomorrow and let you know if the same thing occurs.

My script has the option to uninstall Stubby. I purge the appdata_dir: "/opt/var/cache/stubby" folder upon an uninstall. I have not seen new root keys being created since creating the issue. I've ran the install script multiple times today installing and uninstalling. I have yet to see Stubby generate new root keys inside the appdata_dir: "/opt/var/cache/stubby" folder .

Thank you very much.

Xentrk commented 6 years ago

I retested this morning several times. I am no longer having the issue I described above with setting dnssec_return_status": GETDNS_EXTENSION_FALSE. DNSSEC test sites now work and I get a good status from https://1.1.1.1/help when setting dnssec_return_status": GETDNS_EXTENSION_FALSE.

Connected to 1.1.1.1 | Yes Using DNS over HTTPS (DoH) | No Using DNS over TLS (DoT) | Yes

Not sure why it was not working previously as I had ran several tests.

I still do not have any root keys in the appdata_dir: "/opt/var/cache/stubby" folder though. Not sure yet why I sometimes see root keys and other times I do not. I'll keep testing and checking to see if I can find out why this is occurring.

Xentrk commented 6 years ago

I've retested this throughout the day. DNSSEC test sites now work and I get a good status from https://1.1.1.1/help

Connected to 1.1.1.1 | Yes Using DNS over HTTPS (DoH) | No Using DNS over TLS (DoT) | Yes

when removing dnssec_return_status": GETDNS_EXTENSION_TRUE from stubby.yml.

I still do not have any root keys in the appdata_dir: "/opt/var/cache/stubby" folder though. Not sure yet why I had root keys in my earlier testing. I did a search on the file system for the root anchor files I saw earlier. None were found except for the ones I had backed up to another directory.

I will close the issue now that I have DNSSEC working by removing the dnssec_return_status": GETDNS_EXTENSION_TRUE from stubby.yml. I am still curious about the root anchor files though.

Plan on doing a few more days of QA with my test team. I'll let you know when I go live with the installer.

Thank you for the work you do!