Stubby unable to connect to Cloudflare's 1.1.1.1 (WINDOWS) #87
Comments
|
Using this works for me: |
|
Unable to connect to Cloudflare over TLS either. resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
- GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 128
edns_client_subnet_private : 1
idle_timeout: 10000
listen_addresses:
- 127.0.0.1
round_robin_upstreams: 1
upstream_recursive_servers:
- address_data: 1.1.1.1
tls_auth_name: "cloudflare-dns.com"
tls_port: 853
tls_pubkey_pinset:
- digest: "sha256"
value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=
or even
- address_data: 1.1.1.1
tls_auth_name: "cloudflare-dns.com"
ends up in
STUBBY: 1.1.1.1 : Verify failed : Transport=TLS - *Failure* - (20) "unable to get local issuer certificate"
STUBBY: *FAILURE* no valid transports or upstreams available! |
|
So this seems to be working for me:
|
|
@t5k6 I have same config, but it fails with error: P.S.: Quad9 (9.9.9.9:853) fails with same error too. |
|
@t5k6 I used the folllowing method: which gives: When putting in Conclusion: |
|
@t5k6 My method is usually right but failed due to the certificate not being an RSA certificate. But even when I changed the sha256-pin, the error remains. |
|
@nja0087 Problem still remains with your proposed configuration. |
|
Output of dig for google.com running dnsmasq/stubby using config above with Cloudflare's 1.1.1.1 and DNSSEC: for Stubby 1.4.1-1 on Debian/kernel 4.15 |
|
@nja0087 This thread is only about Windows. |
jankal
changed the title
|
It's working fine for me on Windows 10. |
|
@t5k6 When you disable TLS verification / allow Stubby to resolve without DNS-over-TLS ( Help states: |
|
@jankal This can be another problem, because the relevant part in my config is uncommented. |
|
@t5k6 Looks promising. How on earth did it open a TLS connection now? Maybe this got something to do with: |
|
@jankal Sorry, earlier I haven't directed the command to stubby.yml with The correct output for comparison: |
|
Fellows, haste makes waste, stop posting your “it works for me” without carefully reading first. Mr. @jankal stated clearly in the initial post that issue is related to Windows certificates store, which echoes last year still unresolved issue #46. Windows users have different state of certificates store, there are already three non-amateurs here (the author, @george-chakhidze and me), who suffer from this issue not because configuration is wrong, some whitespaces are omitted, or something else, but exactly because Stubby is a fledgling endeavour. And the only valuable feedback would come from Stubby’s maintainers, i.e. a fix. |
|
For configuration see #89 |
|
Firstly, apologies about the earlier misleading comment - the Windows installer does use the system CA cert store..... but it loads it dynamically into the internal OpenSSL cert store when Stubby starts. So any changes to that store require a restart of Stubby to be used. However, I've just tested this on Windows 10, build 16299 and I am able to connect to both 1.1.1.1 and 9.9.9.9 with no problem using Strict mode. So something slightly deeper going on here.... continuing to investigate. Also am updating the Windows installer to use 1.4.1 and will post here when available. |
|
@saradickinson, it would be easier for some of us, myself included, if you just put updated |
|
Hi All, A new Windows installer is a now available using getdns 1.4.1: |
|
Does not work me, I see the same error: |
|
@sergeevabc which version of Windows do you use? |
|
@wtoorop Same here ( |
|
@wtoorop, Windows 7 x64. |
|
@sergeevabc @george-chakhidze Can you please test and confirm this fails if you use just a SPKI pin? The config uses the tls_auth name by default so replace it with the following: |
resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
- GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 128
edns_client_subnet_private : 1
idle_timeout: 10000
listen_addresses:
- 127.0.0.1
round_robin_upstreams: 1
upstream_recursive_servers:
- address_data: 1.1.1.1
tls_pubkey_pinset:
- digest: "sha256"
value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=outputs So, I guess, it does not work on my end. |
|
C:\OpenSSL-Win32\bin>openssl s_client -connect 9.9.9.9:853 | openssl x509 -pubke what's wrong? win8.1 64 bit |
|
[11:50:26.832943] STUBBY: FAILURE no valid transports or upstreams availabl When I changed GETDNS_AUTHENTICATION_REQUIRED to GETDNS_AUTHENTICATION_NONE, it would be ok. C:\OpenSSL-Win64\bin>"C:\Program Files\Stubby\stubby.exe" -C "C:\Program Files\S |
|
First: current version details: So this is my output on Windows 10 Build 16299 using the default config (uncommented Cloudflare entries): So it still fails using the When using the SPKI pin, it still fails: SPKI-Pin config: My certmgr DigiCert Root: |
|
I've not got |
|
I just installed a compiled OpenSSL seems to be able to verify the CA certificate here, too. |
|
Hi All, Thanks so much for the testing and feedback and sorry for this ongoing problem. It looks like you all have the right certs in your store and are getting the right cert in the handshake so it is still not obvious why only Cloudflare is failing to authenticate on your systems. I've attached a zipped version of getdns_query.exe which has some additional debugging messages enabled. If you are able to test with this using these commands it might help:
Many thanks! |
outputs while outputs |
|
@saradickinson This is what I get: >getdns_query.exe -s -L -m @1.1.1.1~cloudflare-dns.com example.com
[14:42:44.682878] --- SETUP(TLS): add_WIN_cacerts_to_openssl_store : Adding Windows certificates to CA store
[14:42:44.693879] --- SETUP(TLS): add_WIN_cacerts_to_openssl_store : Error adding certificate 0:error:0B07C065:x509 certificate routines:X509_STORE_add_cert:cert already in hash table
An error occurred: 301 'The context has internal deficiencies'
>getdns_query.exe -s -L -m @1.1.1.1 'pin-sha256="yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc="' example.com
[14:42:53.850840] --- SETUP(TLS): add_WIN_cacerts_to_openssl_store : Adding Windows certificates to CA store
[14:42:53.862843] --- SETUP(TLS): add_WIN_cacerts_to_openssl_store : Error adding certificate 0:error:0B07C065:x509 certificate routines:X509_STORE_add_cert:cert already in hash table
An error occurred: 301 'The context has internal deficiencies'
>getdns_query.exe -s -L @1.1.1.1 'pin-sha256="yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc="' example.com
[14:43:06.535639] --- SETUP(TLS): add_WIN_cacerts_to_openssl_store : Adding Windows certificates to CA store
[14:43:06.547135] --- SETUP(TLS): add_WIN_cacerts_to_openssl_store : Error adding certificate 0:error:0B07C065:x509 certificate routines:X509_STORE_add_cert:cert already in hash table
[14:43:06.559799] --- SETUP(TLS): _getdns_context_prepare_for_resolution: DEBUG: SSL_CTX_dane_enable() -> 1
[14:43:06.566800] => ENTRY: _getdns_submit_stub_request : MSG: 00000000029F50E0 TYPE: 2
[14:43:06.566800] --- SETUP: upstream_select_stateful : Testing upstreams 0 0 for transport 1202
[14:43:06.566800] --- SETUP: upstream_select_stateful : Testing upstreams 1 0 for transport 1202
[14:43:06.566800] --- SETUP: upstream_connect : Getting upstream connection: 00000000029F9210
[14:43:06.566800] --- SETUP: tcp_connect : Creating TCP connection: 00000000029F9210
[14:43:06.567799] --- SETUP(TLS): tls_create_object : Proceeding even though no hostname provided!
[14:43:06.568803] --- SETUP(TLS): tls_create_object : WARNING: Using Oppotunistic TLS (fallback allowed)!
[14:43:06.568803] --- SETUP(TLS): tls_create_object : DEBUG: SSL_dane_enable("") -> 1
[14:43:06.568803] --- SETUP: upstream_find_for_transport : FD: 708 Connecting to upstream: 00000000029F9210 No: 1
[14:43:06.568803] ----- SCHEDULE: upstream_find_for_netreq : MSG: 00000000029F50E0 found upstream 00000000029F9210 with transport 1202, fd: 708
[14:43:06.568803] ----- SCHEDULE: upstream_schedule_netreq : MSG: 00000000029F50E0 (schedule event)
[14:43:06.586868] ------- WRITE: upstream_write_cb : MSG: 00000000029F50E0 (writing)
[14:43:06.587801] --- SETUP(TLS): tls_do_handshake : FD: 708
[14:43:06.604867] ------- READ: upstream_read_cb : FD: 708
[14:43:06.605804] --- SETUP(TLS): tls_do_handshake : FD: 708
[14:43:06.605804] ------- READ: upstream_read_cb : FD: 708
[14:43:06.606800] --- SETUP(TLS): tls_do_handshake : FD: 708
[14:43:06.606800] DEBUG Cert verify: depth=1 verify=0 err=20 subject=/C=US/O=DigiCert Inc/CN=DigiCert ECC Secure Server CA errorstr=unable to get local issuer certificate
[14:43:06.608799] DEBUG Cert verify: depth=0 verify=1 err=20 subject=/C=US/ST=CA/L=San Francisco/O=Cloudflare, Inc./CN=*.cloudflare-dns.com errorstr=unable to get local issuer certificate
[14:43:06.626870] ------- READ: upstream_read_cb : FD: 708
[14:43:06.626870] --- SETUP(TLS): tls_do_handshake : FD: 708
[14:43:06.627805] --- SETUP(TLS): tls_do_handshake : FD: 708 Handshake succeeded with auth state None. Session is new.
[14:43:06.627805] ------- WRITE: upstream_write_cb : MSG: 00000000029F50E0 (writing)
[14:43:06.645882] ------- READ: upstream_read_cb : FD: 708
[14:43:06.646380] ------- READ: upstream_read_cb : MSG: 00000000029F50E0 (read)
[14:43:06.646882] --- CLEANUP: stub_cleanup : MSG: 00000000029F50E0
[14:43:06.647349] ----- SCHEDULE: upstream_reschedule_events : FD: 708
[14:43:06.647860] ----- SCHEDULE: upstream_reschedule_events : FD: 708 Connection idle - timeout is 0
[14:43:06.647860] --- CLEANUP: upstream_idle_timeout_cb : FD: 708 Closing connection
{
"answer_type": GETDNS_NAMETYPE_DNS,
"canonical_name": <bindata for example.com.>,
"replies_full":
[
<bindata of 0xa5448180000100020000000107657861...>
],
"replies_tree":
[
{
"additional":
[
{
"do": 0,
"extended_rcode": 0,
"rdata":
{
"options":
[
{
"option_code": 12,
"option_data": <bindata of 0x00000000000000000000000000000000...>
}
],
"rdata_raw": <bindata of 0x000c0178000000000000000000000000...>
},
"type": GETDNS_RRTYPE_OPT,
"udp_payload_size": 1536,
"version": 0,
"z": 0
}
],
"answer":
[
{
"class": GETDNS_RRCLASS_IN,
"name": <bindata for example.com.>,
"rdata":
{
"nsdname": <bindata for a.iana-servers.net.>,
"rdata_raw": <bindata for a.iana-servers.net.>
},
"ttl": 3405,
"type": GETDNS_RRTYPE_NS
},
{
"class": GETDNS_RRCLASS_IN,
"name": <bindata for example.com.>,
"rdata":
{
"nsdname": <bindata for b.iana-servers.net.>,
"rdata_raw": <bindata of 0x0162c02b>
},
"ttl": 3405,
"type": GETDNS_RRTYPE_NS
}
],
"answer_type": GETDNS_NAMETYPE_DNS,
"authority": [],
"canonical_name": <bindata for example.com.>,
"header":
{
"aa": 0,
"ad": 0,
"ancount": 2,
"arcount": 1,
"cd": 0,
"id": 42308,
"nscount": 0,
"opcode": GETDNS_OPCODE_QUERY,
"qdcount": 1,
"qr": 1,
"ra": 1,
"rcode": GETDNS_RCODE_NOERROR,
"rd": 1,
"tc": 0,
"z": 0
},
"question":
{
"qclass": GETDNS_RRCLASS_IN,
"qname": <bindata for example.com.>,
"qtype": GETDNS_RRTYPE_NS
}
}
],
"status": GETDNS_RESPSTATUS_GOOD
} |
|
We need |
|
@wtoorop This only leaves me with errors: >getdns_query.exe -s -L -m @1.1.1.1~cloudflare-dns.com example.com -y 7
[15:08:46.124224] --- SETUP(TLS): add_WIN_cacerts_to_openssl_store : Adding Windows certificates to CA store
[15:08:46.136201] --- SETUP(TLS): add_WIN_cacerts_to_openssl_store : Error adding certificate 0:error:0B07C065:x509 certificate routines:X509_STORE_add_cert:cert already in hash table
An error occurred: 301 'The context has internal deficiencies'
>getdns_query.exe -s -L -m @1.1.1.1 -y 7 -K 'pin-sha256="yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc="'example.com
could not convert ''pin-sha256=yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc='example.com' into a public key pin.
Good pins look like: pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="
Please see RFC 7469 for details about the format
>getdns_query.exe -s -L @1.1.1.1 -y 7 -K 'pin-sha256="yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc="' example.com
could not convert ''pin-sha256=yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc='' into a public key pin.
Good pins look like: pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="
Please see RFC 7469 for details about the format
>getdns_query.exe -s -L @1.1.1.1~cloudflare-dns.com -y 7 -K 'pin-sha256="yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc="' example.com
could not convert ''pin-sha256=yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc='' into a public key pin.
Good pins look like: pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="
Please see RFC 7469 for details about the format |
|
Thanks All again for the debugging! I've fixed the error condition shown in the traces above and here is a new version of getdns_query.exe for testing. If this fixes the problem for you all I will produce new packages. |
|
@saradickinson Just dropped the new version of getdns_query in my Stubby folder. The problem is still there (even just with the |
|
I see the same as @jankal. |
|
OK, try this please: |
|
@saradickinson, it seems to be working now, but you be the judge.
|
|
@sergeevabc Thanks - that looks good to me. |
|
@saradickinson, so what was the problem after all? |
|
When Stubby built the local certificate store it hit an error condition if there was a duplicate certificate in the root cert store and stopped processing. The fix is to ignore duplicate certs. |
|
I've created a 0.0.4 installer with a custom fix for this issue - please see if this works. I've also opened getdnsapi/getdns#392 to implement a review of this code and a fix for the CA path/file issue for the next release. |
…rts in the root store.
|
@saradickinson, verified, issue is fixed on my end. P.S. I wonder why don’t you output Stubby’s version at once and require |
|
Perhaps I've missed something, but after downloading the latest installer and the getdns_query.zip from earlier today 1.1.1.1 still isn't working for me? |
|
@rwfeldmann, indeed, you’ve missed something, i.e. to provide the output of the following command: |
|
@rwfeldmann Thanks for the logs. I looks to me that the version of getdns_query.exe you have is the latest and is working just fine which means that the very latest installer (0.0.4) should also work for you. From the log I believe you still have the 0.0.3 version of Stubby installed - can you re-install the latest version and test Stubby again please? |
|
Success. I thought I'd downloaded the latest before I posted, but it's possible I overlooked it. It's working great. Thanks! |
|
Closing as resolved. |
Temporary fix for getdnsapi/stubby#87. Dete…
Temporary fix for getdnsapi/stubby#87. Dete…
Package changes: * PLIST adjustment; stubby no longer built by default Upstream changes: * 2018-12-21: Version 1.5.0 * RFE getdnsapi/stubby#121 log re-instantiating TLS upstreams (because they reached tls_backoff_time) at log level 4 (WARNING) * GETDNS_RESPSTATUS_NO_NAME for NODATA answers too * ZONEMD rr-type * getdns_query queries for addresses when a query name without a type is given. * RFE #408: Fetching of trust anchors will be retried after failure, after a certain backoff time. The time can be configured with getdns_context_set_trust_anchors_backoff_time(). * RFE #408: A "dnssec" extension that requires DNSSEC verification. When this extension is set, Indeterminate DNSSEC status will not be returned. * Issue #410: Unspecified ownership of get_api_information() * Fix for DNSSEC bug in finding most specific key when trust anchor proves non-existance of one of the labels along the authentication chain other than the non- existance of a DS record on a zonecut. * Enhancement getdnsapi/stubby#56 & getdnsapi/stubby#130: Configurable minimum and maximum TLS versions with getdns_context_set_tls_min_version() and getdns_context_set_tls_max_version() functions and tls_min_version and tls_max_version configuration parameters for upstreams. * Configurable TLS1.3 ciphersuites with the getdns_context_set_tls_ciphersuites() function and tls_ciphersuites config parameter for upstreams. * Bugfix in upstream string configurations: tls_cipher_list and tls_curve_list * Bugfix finding signer for validating NSEC and NSEC3s, which caused trouble with the partly tracing DNSSEC from the root up, introduced in 1.4.2. Thanks Philip Homburg * 2018-05-11: Version 1.4.2 * Bugfix getdnsapi/stubby#87: Detect and ignore duplicate certs in the Windows root CA store. * PR #397: No TCP sendto without TCP_FASTOPEN Thanks Emery Hemingway * Bugfix getdnsapi/stubby#106: Core dump when printing certain configuration. Thanks Han Vinke * Bugfix getdnsapi/stubby#99: Partly trace DNSSEC from the root up (for tld and sld), to find insecure delegations quicker. Thanks UniverseXXX * Bugfix: Allow NSEC spans starting from (unexpanded) wildcards Bug was introduced when dealing with CVE-2017-15105 * Bugfix getdnsapi/stubby#46: Don't assume trailing zero with string bindata's. Thanks Lonnie Abelbeck * Bugfix #394: Update src/compat/getentropy_linux.c in order to handle ENOSYS (not implemented) fallback. Thanks Brent Blood * Bugfix #395: Clarify that libidn2 dependency is for version 2.0.0 or higher. Thanks mire3212 * 2018-03-12: Version 1.4.1 * Bugfix #388: Prevent fallback to an earlier tries upstream within a single query. Thanks Robert Groenenberg * PR #387: Compile with OpenSSL with deprecated APIs disabled. Thanks Rosen Penev * PR #386: UDP failover improvements: - When all UDP upstreams fail, retry them (more or less) equally - Limit maximum UDP backoff (default to 1000) This is configurable with the --with-max-udp-backoff configure option. Thanks Robert Groenenberg * Bugfix: Find zonecut with DS queries (instead of SOA queries). Thanks Elmer Lastdrager * Bugfix #385: Verifying insecure NODATA answers (broken since 1.2.1). Thanks hanvinke * PR #384: Fix minor spelling and formatting. Thanks dkg. * Bugfix #382: Parallel install of getdns_query and getdns_server_mon * 2018-02-21: Version 1.4.0 * .so revision bump to please fedora packaging system. Thanks Paul Wouters * Specify the supported curves with getdns_context_set_tls_curves_list() An upstream specific list of supported curves may also be given with the tls_curves_list setting in the upstream dict with getdns_context_set_upstream_recursive_servers() * New tool getdns_server_mon for checking upstream recursive resolver's capabilities. * Improved handling of opportunistic back-off. If other transports are working, don't forcibly promote failed upstreams just wait for the re-try timer. * Hostname authentication with libressl Thanks Norbert Copones * Security bugfix in response to CVE-2017-15105. Although getdns was not vulnerable for this specific issue, as a precaution code has been adapted so that signatures of DNSKEYs, DSs, NSECs and NSEC3s can not be wildcard expansions when used with DNSSEC proofs. Only direct queries for those types are allowed to be wildcard expansions. * Bugfix PR#379: Miscelleneous double free or corruption, and corrupted memory double linked list detected issue, with serving functionality. Thanks maddie and Bruno Pagani * Security Bugfix PR#293: Check sha256 pinset's with OpenSSL native DANE functions for OpenSSL >= 1.1.0 with Viktor Dukhovni's danessl library for OpenSSL >= 1.0.0 don't allow for authentication exceptions (like self-signed certificates) otherwise. Thanks Viktor Dukhovni * libidn2 support. Thanks Paul Wouters * 2017-12-21: Version 1.3.0 * Bugfix #300: Detect dnsmasq and skip unit test that fails with it. Thanks Tim Rohsen and Konomi Kitten * Specify default available cipher suites for authenticated TLS upstreams with getdns_context_set_tls_ciphers_list() An upstream specific available cipher suite may also be given with the tls_cipher_list setting in the upstream dict with getdns_context_set_upstream_recursive_servers() * PR #366: Add support for TLS 1.3 and Chacha20-Poly1305 Thanks Pascal Ernster * Bugfix #356: Do Zero configuration DNSSEC meta queries over on the context configured upstreams. Thanks Andreas Schulze * Report default extension settings with getdns_context_get_api_information() * Specify locations at which CA certificates for verification purposes are located: getdns_context_set_tls_ca_path() getdns_context_set_tls_ca_file() * getdns_context_set_resolvconf() function to initialize a context upstreams and suffices with a resolv.conf file. getdns_context_get_resolvconf() to get the file used to initialize the context's upstreams and suffixes. getdns_context_set_hosts() function to initialize a context's LOCALNAMES namespace. getdns_context_get_hosts() function to get the file used to initialize the context's LOCALNAMES namespace. * get which version of OpenSSL was used at build time and at run time when available with getdns_context_get_api_information() * GETDNS_RETURN_IO_ERROR return error code * Bugfix #359: edns_client_subnet_private should set family Thanks Daniel Areiza & Andreas Schulze * Bugfix getdnsapi/stubby#34: Segfault issue with native DNSSEC validation. Thanks Bruno Pagani * 2017-11-11: Version 1.2.1 * Handle more I/O error cases. Also, when an I/O error does occur, never stop listening (with servers), and never exit (when running the built-in event loop). * Bugfix: Tolerate unsigned and unused RRsets in the authority section. Fixes DNSSEC with BIND upstream. * Bugfix: DNSSEC validation without support records * Bugfix: Validation of full recursive DNSKEY lookups * Bugfix: Retry to validate full recursion BOGUS replies with zero configuration DNSSEC only when DNSSEC was actually requested * Bugfix #348: Fix a linking issue in stubby when libbsd is present Thanks Remi Gacogne * More robust scheduling; Eliminating a segfault with long running applications. * Miscellaneous Windows portability fixes from Jim Hague. * Fix Makefile dependencies for parallel install. Thanks ilovezfs * 2017-09-29: Version 1.2.0 * Bugfix of rc1: authentication of first query with TLS Thanks Travis Burtrum * A function to set the location for library specific data, like trust-anchors: getdns_context_set_appdata(). * Zero configuration DNSSEC - build upon the scheme described in RFC7958. The URL from which to fetch the trust anchor, the verification CA and email can be set with the new getdns_context_set_trust_anchor_url(), getdns_context_set_trust_anchor_verify_CA() and getdns_context_set_trust_anchor_verify_email() functions. The default values are to fetch from IANA and to validate with the ICANN CA. * Update of Stubby with yaml configuration file and logging from a certain severity support. * Fix tpkg exit status on test failure. Thanks Jim Hague. * Refined logging levels for upstream statistics * Reuse (best behaving) backed-off TLS upstreams when non are usable. * Let TLS upstreams back-off a incremental amount of time. Back-off time starts with 1 second and is doubled each failure, but will not exceed the time given by getdns_context_set_tls_backoff_time() * Make TLS upstream management more resilient to temporary outages (like laptop sleeps) * 2017-09-04: Version 1.1.3 * Small bugfixes that came out of static analysis * No annotations with the output of getdns_query anymore, unless -V option is given to increase verbosity Thanks Ollivier Robert * getdns_query will now exit with failure status if replies are BOGUS * Bugfix: dnssec_return_validation_chain now also works when fallback to full recursion was needed with dnssec_roadblock_avoidance * More clear build instructions from Paul Hoffman. Thanks. * Bugfix #320.1: Eliminate multiple closing of file descriptors Thanks Neil Cook * Bugfix #320.2: Array bounds bug in upstream_select Thanks Neil Cook * Bugfix #318: getdnsapi/getdns/README.md links to nonexistent wiki pages. Thanks James Raftery * Bugfix #322: MacOS 10.10 (Yosemite) provides TCP fastopen interface but does not have it implemented. Thanks Joel Purra * Compile without Stubby by default. Stubby now has a git repository of its own. The new Stubby repository is added as a submodule. Stubby will still be build alongside getdns with the --with-stubby configure option. * 2017-07-03: Version 1.1.2 * Bugfix for parallel make install * Bugfix to trigger event callbacks on socket errors * A getdns_context_set_logfunc() function with which one may register a callback log function for certain library subsystems at certain levels. Currently this can only be used for upstream stastistics subsystem. * 2017-06-15: Version 1.1.1 * Bugfix #306 hanging/segfaulting on certain (IPv6) upstream failures * Spelling fix s/receive/receive. Thanks Andreas Schulze. * Added stubby-setdns-macos.sh script to support Homebrew formula * Include stubby.conf in the districution tarball * Bugfix #286 reschedule reused listening addresses * Bugfix #166 Allow parallel builds and unit-tests * NSAP-PTR, EID and NIMLOC, TALINK, AVC support * Bugfix of TA RR type * OPENPGPKEY and SMIMEA support * Bugfix TAG rdata type presentation format for CAA RR type * Bugfix Zero sized gateways with IPSECKEY gateway_type 0 * Guidance for integration with systemd * Also check for memory leaks with advances server capabilities. * Bugfix convert IP string to IP dict with getdns_str2dict() directly. ok'ed by root@zta.lk
Stubby is unable to connect to 1.1.1.1 for DNS-over-TLS cause it cannot validate the certificate on Windows 10 Build 16299
Following configuration should work:
Unfortunatly it fails with a
Verify failed : Transport=TLS - *Failure* - (20) "unable to get local issuer certificate"This should really be fixed! Why doesn't Stubby just use the Windows certificate store to validate the TLS certificates? - Even just a cacerts file would do it, so the users can edit it and add the required certificates if they want to set up their own DNS-over-TLS server within Stubby.
@saradickinson @wtoorop
Also see #46
The text was updated successfully, but these errors were encountered: