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.19k stars 99 forks source link

DNSSEC not working on 0.3.0 (Windows) #244

Open triatic opened 4 years ago

triatic commented 4 years ago

Hi, I've enabled DNSSEC in stubby with:

dnssec_return_status: GETDNS_EXTENSION_TRUE

[15:33:35.264291] STUBBY: Stubby version: Stubby 0.3.0
[15:33:35.277288] STUBBY: Read config from file C:\Program Files\Stubby\stubby.yml
[15:33:35.280285] STUBBY: DNSSEC Validation is ON
[15:33:35.281285] STUBBY: Transport list is:
[15:33:35.282285] STUBBY:   - TLS
[15:33:35.282285] STUBBY: Privacy Usage Profile is Strict (Authentication required)
[15:33:35.284283] STUBBY: (NOTE a Strict Profile only applies when TLS is the ONLY transport!!)
[15:33:35.286283] STUBBY: Starting DAEMON....

However I'm not getting the ad flag when querying a domain with DNSSEC:

C:\>dig @127.0.0.1 pir.org

; <<>> DiG 9.14.4 <<>> @127.0.0.1 pir.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34859
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;pir.org.                       IN      A

;; ANSWER SECTION:
pir.org.                299     IN      A       97.107.141.235
pir.org.                299     IN      RRSIG   A 5 2 300 20200501084004 20200417084004 4746 pir.org. FOMAwwz2RV77aGf7JgJFh4ktk2tfA0W8J3ny4kcR0Af9UHjfA/G6EQmW 5V/2NhQhY9wLENFnFJVIW3oGPnfwgBxn74J6jl0Gf/DUyoLYAFV+JCpn AeRI60EpCwj36yXRyyGrdRea0uvUrY0bM2CF27gqqWxkKRYBD+plOGRB m6M=

;; Query time: 889 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Apr 17 16:27:53 GMT Summer Time 2020
;; MSG SIZE  rcvd: 233
saradickinson commented 4 years ago

Two comments: 1) It is better to use dnssec: GETDNS_EXTENSION_TRUE in Stubby as this will hard fail if there are any problems with obtaining or refreshing the root trust anchor 2) You need to add +dnssec to the dig command to have it set theD0 bit in the outgoing query (in the EDNS OPT RR). Only then will stubby respond setting the AD bit. You can add +qr to the dig command to have it print the query as well as the response to check this. Note that if configured to use DNSSEC Stubby will return SERVFAIL for bogus domains regardless of the D0 bit.

triatic commented 4 years ago

Hi @saradickinson ,

I've set dnssec: GETDNS_EXTENSION_TRUE and am now getting a hard fail.

Any ideas?

[15:39:15.447575] STUBBY: Stubby version: Stubby 0.3.0
[15:39:15.452595] STUBBY: Read config from file C:\Users\triatic\AppData\Roaming\Stubby\stubby.yml
[15:39:15.462703] STUBBY: DNSSEC Validation is ON
[15:39:15.462703] STUBBY: Transport list is:
[15:39:15.472556] STUBBY:   - TLS
[15:39:15.473567] STUBBY: Privacy Usage Profile is Strict (Authentication required)
[15:39:15.473567] STUBBY: (NOTE a Strict Profile only applies when TLS is the ONLY transport!!)
[15:39:15.473567] STUBBY: Starting DAEMON....
; <<>> DiG 9.14.4 <<>> @127.0.0.1 pir.org +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2898
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;pir.org.                       IN      A

;; Query time: 888 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Apr 27 16:39:38 GMT Summer Time 2020
;; MSG SIZE  rcvd: 25

For comparison, identical config except with dnssec: GETDNS_EXTENSION_TRUE removed to prove DNS is functional:

[15:42:08.124475] STUBBY: Stubby version: Stubby 0.3.0
[15:42:08.140473] STUBBY: Read config from file C:\Users\triatic\AppData\Roaming\Stubby\stubby.yml
[15:42:08.144471] STUBBY: DNSSEC Validation is OFF
[15:42:08.145469] STUBBY: Transport list is:
[15:42:08.154065] STUBBY:   - TLS
[15:42:08.156065] STUBBY: Privacy Usage Profile is Strict (Authentication required)
[15:42:08.160542] STUBBY: (NOTE a Strict Profile only applies when TLS is the ONLY transport!!)
[15:42:08.164541] STUBBY: Starting DAEMON....
; <<>> DiG 9.14.4 <<>> @127.0.0.1 pir.org +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26235
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;pir.org.                       IN      A

;; ANSWER SECTION:
pir.org.                299     IN      A       97.107.141.235
pir.org.                299     IN      RRSIG   A 5 2 300 20200511084005 20200427084005 4746 pir.org. Ef5/dW6Re60dHdw3Wbu8DdcqInX51ztcU/nQEIO3uIhScPNAUuEhp/XC JAH1wsS/DbT0WbC/yGYoPJ0VyMDDaHTWH0m7cOp7cuf5MVEgkjhVDbSh 0cPQFut0QbxEZW1ZCvAUyT/clVqNARLpSjjdnB/B2IbMlSnH2IYpKNRX opc=

;; Query time: 144 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Apr 27 16:42:11 GMT Summer Time 2020
;; MSG SIZE  rcvd: 233
triatic commented 4 years ago

As an aside, my version of dig seems to request DNSSEC by default, meaning +dnssec is optional now:

; <<>> DiG 9.14.4 <<>> pir.org @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47758
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;pir.org.                       IN      A

;; ANSWER SECTION:
pir.org.                299     IN      A       97.107.141.235

;; Query time: 28 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Apr 27 17:06:17 GMT Summer Time 2020
;; MSG SIZE  rcvd: 52
triatic commented 4 years ago

Update: I downgraded to 0.2.6.0 and DNSSEC is working again:

[13:28:52.240553] STUBBY: Read config from file C:\Users\triatic\AppData\Roaming\Stubby\stubby.yml
[13:28:52.241541] STUBBY: DNSSEC Validation is ON
[13:28:52.241541] STUBBY: Transport list is:
[13:28:52.241541] STUBBY:   - TLS
[13:28:52.241541] STUBBY: Privacy Usage Profile is Strict (Authentication required)
[13:28:52.241541] STUBBY: (NOTE a Strict Profile only applies when TLS is the ONLY transport!!)
[13:28:52.241541] STUBBY: Starting DAEMON....
; <<>> DiG 9.14.4 <<>> pir.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47437
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;pir.org.                       IN      A

;; ANSWER SECTION:
pir.org.                299     IN      A       34.74.232.240
pir.org.                299     IN      RRSIG   A 5 2 300 20200519204001 20200505204001 4746 pir.org. DquQYRenh48VO00NVBnQBgJrfrXuQFME8Bt/kpLhHgCtZPEL92tKyj5/ 8TitdEtkDLcA3B6/+fKFQhDUoUSKRa03obumwndfQER9V8yK134K8yyV r5hPVDk3XN11G2WDVWGqTBfx8LRQZerWZh5ZFwn48N3cedyBIR3SliCZ MKM=

;; Query time: 4883 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed May 06 14:31:28 GMT Summer Time 2020
;; MSG SIZE  rcvd: 233
hanvinke commented 4 years ago

The solution is very simple. For Windows to get dnssec working with Stubby you need to install Unbound.

triatic commented 4 years ago

@hanvinke why would stubby need Unbound installed? The documentation clearly states newer versions of stubby have automatic trust anchor management and therefore no requirement for unbound.

hanvinke commented 4 years ago

Well, I had the same problem on Windows. Only Opportunistic mode worked out-of-the-box, but Strict Mode failed. After installing Unbound that problem was solved.

Sorry, I am not an expert in Windows use with Stubby and did not study the requirements exactly. Only looked for a quick solution for myself. If you wish you can set Stubby to Opportunistic Mode, then you won't need Unbound.

triatic commented 4 years ago

If Unbound needs to be installed for DNSSEC to work in 0.3.0 (Windows) then that would suggest it is indeed a bug.

hanvinke commented 4 years ago

No sorry, I was sleeping already yesterday. Unbound has nothing to do with it.

The problem is in the default stubby.yml file. On line 134 it should read: "dnssec_return_status: GETDNS_EXTENSION_TRUE". I forgot to change the line, just removed the "#"

When installing there is only : "# dnssec: GETDNS_EXTENSION_TRUE".

[Because I adapted Unbound to act like a caching server I also loaded another yaml file. I presumed therefore incorrectly that by installing Unbound I was probably adding some needed libraries.] ://)

triatic commented 4 years ago

Changing to dnssec_return_status: GETDNS_EXTENSION_TRUE does nothing except allow queries which fail DNSSEC to succeed without validating DNSSEC.

On 0.3.0 (Windows) DNSSEC queries fail validation 100% of the time so enabling dnssec_return_status: GETDNS_EXTENSION_TRUE is no better than disabling DNSSEC altogether. In fact it's worse since you're taking the performance hit of checking DNSSEC which will always fail anyway.

wtoorop commented 4 years ago

@triatic For debugging purposes, could you provide the output of stubby -i ? Also, is getdns_query installed on your system too? If so, could you run:

getdns_query -sL @8.8.8.8 pir.org A  +dnssec_return_validation_chain

and

getdns_query -sL @8.8.8.8 servfail.nl A  +dnssec_return_validation_chain

Thanks!

wtoorop commented 4 years ago

@triatic Oh yes, and how did you install Stubby? Which package or did you build yourself?

triatic commented 4 years ago

getdns_query is not installed.

Output below (personal ip/host redacted, it's firewalled to only accept DoT from my IP).

I installed the 64-bit msi package from: https://dnsprivacy.org/wiki/display/DP/Windows+installer+for+Stubby#WindowsinstallerforStubby-Installation

[12:35:34.948861] STUBBY: Stubby version: Stubby 0.3.0
[12:35:34.959073] STUBBY: Read config from file C:\Users\User\AppData\Roaming\Stubby\stubby.yml
{
  "all_context":
  {
    "add_warning_for_bad_dns": GETDNS_EXTENSION_FALSE,
    "appdata_dir": <bindata of "C:\Users\User\AppData\Roaming\"...>,
    "append_name": GETDNS_APPEND_NAME_TO_SINGLE_LABEL_FIRST,
    "dns_transport_list":
    [
      GETDNS_TRANSPORT_TLS
    ],
    "dnssec": GETDNS_EXTENSION_TRUE,
    "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,
    "edns_client_subnet_private": 1,
    "edns_cookies": GETDNS_EXTENSION_FALSE,
    "edns_do_bit": 0,
    "edns_extended_rcode": 0,
    "edns_version": 0,
    "follow_redirects": GETDNS_REDIRECTS_FOLLOW,
    "idle_timeout": 10000,
    "limit_outstanding_queries": 0,
    "max_backoff_value": 1000,
    "namespaces":
    [
      GETDNS_NAMESPACE_LOCALNAMES,
      GETDNS_NAMESPACE_DNS
    ],
    "resolution_type": GETDNS_RESOLUTION_STUB,
    "return_both_v4_and_v6": GETDNS_EXTENSION_FALSE,
    "return_call_reporting": GETDNS_EXTENSION_FALSE,
    "round_robin_upstreams": 1,
    "specify_class": 1,
    "suffix": [],
    "timeout": 5000,
    "tls_authentication": GETDNS_AUTHENTICATION_REQUIRED,
    "tls_backoff_time": 3600,
    "tls_cipher_list": <bindata of "TLS13-AES-256-GCM-SHA384:TLS13-A"...>,
    "tls_ciphersuites": <bindata of "TLS_AES_256_GCM_SHA384:TLS_AES_1"...>,
    "tls_connection_retries": 2,
    "tls_min_version": GETDNS_TLS1_2,
    "tls_query_padding_blocksize": 256,
    "trust_anchors_backoff_time": 2500,
    "trust_anchors_url": <bindata of "http://data.iana.org/root-anchor"...>,
    "trust_anchors_verify_CA": <bindata of 0x2d2d2d2d2d424547494e204345525449...>,
    "trust_anchors_verify_email": <bindata of "dnssec@iana.org">,
    "upstream_recursive_servers":
    [
      {
        "address_data": <bindata for (redacted)>,
        "address_type": <bindata of "IPv4">,
        "tls_auth_name": <bindata of "(redacted)">
      }
    ]
  },
  "api_version_number": 132058112,
  "api_version_string": <bindata of "December 2015">,
  "compilation_comment": <bindata of "getdns 1.6.0 configured on 2020-"...>,
  "default_hosts_location": <bindata of "C:/Windows/System32/Drivers/etc/"...>,
  "default_resolvconf_location": <bindata of "/etc/resolv.conf">,
  "default_trust_anchor_location": <bindata of "C:/Program Files (x86)/getdns/et"...>,
  "implementation_string": <bindata of "https://getdnsapi.net">,
  "listen_addresses":
  [
     <bindata of 0x7f000001>,
     <bindata of 0x00000000000000000000000000000001>
  ],
  "openssl_build_version_number": 268443967,
  "resolution_type": GETDNS_RESOLUTION_STUB,
  "version_number": 17170432,
  "version_string": <bindata of "1.6.0">
}
Result: Config file syntax is valid.
triatic commented 4 years ago

Wonder if default_trust_anchor_location is an issue. C:/Program Files (x86)/getdns/ does not exist on my system.

triatic commented 4 years ago

I see that getdns_query is installed in the Stubby directory.

Output from your two commands attached:

stubby1.txt stubby2.txt

wtoorop commented 4 years ago

@triatic Thanks, this tells me there is an issue with downloading the Trust Anchor. default_trust_anchor_location should not matter. The newly fetched Trust Anchor should be written in the appdata_dir directory. Do you see root.key, root-anchors.xml and root-anchors.p7s in there?

Could you run the above command again, but now with -y 7 appended? I.e.:

getdns_query -sL @8.8.8.8 pir.org A  +dnssec_return_validation_chain -y 7

It should report on stderr errors occurred while obtaining the trust anchor, for example, here is my successful refetch after I removed the trust anchor:

[13:42:12.201245] UPSTREAM Error opening "/home/willem/.getdns/root-anchors.xml": No such file or directory
[13:42:12.202710] UPSTREAM 8.8.8.8                                  : Conn opened: TLS - Opportunistic Profile
[13:42:12.242792] UPSTREAM Waiting 25ms for AAAA to arrive
[13:42:12.242840] UPSTREAM Setting op connection to: 2606:2800:11f:bb5:f27:227f:1bbf:a0e
[13:42:12.242883] UPSTREAM Error connecting to trust anchor host: Network is unreachable
 [13:42:12.242913] UPSTREAM AAAA connection failed, waiting for A
[13:42:12.242936] UPSTREAM Setting op connection to: 72.21.81.189
[13:42:12.291097] UPSTREAM 8.8.8.8                                  : Conn closed: TLS - Resps=     8, Timeouts  =     0, Curr_auth =   None, Keepalive(ms)=     0
[13:42:12.291151] UPSTREAM 8.8.8.8                                  : Upstream   : TLS - Resps=     8, Timeouts  =     0, Best_auth =   None
[13:42:12.291164] UPSTREAM 8.8.8.8                                  : Upstream   : TLS - Conns=     1, Conn_fails=     0, Conn_shuts=      0, Backoffs     =     0
[13:42:12.486002] UPSTREAM Successfully fetched new trust anchors
[13:42:12.487839] UPSTREAM Error opening "/home/willem/.getdns/root.key": No such file or directory
triatic commented 4 years ago

Do you see root.key, root-anchors.xml and root-anchors.p7s in there?

No. I can see other files in there though with 0 bytes.

Your getdns_query says:

[14:11:34.405403] UPSTREAM Error opening "C:\Users\User\AppData\Roaming\getdns\root-anchors.xml": unknown WSA error code 2
[14:11:34.405403] UPSTREAM Error closing temporary file "C:\Users\User\AppData\Roaming\getdns\a27432": unknown WSA error code 5
[14:11:34.405403] UPSTREAM Not fetching TA, because non writeable appdata directory
[14:11:34.555676] UPSTREAM Error opening "C:\Users\User\AppData\Roaming\getdns\root-anchors.xml": unknown WSA error code 2
[14:11:34.555676] UPSTREAM Not fetching TA, because non writeable appdata directory

The directory is writeable though. Stubby is filling it with 0 bytes files.

wtoorop commented 4 years ago

@saradickinson @banburybill @johndickinson , do you see that error too when removing the appdata_dir and other dnssec trust anchors? If you do, this is appears to be a degradation since 0.2.6.0 but non of the anchor or async event handling code is changed as far as I remember...

hanvinke commented 4 years ago

I manually added the root cert earlier with unbound-anchor. It seemed to work. When I changed the location of trust-anchor file however, I noticed spaces and capital letters are a problem. Currently I am at work, will check later.

wtoorop commented 4 years ago

@triatic FYI, the files you see are temporary files which would be moved "atomically" root root-achors.xml and root-anchors.p7s. Unfortunately an EIO is returned when the file is closed, which is a very generic error.

triatic commented 4 years ago

@wtoorop I see. What's the purpose of all these 0 byte files (e.g. r23948, k23948, a27432) in the application data directory then? Should they have content?

triatic commented 4 years ago

Or are you saying those files are initially given random filenames before being renamed (unsuccessfully) to root-anchors.* ?

hanvinke commented 4 years ago

Now finally getting an answer with stubby 0.3.0:

; <<>> DiG 9.17.1 <<>> dig @127.0.0.1 pir.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6773 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;dig. IN A

;; AUTHORITY SECTION: diet. 86400 IN NSEC digital. NS DS RRSIG NSEC diet. 86400 IN RRSIG NSEC 8 1 86400 20200526170000 20200513160000 48903 . snAxyxvHiMI2iIKL0tVgwz8etIaejsrh4+1GV190UaMlfqDXeTqmkpBw Cq6xsyDGumX+b6kQuF68pbwYEGfY63ajszgxdVNE0KxOoyCJWwvH5Bxl u14iQerjfaOzYU1JjlJuZSFquvDtO+RhnGl06JGztmDO76SQMgI0TxXK C+NWuQclBQr6QvNf3GLMMTxpF5BkzzUbsx33b8Ryqx0wVzTUAQwdjxJJ mOrfCQSfZLxbpoSw1a5K1kjRpeIlzagom2qOGhxqRmqNypnwC/FX/CsU AoYJTnzT+iFzQfzAG3svGKJQKmpClUjJNndfFcQznSzySo/3Z5QmYaIi 4n1DHw== . 81638 IN NSEC aaa. NS SOA RRSIG NSEC DNSKEY . 81638 IN RRSIG NSEC 8 0 86400 20200526170000 20200513160000 48903 . rbw4k1qL/P1Pt1sYTcAoGK3DIBhFHcmZchm0zNs72TVFZvUWlECOiffo 53Rlwwh/c4dZxX3qvmuBMwuKFBpP7yBFI11R4mkwrx0Nd9HTmw2qEWhM QWd0Xe4Kq/I4ezRXY5Hu10BCT/s5YkSQKeCCKkLEv8FamAnhBSgrvWy3 nLq8izmHZk7791ArSaDRxs752xuc5jhRqggl2s7PMPepGrKkFxS+bsQQ kUngUNAgCyPsU5Ni9QKvTx+vzgnwjefZ3HPCPt27FZNuH0MJ055qC/sb k741yZw3FSKMTX0dMteEN4ABgsSWGSDHjqc5jJKaAKaI7V0zba2HogOz DeFxTw== . 2439 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2020051301 1800 900 604800 86400 . 85239 IN RRSIG SOA 8 0 86400 20200526170000 20200513160000 48903 . bRkaSZwYN4jY24tu2KCqy4NLJJTV97rCaTHiat8/tHoE8MAfKc6rRrvp RUn+Iy3FYA1IIRHQIwv2KgA5l/T7eJ102ap93cF4j6h8pcw4Su3+tmHR IKkaxo7vSqEzZGsfet+227TcBUhv1Z2BlMltCLdi3CtcbelrUcR3NF+f n8s0u6ahAAfM0ytmiQXnjf+zjNP2u8efoMLXlzEt8ATZIaI7QP4g3ubU 73bZx/Rm0310j82HHfvU3Me5/B79hkYgz3jI4Cz/2q4ewkzyzOBkXxgt OvdXihcrvqKqpktD+bUwxjsrJfbd26fxv70thywL0urV0GOMf0xYYxK3 Yf7Osg==

;; Query time: 593 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed May 13 21:00:51 West-Europa (zomertijd) 2020 ;; MSG SIZE rcvd: 1028

;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22589 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: ab9704cc0a59cd75523c48755ebc43e4390faf4a270f1314 (good) ;; QUESTION SECTION: ;pir.org. IN A

;; ANSWER SECTION: pir.org. 300 IN A 34.74.232.240 pir.org. 300 IN RRSIG A 5 2 300 20200527084004 20200513084004 50307 pir.org. o6wKCfCKQ3KtiP/QwCB34DMuwoOZ/YpxWK0p7tWhy8UosGJu0XD7BMiy Euzc30yfv/x/APDbKcUrqJOMMs9DGtmogyLRDz/bArTxQ++qgbZa1dJ7 +KAR0aGgMXAsW+vWw3N9sbGa2oxAE/w9lVt5iTiEPEdbijIu51mk6Em9 fJQ=

;; Query time: 463 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed May 13 21:00:51 West-Europa (zomertijd) 2020 ;; MSG SIZE rcvd: 261

@triatic Can you add to your stubby.yml the following settings?

dnssec: GETDNS_EXTENSION_TRUE dnssec_return_validation_chain: GETDNS_EXTENSION_TRUE

triatic commented 4 years ago

@hanvinke from your reply:

;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

Your reply is missing the ad flag, and therefore is not validated. Sure you got a reply, but you might as well disable DNSSEC altogether because having it enabled is clearly not checking anything for you.

hanvinke commented 4 years ago

@triatic Ah, thanks missed the ad flag. There are also just atomic files downloaded and no root.key either. Next time I take a better look. Thank you for correcting me.

Op woensdag 13 mei 2020 schreef triatic notifications@github.com:

@hanvinke https://github.com/hanvinke from your reply:

;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

Your reply is missing the ad flag, and therefore is not validated. Sure you got a reply, but you might as well disable DNSSEC altogether because having it enabled is clearly not checking anything for you.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/getdnsapi/stubby/issues/244#issuecomment-628195057, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGDNGSPGVW247QFFUPJKOH3RRLXMHANCNFSM4MK2Y5IA .

hanvinke commented 4 years ago

Default location for root trust anchor should be in %appdata%\GETDNS directory. But stubby -i shows otherwise: "default_trust_anchor_location": <bindata of "C:/Program Files (x86)/getdns/et"...>, Unfortunately the full path is not readable., it is truncated. Changing the location in stubby.yml doesn't help, it simply stays the same.

@wtoorop If I can find out what the full path is I could put the trust anchor files there and see if it makes a difference.

wtoorop commented 4 years ago

@hanvinke Yes, that is possible bij showing settings in (formatted) JSON format:

getdns_query.exe -iJ

with my install from the package from dnsprivacy.org I see:

  "default_trust_anchor_location": "C:/Program Files (x86)/getdns/etc/unbound/getdns-root.key"
wtoorop commented 4 years ago

Or are you saying those files are initially given random filenames before being renamed (unsuccessfully) to root-anchors.* ?

@triatic Yes, that is what I meant with atomically. First written to a temporary file and than moved to the actual filename. That those will not even be tried to be removed is a bug too... which I can fix right away. For me to fix the zero dnssec failure on windows I need to setup a VisualStudio build system for Stubby myself (I can now only do mingw builds), but maybe @saradickinson or @banburybill can help out to address this more quickly since they already have the build system...

triatic commented 4 years ago

@wtoorop ah so the existence of the random filenames clearly proves Stubby has write access to that directory, since otherwise the 0 byte files could not exist. Very odd then that getdns is reporting permissions failure.

By the way what is the relationship between getdns_query and stubby? Is the getdns_query code used internally within stubby, or called by stubby in some way?

wtoorop commented 4 years ago

@triatic Yes, the error does not come from the write operation, but from the close operation. Error 5 means IO error which is not very helpful. I really have to get my hands on with the right build system (VisualStudio) to be able to address this... (for which I have to find and/or make time!) getdns_query is a tool which we use to work on the getdns library. It exposes the libraries functionality on the command line so it can be tried out and debugged quickly... Stubby is very similar, but focused towards being a stub resolver system component. Stubby even started out as an alias for getdns_query, see https://getdnsapi.net/presentations/stubby/

hanvinke commented 4 years ago

After creating the directory C:/Program Files (x86)/getdns/etc/unbound and adding the trust-anchor files manually :

;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41190 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

So it works now. I tried with empty directory, but it fails. But the atomic files do not appear any longer when the anchor files are there.

query.txt

triatic commented 4 years ago

Manually copying root.key from Unbound to C:/Program Files (x86)/getdns/etc/unbound/getdns-root.key works for me too.

A usable workaround until Stubby is fixed so it can generate its own root.key.

hanvinke commented 4 years ago

@triatic Thanks and sorry - should have mentioned that renaming the key is essential.

hanvinke commented 4 years ago

Just a remark: At line 212 in CMakeLists.txt there is: " set(PATH_TRUST_ANCHOR_FILE "${CMAKE_INSTALL_FULL_SYSCONFDIR}/unbound/getdns-root.key" ". I also used the stubby-0.3.0.6-x64.msi for installation (64bit Windows Installer), not the 32 bit version. But sysconfdir is obviously set to C:\Program Files (x86)\getdns\etc instead of C:\Program Files\Stubby. //edit: found windows/stubby64.wxs

triatic commented 4 years ago

The default_trust_anchor_location value is not important.

appdata_dir is used for storing root.key, Stubby is just having a problem writing to it.

hanvinke commented 4 years ago

To be able to build vcpkg with Visual Studio 2019 Community ("https://visualstudio.microsoft.com/vs/community/") you first you need to set the environmental setting for windowsx64, but there will be a patch for that soon. Also I needed to add the filepath CMAKE_TOOLCHAIN_FILE. Also before installing vcpkg you better install PowerShell core for x64 ("https://github.com/PowerShell/PowerShell/releases/download/v7.0.1/PowerShell-7.0.1-win-x64.msi")