no valid transports or upstreams available #46

zyrill · 2017-11-18T16:45:46Z

Hi guys

I can't seem to get stubby to behave on my (linux) router. I'm running stubby successfully on my windows machine. But on the router, I always get errors when testing if the stubby works with dig @192.168.66.1 -p 453 www.heise.de.

Could you guys help me out pls? I'm sure I've just forgotten something, but I can't figure out what. I've also uploaded the error messages for better readability to https://pastebin.com/V696AZtQ

Googling for a few hours didn't provide me with a clue how to solve the problem, sadly - but I think it may have something to do with missing intermediate certificates? But where would I put those?

So here's the message:
stubby -l [16:36:54.381273] STUBBY: Read config from file /mod/root/.stubby.yml [16:36:54.383812] STUBBY: Starting DAEMON.... [16:36:57.602079] STUBBY: 145.100.185.15 : Conn opened: TLS - Strict Profile [16:36:57.695453] STUBBY: 145.100.185.15 : Verify failed : Transport=TLS - *Failure* - (20) "unable to get local issuer certificate" [16:36:57.700220] STUBBY: 145.100.185.15 : Conn closed : Transport=TLS - *Failure* [16:36:57.704930] STUBBY: 145.100.185.16 : Conn opened: TLS - Strict Profile [16:36:57.708250] STUBBY: 145.100.185.15 : Conn closed: TLS - Resps= 0, Timeouts = 0, Curr_auth = Failed, Keepalive(ms)= 0 [16:36:57.713019] STUBBY: 145.100.185.15 : Upstream : TLS - Resps= 0, Timeouts = 0, Best_auth = Failed [16:36:57.713692] STUBBY: 145.100.185.15 : Upstream : TLS - Conns= 0, Conn_fails= 0, Conn_shuts= 0, Backoffs = 0 [16:36:57.794389] STUBBY: 145.100.185.16 : Verify failed : Transport=TLS - *Failure* - (20) "unable to get local issuer certificate" [16:36:57.798158] STUBBY: 145.100.185.16 : Conn closed : Transport=TLS - *Failure* [16:36:57.801759] STUBBY: 185.49.141.37 : Conn opened: TLS - Strict Profile [16:36:57.803273] STUBBY: 145.100.185.16 : Conn closed: TLS - Resps= 0, Timeouts = 0, Curr_auth = Failed, Keepalive(ms)= 0 [16:36:57.803965] STUBBY: 145.100.185.16 : Upstream : TLS - Resps= 0, Timeouts = 0, Best_auth = Failed [16:36:57.804634] STUBBY: 145.100.185.16 : Upstream : TLS - Conns= 0, Conn_fails= 0, Conn_shuts= 0, Backoffs = 0 [16:36:57.857548] STUBBY: 185.49.141.37 : Verify failed : Transport=TLS - *Failure* - (20) "unable to get local issuer certificate" [16:36:57.859055] STUBBY: 185.49.141.37 : Conn closed : Transport=TLS - *Failure* [16:36:57.861521] STUBBY: 2001:610:1:40ba:145:100:185:15 : Conn opened: TLS - Strict Profile [16:36:57.862118] STUBBY: 185.49.141.37 : Conn closed: TLS - Resps= 0, Timeouts = 0, Curr_auth = Failed, Keepalive(ms)= 0 [16:36:57.864410] STUBBY: 185.49.141.37 : Upstream : TLS - Resps= 0, Timeouts = 0, Best_auth = Failed [16:36:57.870816] STUBBY: 185.49.141.37 : Upstream : TLS - Conns= 0, Conn_fails= 0, Conn_shuts= 0, Backoffs = 0 [16:36:57.937756] STUBBY: 2001:610:1:40ba:145:100:185:15 : Verify failed : Transport=TLS - *Failure* - (20) "unable to get local issuer certificate" [16:36:57.940717] STUBBY: 2001:610:1:40ba:145:100:185:15 : Conn closed : Transport=TLS - *Failure* [16:36:57.945270] STUBBY: 2001:610:1:40ba:145:100:185:16 : Conn opened: TLS - Strict Profile [16:36:57.947053] STUBBY: 2001:610:1:40ba:145:100:185:15 : Conn closed: TLS - Resps= 0, Timeouts = 0, Curr_auth = Failed, Keepalive(ms)= 0 [16:36:57.950262] STUBBY: 2001:610:1:40ba:145:100:185:15 : Upstream : TLS - Resps= 0, Timeouts = 0, Best_auth = Failed [16:36:57.953177] STUBBY: 2001:610:1:40ba:145:100:185:15 : Upstream : TLS - Conns= 0, Conn_fails= 0, Conn_shuts= 0, Backoffs = 0 [16:36:58.007956] STUBBY: 2001:610:1:40ba:145:100:185:16 : Verify failed : Transport=TLS - *Failure* - (20) "unable to get local issuer certificate" [16:36:58.009320] STUBBY: 2001:610:1:40ba:145:100:185:16 : Conn closed : Transport=TLS - *Failure* [16:36:58.011621] STUBBY: 2a04:b900:0:100::38 : Conn opened: TLS - Strict Profile [16:36:58.012227] STUBBY: 2001:610:1:40ba:145:100:185:16 : Conn closed: TLS - Resps= 0, Timeouts = 0, Curr_auth = Failed, Keepalive(ms)= 0 [16:36:58.013992] STUBBY: 2001:610:1:40ba:145:100:185:16 : Upstream : TLS - Resps= 0, Timeouts = 0, Best_auth = Failed [16:36:58.017795] STUBBY: 2001:610:1:40ba:145:100:185:16 : Upstream : TLS - Conns= 0, Conn_fails= 0, Conn_shuts= 0, Backoffs = 0 [16:36:58.064408] STUBBY: 2a04:b900:0:100::38 : Verify failed : Transport=TLS - *Failure* - (20) "unable to get local issuer certificate" [16:36:58.068870] STUBBY: 2a04:b900:0:100::38 : Conn closed : Transport=TLS - *Failure* [16:36:58.073570] STUBBY: 89.233.43.71 : Conn opened: TLS - Strict Profile [16:36:58.077700] STUBBY: 2a04:b900:0:100::38 : Conn closed: TLS - Resps= 0, Timeouts = 0, Curr_auth = Failed, Keepalive(ms)= 0 [16:36:58.082302] STUBBY: 2a04:b900:0:100::38 : Upstream : TLS - Resps= 0, Timeouts = 0, Best_auth = Failed [16:36:58.087956] STUBBY: 2a04:b900:0:100::38 : Upstream : TLS - Conns= 0, Conn_fails= 0, Conn_shuts= 0, Backoffs = 0 [16:36:58.164430] STUBBY: 89.233.43.71 : Verify failed : Transport=TLS - *Failure* - (20) "unable to get local issuer certificate" [16:36:58.169350] STUBBY: 89.233.43.71 : Conn closed : Transport=TLS - *Failure* [16:36:58.174020] STUBBY: 51.15.70.167 : Conn opened: TLS - Strict Profile [16:36:58.174591] STUBBY: 89.233.43.71 : Conn closed: TLS - Resps= 0, Timeouts = 0, Curr_auth = Failed, Keepalive(ms)= 0 [16:36:58.175285] STUBBY: 89.233.43.71 : Upstream : TLS - Resps= 0, Timeouts = 0, Best_auth = Failed [16:36:58.175885] STUBBY: 89.233.43.71 : Upstream : TLS - Conns= 0, Conn_fails= 0, Conn_shuts= 0, Backoffs = 0 [16:36:58.252260] STUBBY: 51.15.70.167 : Verify failed : Transport=TLS - *Failure* - (20) "unable to get local issuer certificate" [16:36:58.255366] STUBBY: 51.15.70.167 : Conn closed : Transport=TLS - *Failure* [16:36:58.258880] STUBBY: *FAILURE* no valid transports or upstreams available! [16:36:58.260495] STUBBY: 51.15.70.167 : Conn closed: TLS - Resps= 0, Timeouts = 0, Curr_auth = Failed, Keepalive(ms)= 0 [16:36:58.263636] STUBBY: 51.15.70.167 : Upstream : TLS - Resps= 0, Timeouts = 0, Best_auth = Failed [16:36:58.264774] STUBBY: 51.15.70.167 : Upstream : TLS - Conns= 0, Conn_fails= 0, Conn_shuts= 0, Backoffs = 0

