stubby
stubby copied to clipboard
getdnsapi
DNSSEC not working on 0.3.0 (Windows)
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
Two comments:
- It is better to use
dnssec: GETDNS_EXTENSION_TRUEin Stubby as this will hard fail if there are any problems with obtaining or refreshing the root trust anchor - You need to add
+dnssecto the dig command to have it set theD0bit in the outgoing query (in the EDNS OPT RR). Only then will stubby respond setting the AD bit. You can add+qrto 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.
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
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
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
The solution is very simple. For Windows to get dnssec working with Stubby you need to install Unbound.
@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.
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.
If Unbound needs to be installed for DNSSEC to work in 0.3.0 (Windows) then that would suggest it is indeed a bug.
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.] ://)
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.
@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!
@triatic Oh yes, and how did you install Stubby? Which package or did you build yourself?
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 "[email protected]">,
"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.
Wonder if default_trust_anchor_location is an issue. C:/Program Files (x86)/getdns/ does not exist on my system.
I see that getdns_query is installed in the Stubby directory.
Output from your two commands attached:
@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
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.
@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...
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.
@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.
@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?
Or are you saying those files are initially given random filenames before being renamed (unsuccessfully) to root-anchors.* ?
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
@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.
@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 [email protected]:
@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 .
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.
@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"
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...
@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?
@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/