The text was updated successfully, but these errors were encountered:

wtoorop · 2017-11-21T15:02:22Z

Yes, this is due to a missing certificate store.
What directory does openssl version -d return? Is there a cert directory underneath it?
Even though you might fix the issue by provisioning a store... I do think that it should not be needed when a sha256 pinset is given, so this is a bug that needs to be resolved. We have an getdns issue on this b.t.w. See: getdnsapi/getdns#293

wtoorop · 2017-11-21T15:33:43Z

Although it appears unrelated to getdnsapi/getdns#293 on the surface, it actually is not, and the solution mentioned in there should resolve this too. So that is why I labeled this duplicate.

zyrill · 2017-11-21T17:17:34Z

Thanks for the response, @wtoorop I don't have openssl installed, the only ssl related files on my (router) system are:
# find / | grep ssl
/bin/openssl_genrsa
/bin/openssl_req
/lib/libavmssl.so
/lib/libavmssl.so.2
/lib/libavmssl.so.2.0.0
/lib/libssl.so
/lib/libssl.so.1
/lib/libssl.so.1.0.0
/sys/module/kdsldmod/sections/.text.DHCPOPTIONS_classless_iproute_alloc
/sys/module/kdsldmod/sections/.text.DHCPOPTIONS_classless_iproute_free
/sys/module/kdsldmod/sections/.text.ipaccesslogging_string
/sys/module/kdsldmod/sections/.text.ipaccesslogging_parse
/usr/lib/freetz/libssl.so
/usr/lib/freetz/libssl.so.1.0.0
/var/flash/websrv_ssl_key.pem
/var/flash/websrv_ssl_cert.pem
/var/tmp/websrv_ssl_cert.pem

However, if you're looking for the path to where the (SSH?) keys are stored, I have this to offer:
# ll /var/mod/root/
0 drwxr-xr-x 3 root root 120 Nov 21 10:38 ./
0 drwxr-xr-x 11 root root 220 Jan 1 1970 ../
0 drwxr-xr-x 2 root root 40 Nov 21 10:38 .getdns/
0 lrwxrwxrwx 1 root root 23 Jan 1 1970 .profile -> /tmp/flash/mod/.profile
0 lrwxrwxrwx 1 root root 31 Jan 1 1970 .ssh -> /tmp/flash/authorized_keys_root/
0 lrwxrwxrwx 1 root root 21 Nov 15 10:25 .stubby.yml -> /tmp/flash/stubby.yml

Where does stubby look for the certificate store by default?

I might add that I have no idea how to provision a store that works with getdns. If that's a temporary fix, could somebody pls point me in the right direction?

wtoorop · 2017-11-29T14:14:14Z

Well... getdns uses the OpenSSL SSL_CTX_load_verify_locations function. It is hard to tell what the location would be without the openssl command line tool (maybe we could provide this information via the getdns_context_get_api_information function (i.e. -i option with stubby) in the next getdns release), but it is quite often /etc/ssl/certs.
Although it is a bug that you need these even if you have SPKI pinsets, it might still be a good idea to have the default locations configurable in getdns anyway (for upstreams which need to be authenticated by only name).
Oh... b.t.w. I forgot to mention, but you could bypass the error by disabling authentication too.
Of course you'd have only opportunistic DNS-over-TLS, but maybe better than nothing for the time being.

Kdmeizk · 2018-02-17T23:32:40Z

I had no choice but to reinstall Windows 7. Since this, Stubby gives a same message as in this bug:

Failure - (20) "unable to get local issuer certificate"

So, I assume it is related to this bug.

saradickinson · 2018-02-19T11:40:44Z

@Kdmeizk Hmm, a clean install of Stubby shouldn't give this error unless there is something wrong with the certificate. What version of Stubby are you using, how did you install and are you using the default Stubby config?

Kdmeizk · 2018-02-21T01:31:32Z

@saradickinson Ahaha, I tested until the latest optional update from Windows Update related to certificates and TLS, and it is this very last update which solved the problem. I will test more precisely later to find out what optional updates are concerned, or maybe you know them already?

~~It seems KB3172605 solved the problem, but I got it by installing other optional updates I believe. I will check.~~

PS: I have the latest version of Stubby for Windows (0.2.0), default/clean config

saradickinson · 2018-02-21T11:57:02Z

@Kdmeizk thanks for the info! I've added a link to this page as a known issue on the wiki for the Windows installer:
https://dnsprivacy.org/wiki/display/DP/Windows+installer+for+Stubby

Kdmeizk · 2018-02-28T21:28:37Z

@saradickinson Well, I thought wrong… I tried on a clean install but it did not work, even having done absolutely all the updates. I probably got lucky because I simply reset Windows 7 with the upgrade mode, so the necessary certificate was probably still here. I think the problem is the same as for curl. curl must have a certificate with him to work on Windows, so there is one provided with curl. It is probably the same for Stubby, which you are fixing in this bug if I understood?

saradickinson · 2018-03-02T14:29:17Z

The Stubby for Windows installer comes with its own certificate store which is why I don't think this is the same issue as the curl problem (where the system has no certificate store by default).
Does it give this message for all the upstreams or do you have a single upstream configured?
Also, I'm planning to update the Windows installer in the next couple of weeks with the 1.4 release of getdns which includes the option to use just a SPKI pin for an upstream (not requiring a cert) which would at least provide a workaround for you.

Kdmeizk · 2018-03-02T16:34:19Z

Does it give this message for all the upstreams

Yes it gives the same message for any upstream.

The Stubby for Windows installer comes with its own certificate store

How it works? Is this a file included with the others or Windows installer puts it in the Registry for example? Maybe I can check if this certificate exists after the installation of Stubby.

jankal · 2018-04-02T12:29:04Z

This is also related if one wants to setup cloudflares 1.1.1.1 DNS-over-TLS servers via Stubby on Windows.
Following configuration should work:

upstream_recursive_servers:
  - address_data: 1.1.1.1
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=

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

This is important!

jankal · 2018-04-02T12:33:10Z

See also #87

george-chakhidze · 2018-04-02T12:58:00Z

I have same problem too: Verify failed : Transport=TLS - *Failure* - (20) "unable to get local issuer certificate".
OS: Windows
Relevant entries from stubby.yml:

upstream_recursive_servers:
# Quad9 DNS-over-TLS server
  - address_data: 9.9.9.9
    tls_auth_name: "dns.quad9.net"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: ZMZ1T16d9Qc5uvRpUn/mu6fh4+IdoJGOEKjANut91Io=
    tls_port: 853
# CloudFlare DNS-over-TLS server
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=
    tls_port: 853

I have manually downloaded entire chains of X.509 certificates from both 9.9.9.9:853 and 1.1.1.1:853 endpoints and installed in Windows certificate store. Did not help.

Using latest Windows installer from here.

Verbose log output:

"C:\Program Files\Stubby\stubby.exe" -C "C:\Program Files\Stubby\stubby.yml" -v 7
[13:00:43.849858] STUBBY: Read config from file C:\Program Files\Stubby\stubby.yml
[13:00:43.849858] STUBBY: Starting DAEMON....
Could not schedule query: The context has internal deficiencies
[13:00:50.216157] STUBBY: 9.9.9.9                                  : Conn opened: TLS - Strict Profile
[13:00:50.344070] STUBBY: 9.9.9.9                                  : Verify failed : Transport=TLS - *Failure* -  (20) "unable to get local issuer certificate"
[13:00:50.344070] STUBBY: 9.9.9.9                                  : Conn closed   : Transport=TLS - *Failure*
[13:00:50.344070] STUBBY: 1.1.1.1                                  : Conn opened: TLS - Strict Profile
[13:00:50.344070] STUBBY: 9.9.9.9                                  : Conn closed: TLS - Resps=     0, Timeouts  =     0, Curr_auth = Failed, Keepalive(ms)=     0
[13:00:50.344070] STUBBY: 9.9.9.9                                  : Upstream   : TLS - Resps=     0, Timeouts  =     0, Best_auth = Failed
[13:00:50.344070] STUBBY: 9.9.9.9                                  : Upstream   : TLS - Conns=     0, Conn_fails=     0, Conn_shuts=      0, Backoffs     =     0
[13:00:50.484653] STUBBY: 1.1.1.1                                  : Verify failed : Transport=TLS - *Failure* -  (20) "unable to get local issuer certificate"
[13:00:50.484653] STUBBY: 1.1.1.1                                  : Conn closed   : Transport=TLS - *Failure*
[13:00:50.484653] STUBBY: *FAILURE* no valid transports or upstreams available!
[13:00:50.484653] STUBBY: 1.1.1.1                                  : Conn closed: TLS - Resps=     0, Timeouts  =     0, Curr_auth = Failed, Keepalive(ms)=     0
[13:00:50.484653] STUBBY: 1.1.1.1                                  : Upstream   : TLS - Resps=     0, Timeouts  =     0, Best_auth = Failed
[13:00:50.484653] STUBBY: 1.1.1.1                                  : Upstream   : TLS - Conns=     0, Conn_fails=     0, Conn_shuts=      0, Backoffs     =     0
[13:00:50.484653] STUBBY: *FAILURE* no valid transports or upstreams available!
Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
[13:00:50.484653] STUBBY: *FAILURE* no valid transports or upstreams available!
Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
[13:00:50.484653] STUBBY: *FAILURE* no valid transports or upstreams available!
Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports

Viktor45 · 2018-04-02T17:25:25Z

i have same issues on my entware router and fixed this with
opkg install ca-certificates
opkg install ca-bundle

i hope this helps a lot to somebody, who is setting stubby first time with entware

wtoorop · 2018-04-03T12:07:43Z

@jankal Yes this is important and has been adressed in the getdns-1.4.0 release (or should have been adressed).

When compiled with OpenSSL 1.1.0 or higher it will use the native DANE functions for pin authentication. A pin authentication is then enough, and no Certificate Authority needs to vouch for the name then. With OpenSSL 1.0.2 or higher Viktor's ssl_dane library will be used.

Which version of getdns do you use? The output of the stubby -i command (or stubby.exe -i) should tell...

sergeevabc · 2018-04-03T12:29:59Z

@wtoorop, since I have the same issue as @jankal, let me reply as well.

"api_version_number": 132058112,
"api_version_string": <bindata of "December 2015">,
"compilation_comment": <bindata of "getdns 1.2.2-rc1 configured on 2"...>

"openssl_build_version_number": 268443855,
"resolution_type": GETDNS_RESOLUTION_STUB,
"version_number": 16908737,
"version_string": <bindata of "1.2.2-rc1">

jankal · 2018-04-03T12:46:39Z

"api_version_number": 132058112,
  "api_version_string": <bindata of "December 2015">,
  "compilation_comment": <bindata of "getdns 1.2.2-rc1 configured on 2"...>,
  "default_hosts_location": <bindata of "C:\Windows\System32\Drivers\etc\"...>,
  "default_resolvconf_location": <bindata of "/etc/resolv.conf">,
  "default_trust_anchor_location": <bindata of "/mingw64/etc/unbound/getdns-root"...>,
  "implementation_string": <bindata of "https://getdnsapi.net">,
  "listen_addresses":
  [
    {
      "address_data": <bindata for 127.0.0.1>,
      "address_type": <bindata of "IPv4">,
      "port": 53
    },
    {
      "address_data": <bindata for ::1>,
      "address_type": <bindata of "IPv6">,
      "port": 53
    }
  ],
  "openssl_build_version_number": 268443855,
  "resolution_type": GETDNS_RESOLUTION_STUB,
  "version_number": 16908737,
  "version_string": <bindata of "1.2.2-rc1">

wtoorop · 2018-04-03T12:50:21Z

@saradickinson We need to update the Windows build...

wtoorop · 2018-04-03T12:52:31Z

Oh reading back I see that Sara mentioned all this earlier already.

We'll provide a Windows build with getdns-1.4.1 soon, with which you can work around the issue by providing a SPKI pin.

wtoorop · 2018-04-03T12:56:31Z

Oh and 1.3.0 introduced configuration parameters for specifying the CA store, so it should work with that as well:https://getdnsapi.net/functions/getdns_context_set_tls_ca_path.html

So you can specify something like

tls_ca_path: "C:\ssl\certs"

in stubby.yml.

jankal · 2018-04-03T12:57:41Z

@wtoorop I only added this in here so you know it's even more important now, when everyone wants to use Stubby with 1.1.1.1. I hope, a new build will be provided soon (I haven't got any build environment installed right now, currently I only develop using Docker).

set_tls_ca_path seems to be the solution we've all been looking for.

jankal · 2018-04-03T12:58:42Z

@wtoorop Is set_tls_ca_file also supported?

wtoorop · 2018-04-03T13:06:37Z

Yes, all getdns_context_set_(*) works from the .yml file (so https://getdnsapi.net/functions/getdns_context_set_resolution_type.html and all functions below it on that page) + all the extension settings, but I said it wrong. You have to strip of getdns_context_set_ in the .yml file. So specifying a CA file:

tls_ca_file: "C:\ssl\certs.pem"

And to specify a CA path:

tls_ca_path: "C:\ssl\certs"

jankal · 2018-04-03T13:07:54Z

@wtoorop You are awesome!

wtoorop · 2018-04-03T13:08:53Z

Thanks! :-)

I do think we still have to integrate with the native Windows CA store though...

jankal · 2018-04-03T13:12:42Z

C:\Program Files\Stubby>"C:\Program Files\Stubby\stubby.exe" -C "C:\Program Files\Stubby\stubby.yml" -l
Could not configure context with config dict: The library did not have the requested API feature implemented.
Could not parse config file "C:\Program Files\Stubby\stubby.yml": The library did not have the requested API feature implemented.

when using tls_ca_file: 'C:\\Users\\alexa\\ca-bundle.crt'
I've stored a Firefox ca-bundle.crt at C:\Users\alexa\ca-bundle.crt.

george-chakhidze · 2018-04-03T13:19:46Z

@jankal Current build of Stubby for Windows is bundled with 1.2.1rc-1 version of getdns — we must wait for new release...

jankal · 2018-04-03T13:21:51Z

@george-chakhidze the hell you're right. I hate waiting.

saradickinson · 2018-04-03T13:28:29Z

@wtoorop I'll work on updating the Windows installer asap

saradickinson · 2018-04-05T10:26:05Z

Hi All, A new Windows installer is a now available using getdns 1.4.1:
https://dnsprivacy.org/wiki/display/DP/Windows+installer+for+Stubby
However note @wtoorop the ca_path/ca-file settings are not used for the Windows cert config in 1.4.1, the code currently just loads from the system root store. We'll need to fix this.
But this release should allow using just pins for validation as a workaround.

abelbeck · 2018-04-14T14:23:00Z

I have a Linux issue related to this topic, my stubby.yml contains:

tls_ca_file: "/usr/lib/ssl/certs/ca-bundle.crt"

stubby -i shows

    "tls_ca_file": <bindata of "/usr/lib/ssl/certs/ca-bundle.crt"...>,

I'm getting (20) unable to get local issuer certificate

Additionally, a strace stubby -l 2>&1 | grep 'ca-bundle' shows

open("/usr/lib/ssl/certs/ca-bundle.crt`", O_RDONLY) = -1 ENOENT (No such file or directory)

Somewhere a trailing garbage character is being added to the filename - grave accent here.

BTW, I'm using libyaml, version 0.1.7

wtoorop · 2018-04-23T13:05:16Z

@abelbeck Thanks. This was actually quite a severe bug, which can be fixed with attached patch:

0001-Force-trailing-0-with-string-config-settings.patch.gz

abelbeck · 2018-04-23T14:02:55Z

@wtoorop I can confirm your fix solves the issue.

Thanks for your prompt solution.

Ref: getdnsapi/stubby#46 (comment)

saradickinson · 2018-05-04T09:57:39Z

Closing as I think all the issues are resolved.

Kdmeizk · 2018-05-11T01:04:06Z

@saradickinson
#46 (comment)
#46 (comment)

You can remove the point about a possible Windows update required for certificate verification to work because Stubby works perfectly without any Windows update now :)

Here:
https://dnsprivacy.org/wiki/display/DP/Windows+installer+for+Stubby#WindowsinstallerforStubby-KnownIssues

saradickinson · 2018-05-11T09:21:22Z

Thanks - done!

See: - getdnsapi#46 (comment) - https://getdnsapi.net/doxygen/group__getdns__context.html#ga2b8d16f0582e7643701aad1673732de4

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

Zamiell · 2019-10-02T20:40:48Z

I ran into this issue today with a vanilla Stubby installation on Windows 10. The error message of *FAILURE* no valid transports or upstreams available! is fairly misleading, as it implies that the "stubby.yml" file has no configured upstream servers, or that the current configured upstream servers are not available to be contacted. (Neither of which is the case, because the real problem is just certificate validation.)

@saradickinson Is it possible for a separate error message to be created, or the existing one changed, or something along those lines?

wellloaded · 2021-08-01T18:24:22Z

I just wanted to add to this topic that the error in the subject happens also when the Internet connectivity becomes slowish/unreliable. It is common for me to see these entries in the log when my router is connected via 3G/4G and there's a temporary issue with the mobile provider. E.g. today my 30Mb 4G service was capped to 0.5Mb due to fair usage policy and Stubby went banana.

So two points from myself:

Perhaps the Failure message could be a bit more descriptive to help troubleshooting. I bet there are a bunch of different root causes that generate the very same log entry. Ideally you will want one entry per root cause.
Can Stubby be re-thught to perform also over slow/unreliable networks? (rather than just fail)?

saradickinson · 2021-08-04T13:49:37Z

@wellloaded @Zamiell Points taken and acknowledged.

We are quite limited by the internal error reporting mechanism available in getdns which was not designed to transmit transport specific error messages back on failure. With full logging the error encountered on each separate upstream should be reported when the connection fails e.g.
[13:00:50.344070] STUBBY: 9.9.9.9 : Verify failed : Transport=TLS - *Failure* - (20) "unable to get local issuer certificate"
or a handshake failure, or etc.
But I agree we could improve the *FAILURE* no valid transports or upstreams available! message. Perhaps:
FAILURE: None of the configured upstreams could be reached, please check full logging output for specific reasons for each upstream.??
Stubby should continually re-try all upstreams based on a back-off model, but I know there are some situations where this doesn't provide reliable performance. The long awaited re-factor of upstream handling should hopefully also introduce more robust re-try mechanisms. @wtoorop please note this issue as input to that work.

wellloaded · 2021-08-04T19:05:55Z

It might be not the right context but I'm starting to wonder if a wireguard like approach (encryption peering with no formal handshaking) would be more suitable for Stubby operations. I'm not suggesting to wireguard into the DNS resolver network but rather to use the same fast and painless end-to-end encryption idea. Of course that's not only Stubby and would need to come from the resolver side too, but it could be an improvement for sloppy networks and perhaps even improve the overall performance under normal conditions.

Just a thought

wtoorop added bug duplicate labels Nov 21, 2017

wtoorop mentioned this issue Jan 11, 2018

Devel/spki pinset via tlsa checking getdnsapi/getdns#371

Merged

jankal mentioned this issue Apr 2, 2018

Stubby unable to connect to Cloudflare's 1.1.1.1 (WINDOWS) #87

Closed

abelbeck added a commit to astlinux-project/astlinux that referenced this issue Apr 23, 2018

getdns, add upstream patch

033d647

Ref: getdnsapi/stubby#46 (comment)

saradickinson closed this as completed May 4, 2018

MatthewVance added a commit to MatthewVance/stubby that referenced this issue Nov 28, 2018

Provide tls_ca_path example

18fa6e1

See: - getdnsapi#46 (comment) - https://getdnsapi.net/doxygen/group__getdns__context.html#ga2b8d16f0582e7643701aad1673732de4

MatthewVance mentioned this issue Nov 28, 2018

Provide tls_ca_path example #141

Merged

no valid transports or upstreams available #46

no valid transports or upstreams available #46

Comments

zyrill commented Nov 18, 2017 • edited Loading

wtoorop commented Nov 21, 2017

wtoorop commented Nov 21, 2017

zyrill commented Nov 21, 2017 • edited Loading

wtoorop commented Nov 29, 2017

Kdmeizk commented Feb 17, 2018

saradickinson commented Feb 19, 2018

Kdmeizk commented Feb 21, 2018 • edited Loading

saradickinson commented Feb 21, 2018

Kdmeizk commented Feb 28, 2018

saradickinson commented Mar 2, 2018

Kdmeizk commented Mar 2, 2018

jankal commented Apr 2, 2018

jankal commented Apr 2, 2018

george-chakhidze commented Apr 2, 2018 • edited Loading

Viktor45 commented Apr 2, 2018 • edited Loading

wtoorop commented Apr 3, 2018

sergeevabc commented Apr 3, 2018

jankal commented Apr 3, 2018 • edited Loading

wtoorop commented Apr 3, 2018

wtoorop commented Apr 3, 2018

wtoorop commented Apr 3, 2018 • edited Loading

jankal commented Apr 3, 2018

jankal commented Apr 3, 2018

wtoorop commented Apr 3, 2018

jankal commented Apr 3, 2018

wtoorop commented Apr 3, 2018

jankal commented Apr 3, 2018 • edited Loading

george-chakhidze commented Apr 3, 2018

jankal commented Apr 3, 2018

saradickinson commented Apr 3, 2018

saradickinson commented Apr 5, 2018

abelbeck commented Apr 14, 2018

wtoorop commented Apr 23, 2018 • edited Loading

abelbeck commented Apr 23, 2018

saradickinson commented May 4, 2018

Kdmeizk commented May 11, 2018

saradickinson commented May 11, 2018

Zamiell commented Oct 2, 2019 • edited Loading

wellloaded commented Aug 1, 2021 • edited Loading

saradickinson commented Aug 4, 2021

wellloaded commented Aug 4, 2021

zyrill commented Nov 18, 2017 •

edited

Loading

zyrill commented Nov 21, 2017 •

edited

Loading

Kdmeizk commented Feb 21, 2018 •

edited

Loading

george-chakhidze commented Apr 2, 2018 •

edited

Loading

Viktor45 commented Apr 2, 2018 •

edited

Loading

jankal commented Apr 3, 2018 •

edited

Loading

wtoorop commented Apr 3, 2018 •

edited

Loading

jankal commented Apr 3, 2018 •

edited

Loading

wtoorop commented Apr 23, 2018 •

edited

Loading

Zamiell commented Oct 2, 2019 •

edited

Loading

wellloaded commented Aug 1, 2021 •

edited

Loading