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).

About Stubby

Stubby is an application that acts as a local DNS Privacy stub resolver (using DNS-over-TLS). Stubby encrypts DNS queries sent from a client machine (desktop or laptop) to a DNS Privacy resolver increasing end user privacy. Stubby is in the early stages of development but is suitable for technical/advanced users. A more generally user-friendly version is on the way!

Stubby provides DNS Privacy by:

• Running as a daemon
• Listening on the loopback address to send all outgoing DNS queries received on that address out over TLS
• Using a default configuration which provides Strict Privacy and uses a subset of the available DNS Privacy servers

Stubby is developed by the getdns team.

Stubby can be used as a command line tool requiring the user to manually modify the system DNS resolvers. A development version of a Stubby Manager GUI is also available for Windows, see Stubby Mananger GUI.

Documentation

See Stubby Homepage for more details

Dependencies

Stubby uses getdns and requires the 1.5.0 release of getdns or later.

It also requires yaml.

Installing Using a Package Manager

Check to see if stubby, getdns and yaml are available via a package manager for your system: https://repology.org/metapackage/stubby/versions https://repology.org/metapackage/getdns/versions https://repology.org/metapackage/libyaml/versions

• A Windows Installer is now available for Stubby. From version 0.4.0 the msi installer includes a development version of a Windowd GUI.
• A Homebrew package for stubby is now available (brew install stubby).
• A GUI for macOS is also available for testing

If you need to install getdns from source, see the section at the end of this document.

Build Stubby from source

A Dockerfile is provided in the contrib directory to build a Docker image from source. See Docker usage docs.

Get the code:

git clone https://github.com/getdnsapi/stubby.git

Build and install (NOTE: from release 0.3.0 stubby uses cmake)

cd stubby
cmake .
make

If you get an error Could NOT find Getdns (missing: GETDNS_LIBRARIES GETDNS_INCLUDE_DIR) then you need to set the following 2 variable as arguements to cmake:

cmake -DGETDNS_LIBRARY=<path to libgetdns> -DGETDNS_INCLUDE_DIR=<path to getdns.h header file> .

A quick start guide to using cmake with getdns is here.

Configure Stubby

It is recommended to use the default configuration file provided which will use 'Strict' privacy mode and spread the DNS queries among several of the current DNS Privacy test servers. Note that this file contains both IPv4 and IPv6 addresses. This file is installed on *nix systems as /usr/local/etc/stubby/stubby.yml

The configuration file format is a YAML like format and the name of the file must have an extension of .yml. Essentially the configuration options available are the same as the options that can be set on a getdns context - Doxygen documentation for which is available here. To aid with creating a custom configuration file, an example is given below.

NOTE: As of the 0.1.3 release of Stubby the YAML format replaces the JSON like format used in earlier versions of the configuration file for getdns/stubby. The YAML format is more human readable and supports comments allowing options to be easily enabled and disabled. The JSON format is that which is used internally in getdns (it is the same as the output returned by stubby -i) and is still available by directly specifying a file with the name 'stubby.conf' on the command line using the -C option.

Create Custom Configuration File

Alternatively the configuration file location can be specified on the command line using the -C flag. Changes to the configuration file require a restart of Stubby.

The config file below will configure Stubby in the following ways:

• resolution_type: Work in stub mode only (not recursive mode) - required for Stubby operation.
• dns_transport_list: Use TLS only as a transport (no fallback to UDP or TCP).
• tls_authentication: Use Strict Privacy i.e. require a TLS connection and authentication of the upstream
• If Opportunistic mode is desired, simply remove the tls_authentication: GETDNS_AUTHENTICATION_REQUIRED field. In Opportunistic mode authentication of the nameserver is not required and fallback to clear text transports is permitted if they are in the dns_transport_list.
• tls_query_padding_blocksize: Use the EDNS0 padding option to pad DNS queries to hide their size
• edns_client_subnet_private: Use EDNS0 Client Subnet privacy so the client subnet is not sent to authoritative servers
• idle_timeout: Use an EDNS0 Keepalive idle timeout of 10s unless overridden by the server. This keeps idle TLS connections open to avoid the overhead of opening a new connection for every query.
• listen_address: have the Stubby daemon listen on IPv4 and IPv6 on port 53 on the loopback address
• round_robin_upstreams: Round robin queries across all the configured upstream servers. Without this option Stubby will use each upstream server sequentially until it becomes unavailable and then move on to use the next.
• upstream_recursive_servers: Use the NLnet labs test DNS Privacy Server for outgoing queries. In Strict Privacy mode, at least one of the following is required for each nameserver:
• tls_auth_name: This is the authentication domain name that will be verified against the presented certificate.
• tls_pubkey_pinset: The sha256 SPKI pinset for the server. This is also verified against the presented certificate.

resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list: 
  - GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 256
edns_client_subnet_private : 1
idle_timeout: 10000
listen_addresses:
  - 127.0.0.1
  -  0::1
round_robin_upstreams: 1
upstream_recursive_servers:
  - address_data: 185.49.141.38
    tls_auth_name: "getdnsapi.net"
    tls_pubkey_pinset:
      digest: "sha256"
       value: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=

Additional privacy servers can be specified by adding more entries to the upstream_recursive_servers list above (note a separate entry must be made for the IPv4 and IPv6 addresses of a given server. More DNS Privacy test servers are listed here.

A custom port can be specified by adding the tls_port: attribute to the upstream_recursive_server in the config file.

More details can be found in the comments in the default configuration file and at https://dnsprivacy.org/wiki/display/DP/Configuring+Stubby

Run Stubby

Simply invoke Stubby on the command line. By default it runs in the foreground, the -g flag runs it in the background.

> sudo stubby

Or, to let it run as an unprivileged user:

> sudo setcap 'cap_net_bind_service=+ep' /usr/local/bin/stubby
> stubby

• Enable connection logging by using the -l flag. The logging is currently simplistic and simply writes to stdout. (We are working on making this better!)
• A custom configuration file can be specified using the -C flag.
• The pid file is /usr/local/var/run/stubby.pid

Platform specific management

The Windows and macOS installers include scripts to run stubby as a managed daemon. We have basic support for using systemd to manage Stubby, see systemd

Test Stubby

A quick test can be done by using dig (or your favourite DNS tool) on the loopback address

> dig @127.0.0.1 www.example.com

> getdns_query -s @127.0.0.1 www.example.com

Modify your upstream resolvers

!!! Once this change is made your DNS queries will be re-directed to Stubby and sent over TLS!
(You may need to restart some applications to have them pick up the network settings).

You can monitor the traffic using Wireshark watching on port 853.

For Stubby to re-send outgoing DNS queries over TLS the system stub resolvers on your machine must be changed to send all the local queries to the loopback interface on which Stubby is listening. This depends on the operating system being run. It is useful to note your existing default nameservers before making this change!

Linux/Unix systems

• Edit the /etc/resolv.conf file
• Comment out the existing nameserver entries
• Add the following (only add the IPv4 address if you don't have IPv6)

  nameserver 127.0.0.1
  nameserver ::1

OS X

A script is provided with Stubby for easier configuration. From the command line you can do the following to switch all your queries to use Stubby

> sudo /usr/local/sbin/stubby-setdns-macos.sh

If you want to reset, just use:

> sudo /usr/local/sbin/stubby-setdns-macos.sh -r

which should pick up the default DHCP nameservers.

You can add /usr/local/sbin to your path to avoid having to type it above by doing

export PATH=/usr/local/sbin:$PATH

Or via the macOs System Settings GUI:

• Open System Preferences → Network → Advanced → DNS
• Use the '-' button to remove the existing nameservers
• Use the '+' button to add 127.0.0.1 and ::1 (only add the IPv4 address if you don't have IPv6)
• Hit 'OK' in the DNS pane and then 'Apply' on the Network pane

Windows 8 and later

See the file windows/README.txt for a detailed description of building and using Stubby on windows.

Powershell scripts are provided in the the windows directory of the source code that can be used to update the system resolvers. Instructions for how to update the resolvers manually are provided are also provided - see https://dnsprivacy.org/wiki/display/DP/Windows+installer+for+Stubby Stubby has been reported to work on Windows 7, but we don't officially support it.

Notes:

• If Stubby works for a while but you then see failures from Stubby such as "None of the configured upstreams could be used to send queries on the specified transports" try restarting Stubby.
• If you are using a DNS Privacy server that does not support concurrent processing of TLS queries, you may experience some issues due to timeouts causing subsequent queries on the same connection to fail.

Building getdns from source

Note that from getdns 1.1.3 stubby is included in the getdns code as a git submodule. Therefore stubby and getdns can be built together by following the instructions in the getdns README and setting the BUILD_STUBBY option.

Logging/debugging when building from source

--enable-debug-stub If you do want to see very detailed debug information as messages are processed then add the --enable-debug-stub option to the configure line above (not recommended for use with Stubby)

Contributions

The contrib directory contains code kindly contributed by various people:

vapniks Tom Matthews CameronNemo

stubby's Issues

No stubby PID file created

$ cat stubby.pid
cat: stubby.pid: No such file or directory

It doesn't help when configuring: --with-piddir=/usr/local/var/run
There is no file creation.

Now only manual creation possible with:
stubby & pidof stubby > /tmp/stubby.pid and cut/copy to /usr/local/var/run

Stubby yaml processing doesn't support IPv6 addresses that end in ::

Experience dropouts from time to time on macOS High Sierra

Hi,

I'm using Stubby on High Sierra, and at least once a day I experience that I'm unable to resolve DNS. When pinging 8.8.8.8 I get a connection. Have yet to change to a different DNS to eliminate stubby, but I did not have this issue with DNSCrypt – nor regular DNS.

I run with default config (strict mode I believe), and I use the Homebrew package.

Any thoughts?

Create an rc.d script to run stubby as a daemon

The documentation says to run stubby as sudo stubby, however this is an inconvenient way to run a system process that should always be left running, and that should come up with the system. I see that support is being or has been added to run it using systemd. As a user of FreeBSD I would also like to see a script for use with the rc system.

Create aliases for Strict/Opportunistic usage profiles in the getdns options

getdnsapi/getdns#366 made me wonder whether we could be able to select ciphers and curves used by stubby.

As soon as possible (i.e. when upstream resolvers support that), I would like to restrain it to:

• TLS 1.3, but at least TLS 1.2;
• The exact cipher list proposed by the above mentioned PR;
• x25519 and x448 as only available curves.

Yaml is really anti-human. A space can cause an accident!

Yaml is really anti-human. A space can cause an accident!

https://www.zionandzion.com/json-vs-xml-vs-toml-vs-cson-vs-yaml/

Why not use json ?

Stubby crashes every 1-2 days

System: RaspberryPi 3
OS: raspbian lite stretch
picked from: buster repo
Stubby: 1.3.0

Every 1-2 Days Stubby doesn't work anymore

systemclt status stubby
shows aktive and no Problems

after an
systemctl restart stubby

it runs for another 1-2 days, sometimes only for an hour....

censurfridns.dk server errors

When running stubby with debug logging, I'm seeing:

[09:58:36.855948] STUBBY: 184.105.193.78                           : Conn opened: TLS - Strict Profile
[09:58:37.135059] STUBBY: 184.105.193.78                           : Conn closed   : Transport=TLS - *Failure*
[09:58:37.135227] STUBBY: 184.105.193.78                           : Conn closed: TLS - Resps=     0, Timeouts  =     0, Curr_auth =   None, Keepalive(ms)=     0
[09:58:37.135238] STUBBY: 184.105.193.78                           : Upstream   : TLS - Resps=     0, Timeouts  =     0, Best_auth =   None
[09:58:37.135247] STUBBY: 184.105.193.78                           : Upstream   : TLS - Conns=     0, Conn_fails=     1, Conn_shuts=      0, Backoffs     =     0
[09:58:37.135313] STUBBY: 184.105.193.78                           : Conn closed: TLS - Resps=     0, Timeouts  =     0, Curr_auth =   None, Keepalive(ms)=     0
[09:58:37.135327] STUBBY: 184.105.193.78                           : Upstream   : TLS - Resps=     0, Timeouts  =     0, Best_auth =   None
[09:58:37.135333] STUBBY: 184.105.193.78                           : Upstream   : TLS - Conns=     0, Conn_fails=     1, Conn_shuts=      0, Backoffs     =

I see the same with the IPv6 address of the server.

Example config doesn't show how to use alternative port

The example stubby config shows how to list addresses to listen on, and says that the default port is 53, but doesn't explicitly show how to specify an alternative port using the address@port syntax. I eventually figured it out, but it would be nice if this were made clear in the example, because it's not obvious.

Run stubby as unprivileged user

Hi,

AFAICS, stubby can only run as root. I'd great if it could bind to the 53 port as an unprivileged user.

Thanks for your great work,

Santiago

Consider more compact format for upstream config

We could consider supporting in yaml a format that allows upstreams to be specified in a more compact fashion for increased usability.
In particular, at the moment each IP address and port combination requires a separate entry which (typically) repeats exactly the same authentication information. So for a server that listens on IPv4 and IPv6 and port 853 and port 443 on both addresses, 4 entries are needed!

From a pure user point of view something like the following would be preferred:

- upstream_data:
  addresses: ["145.100.185.15", "2001:610:1:40ba:145:100:185:15"]
  tls_ports:  [853, 443]
  tls_auth_name: "dnsovertls.sinodun.com"
  tls_pubkey_pinset:  [62lKu9HsDVbyiPenApnc4sfmSYTHOVfFgL3pyB+cBL4=]

Problems with DNSSEC on Windows

Reported on the dnsprivacy website:

i have changed the configuration, after restart -> 'server not found' error in different browsers

C:\Users\test>"C:\Program Files\Stubby\stubby.exe" -C "C:\Program Files\Stubby\stubby.yml" -l
[17:29:46.161428] STUBBY: Read config from file C:\Program Files\Stubby\stubby.yml
[17:29:46.164428] STUBBY: Starting DAEMON....
[17:29:48.552564] STUBBY: 145.100.185.15 : Conn opened: TLS - Strict Profile
[17:29:48.554565] STUBBY: 145.100.185.16 : Conn opened: TLS - Strict Profile
[17:29:48.554565] STUBBY: 185.49.141.37 : Conn opened: TLS - Strict Profile
[17:29:48.726574] STUBBY: 89.233.43.71 : Conn opened: TLS - Strict Profile
[17:29:48.727574] STUBBY: 2001:610:1:40ba:145:100:185:15 : Conn opened: TLS - Strict Profile
[17:29:48.728574] STUBBY: 2001:610:1:40ba:145:100:185:16 : Conn opened: TLS - Strict Profile
[17:29:48.728574] STUBBY: 2a04:b900:0:100::38 : Conn opened: TLS - Strict Profile
[17:29:48.847581] STUBBY: 2a01:3a0:53:53:: : Conn opened: TLS - Strict Profile
[17:31:54.473767] STUBBY: 2a01:3a0:53:53:: : Conn closed: TLS - Resps= 222, Timeouts = 0, Curr_auth =Success, Keepalive(ms)= 10000
[17:31:54.473767] STUBBY: 2a01:3a0:53:53:: : Upstream : TLS - Resps= 222, Timeouts = 0, Best_auth =Success
[17:31:54.474767] STUBBY: 2a01:3a0:53:53:: : Upstream : TLS - Conns= 1, Conn_fails= 0, Conn_shuts= 0, Backoffs = 0
[17:31:56.460880] STUBBY: 89.233.43.71 : Conn closed: TLS - Resps= 223, Timeouts = 0, Curr_auth =Success, Keepalive(ms)= 10000
[17:31:56.460880] STUBBY: 89.233.43.71 : Upstream : TLS - Resps= 223, Timeouts = 0, Best_auth =Success
[17:31:56.461880] STUBBY: 89.233.43.71 : Upstream : TLS - Conns= 1, Conn_fails= 0, Conn_shuts= 0, Backoffs = 0
[17:31:59.432050] STUBBY: 145.100.185.15 : Conn closed: TLS - Resps= 223, Timeouts = 0, Curr_auth =Success, Keepalive(ms)= 10000
[17:31:59.432050] STUBBY: 145.100.185.15 : Upstream : TLS - Resps= 223, Timeouts = 0, Best_auth =Success
[17:31:59.433050] STUBBY: 145.100.185.15 : Upstream : TLS - Conns= 1, Conn_fails= 0, Conn_shuts= 0, Backoffs = 0
[17:31:59.433050] STUBBY: 145.100.185.16 : Conn closed: TLS - Resps= 223, Timeouts = 0, Curr_auth =Success, Keepalive(ms)= 10000
[17:31:59.434050] STUBBY: 145.100.185.16 : Upstream : TLS - Resps= 223, Timeouts = 0, Best_auth =Success
[17:31:59.434050] STUBBY: 145.100.185.16 : Upstream : TLS - Conns= 1, Conn_fails= 0, Conn_shuts= 0, Backoffs = 0
[17:31:59.435050] STUBBY: 185.49.141.37 : Conn closed: TLS - Resps= 223, Timeouts = 0, Curr_auth =Success, Keepalive(ms)= 10000
[17:31:59.435050] STUBBY: 185.49.141.37 : Upstream : TLS - Resps= 223, Timeouts = 0, Best_auth =Success
[17:31:59.435050] STUBBY: 185.49.141.37 : Upstream : TLS - Conns= 1, Conn_fails= 0, Conn_shuts= 0, Backoffs = 0

IPv6 address incorrect?

I ran the powershell script to set up the DNS, but noticed that IPv6 didn't work for me.

Maybe the address should be changed to ::1? That did work for me, at least.

stubby/windows/stubby_setdns_windows.ps1

Line 4 in 03c0947

set-dnsclientserveraddress $ifname -ServerAddresses ("127.0.0.1","0::1")

error: Could not bind on given addresses: No error

Greetings,

I Installed this programm with the msi installer and executed it like shown below

C:\Windows\System32>"C:\Program Files\Stubby\stubby.exe" -C "C:\Program Files\Stubby\stubby.yml" -l
[08:03:38.669718] STUBBY: Read config from file C:\Program Files\Stubby\stubby.yml
error: Could not bind on given addresses: No error

glad to see that the error was no error ;D

Question: How will Quad9 affect stubby?

I wonder how Quad9 will affect stubby?
i.e will there be a collaboration with Quad9 or sharing of DNS servers?
...

systemd: d /run/stubby 0750 root stubby - - makes no sense

tmpfiles say:

d /run/stubby 0750 root stubby - -

What is the point of /run/stubby in mode 0750 owner root, if stubby is started as user stubby?
It won't be able to write anything in the directory. If there is anything to read there, who places it in that directory (as root even, so not stubby itself)

Why is this directory needed at all?

add stubby to chocolatey.org package manager

Hi,
would you mind adding stubby to the chocolatey.org? It would make it much easier to keep stubby updated on windows. Chocolatey is a package manager for Windows (like apt-get or yum but for Windows). see: https://chocolatey.org/about
Thanks :)

add a man page for stubby

Simplify request handling

Request handling can be dramatically simplified because of the "new" feature with which DNS messages can be passed in and constructed from extensions. So no need to construct them from the ground up ourselves, we can simply pass the original request as an extension dict when doing our own request at the upstream. The unit tests that involve serving already use this mechanism, I can copy from there.

stubby dies when connectivity is lost

My logs are often spammed with:

stubby: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports

This is generally the case after going out of suspend, before the connectivity is regained.

But when connectivity is completely lost (i.e. when roaming from work to home), stubby apparently even segfaults:

systemd[1]: ^[[0;1;39mstubby.service: Main process exited, code=dumped, status=11/SEGV
systemd[1]: ^[[0;1;39mstubby.service: Failed with result 'core-dump'.

DEBUG_SERVER build broken

clang -DHAVE_CONFIG_H -I. -I..  -DSTUBBYCONFDIR=\"/usr/local/etc/stubby\" -DRUNSTATEDIR=\"/usr/local/Cellar/stubby/HEAD-70832ec/var/run\"   -DSERVER_DEBUG=1 -c -o sldns/sbuffer.o sldns/sbuffer.c
stubby.c:375:32: error: expected ')'
        DEBUG_SERVER("reply for: %p %"PRIu64" %d (edns0: %d, do: %d, ad: %d,"
                                      ^
stubby.c:375:2: note: to match this '('
        DEBUG_SERVER("reply for: %p %"PRIu64" %d (edns0: %d, do: %d, ad: %d,"
        ^
stubby.c:98:27: note: expanded from macro 'DEBUG_SERVER'
#define DEBUG_SERVER(...) DEBUG_ON(__VA_ARGS__)
                          ^
stubby.c:91:25: note: expanded from macro 'DEBUG_ON'
                        fprintf(stderr, __VA_ARGS__); \
                               ^
stubby.c:565:33: error: expected ')'
                DEBUG_SERVER("scheduled: %p %"PRIu64" for %s %d\n",
                                              ^
stubby.c:565:3: note: to match this '('
                DEBUG_SERVER("scheduled: %p %"PRIu64" for %s %d\n",
                ^
stubby.c:98:27: note: expanded from macro 'DEBUG_SERVER'
#define DEBUG_SERVER(...) DEBUG_ON(__VA_ARGS__)
                          ^
stubby.c:91:25: note: expanded from macro 'DEBUG_ON'
                        fprintf(stderr, __VA_ARGS__); \
                               ^
2 errors generated.
make[1]: *** [stubby.o] Error 1

Straightforward build patching -DSERVER_DEBUG=1 into the Homebrew formula on macOS.

missing config, for local nameservers

Hi, I miss a option, to forward requests to specified domains to a local nameserver.
eg. *.fritz.box or speedport.ip to my router or mydom.local to my local domain name server and also 0.0.168.192.in-addr.arpa and so on...

Try to check the context for inconsistencies when stubby first starts.

Since stubby will always use the same context when running it would be nice to check the result of
_getdns_context_prepare_for_resolution() early and error if it fails in order to detect problems asap.

-h shows wrong prefix for file locations on Windows

configure: error: cannot find install-sh

Documentation on the main page should include

libtoolize -ci

otherwise the following error will result on configure:

configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."

Regards

Litttlesnitch & Stubby

Hi,

Firstly, thank you very much for building Stubby (+getdns), I am a very happy user of this software.

It seems logical to me that people who use Stubby are fairly likely to also run the popular Littlesnitch firewall app. At the moment this can be quite tricky. For example, I recently experienced very strange Stubby behaviour until I realised that Littlesnitch was blocking the download of the root anchor from data.iana.org. AFAICT, there was no specific error messages from Stubby about this and it took me a while to diagnose the issue. Secondly, Littlesnitch doesn't work well with unsigned code. I guess many people do automatic Homebrew updates but that requires reauthorising everything within Littlesnitch due to the unsigned code. If you are managing Macs via SSH this is quite painful since it's not possible (AFAIK) to update Littlesnitch rules other than via the GUI.

I realise that Stubby is only recommended for technical users at the moment but if there's anything you can do to make it a little more Littlesnitch friendly, that would be very helpful.

Thanks !

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

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:

upstream_recursive_servers:
  - address_data: 1.1.1.1
    tls_pubkey_pinset:
      - digest: "sha256"
        value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=

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!

Also see #46

Powershell scripts work only on Windows 8+

As explained here.

Get-NetAdapter : Die Benennung "Get-NetAdapter" wurde nicht als Name eines Cmdlet, einer Funktion, einer Skriptdatei oder eines ausführbaren Programms erkannt. Überprüfen Sie die Schreibweise des
Namens, oder ob der Pfad korrekt ist (sofern enthalten), und wiederholen Sie den Vorgang.
In C:\Program Files\Stubby\stubby_setdns_windows.ps1:1 Zeichen:1
+ Get-NetAdapter -Physical | ForEach-Object {
+ ~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (Get-NetAdapter:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Error in `/usr/bin/stubby': double free or corruption

Observed this in my journal when I woke up this morning.

Dec 26 01:22:01 debian stubby[29787]: [14:22:01.795784] STUBBY: Read config from file /etc/stubby/stubby.yml
Dec 26 01:22:01 debian stubby[29787]: [14:22:01.796863] STUBBY: Starting DAEMON....
Dec 26 05:53:43 debian stubby[29787]: *** Error in `/usr/bin/stubby': double free or corruption (!prev): 0x0000000000aca290 ***

I know this isn't much to go off of, I obviously had to restart the systemd service, what can I do to help debug this? I compiled with Stubby - v0.2.1 from the releases page.

Feature Request: DNS Blacklist

WIth DNSCrypt it looked like this:

https://web.archive.org/web/20180108142429/https://webcache.googleusercontent.com/search?q=cache:https://github.com/jedisct1/dnscrypt-proxy/wiki/Blacklists

Is this possible with Stubby?

add support for pure randomization of DNS upstream server

Dear stubby team,

I want my DNS requests to be spread over different servers. For this, option round_robin_upstreams is a first step. However, it is weak if the attacker gets to make fake DNS requests so that all the interesting requests to be spied are sent to the same server.

For overcoming this problem, what about adding an option for pure randomization when selecting the server:

# Instructs stubby to randomly distribute queries across all available name servers. 
randomize_upstreams: 1

High data traffic bandwidth even without queries(win)?

i don't use stubby as upstream for unbound anymore, but high data traffic bandwidth even without queries?

no valid transports or upstreams available

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

Option to restore last configured set of DNS resolvers

When the macOS/windows scripts set the system resolvers to use local host to enable stubby they should store the current DNS configuration somewhere.

Then when disabling stubby by reverting the system resolvers there should be an option to restore the configuration from this saved information (in addition to the default of using DHCP provided servers).

This supports the workflow where a user wants to use a fixed set of servers (e.g. 8.8.8.8) if they can't use stubby.

Question: can we use locations on macOS to manage the DNS more gracefully?

Extend wiki info about manual configuration on Windows

Windows - Cannot change nameservers

Windows 7 Ultimate: Service Pack 1
Stubby version: from day 3rd April 2018(newest right now)

After successful start and test of Stubby I opened another Administrator: Command Line and typed this:

C:\Users\User>PowerShell -ExecutionPolicy bypass -file "C:\Program Files\Stubby\stubby_setdns_windows7.ps1"

aaaand this is shown:

Cannot process the "#requires" statement at line 1 because it is not in the correct format.
The "#requires" statement must be in one of the following formats:
"#requires -shellid "
"#requires -version <major.minor>"
"#requires -pssnapin [-version <major.minor>]"
+ CategoryInfo : ObjectNotFound: (:String) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : CommandNotFoundException

halp plz

stubby.pid is not created as expected

Something in the configure phase seems broken. I just tried the getdns git with stubby as a submodule and when starting stubby with the -g flag I get the output
Could not write pid to "@runstatedir@/stubby.pid": No such file or directory
which seems as if some replacement failed.
When I use the stubby git repository on its own, the stubby.pid file is create at / instead of /var/run/ which also seems to be a replacement problem. Unfortunately I don't know enough about autotools to fix this.

its very beautiful software!!!!

its software is very very beautiful ....
tanks for your!!!!

Create a scheduled task for stubby on Windows

While it would be nice to have stubby run as a service it requires some development work. As a short term work around we should create a scheduled task for Stubby.

This can be done the following way (thanks to anonymous comment on dnsprivacy.org)

Create a stubby.bat with e.g.:
"C:\Program Files\Stubby\stubby.exe" -C "C:\Program Files\Stubby\stubby.yml" -l

Create a stubby.vbs to hide the cmd window with:

Set WinScriptHost = CreateObject("WScript.Shell")
WinScriptHost.Run Chr(34) & "C:\Program Files\Stubby\stubby.bat" & Chr(34), 0
Set WinScriptHost = Nothing```

Create a scheduled task and use the stubby.vbs script, run at boot. ready.
Now you should have stubby running at boot.

Stubby shouldn't try to use IPv6 entries when it isn't bound to an IPv6 address

Even though I only have stubby bound to an IPv4 address (127.0.0.1) log output shows that it will try to use IPv6 resolvers that are defined in stubby.conf. Stubby should be made to only use IPv6 entries when it's bound to an IPv6 address and similar for IPv4.

stubby.yml should be installed under $(DESTDIR)

In

stubby/Makefile.am

Line 18 in 0cbd46e

${INSTALL_DATA} $(CONFIG_FILE) ${stubbyconfdir}/stubby.yml

, the config file is installed in ${stubbyconfdir}, but this folder might not exist:

test -f /etc/stubby/stubby.yml || \
	/usr/bin/install -c -m 644 ./stubby.yml.example /etc/stubby/stubby.yml
/usr/bin/install: cannot create regular file '/etc/stubby/stubby.yml': No such file or directory

That’s because the folder was created under $(DESTDIR), which is not used here.

SERVFAIL when CD set

$ dig @127.0.0.1 -p5342 filippo.io

; <<>> DiG 9.11.2 <<>> @127.0.0.1 -p5342 filippo.io
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8756
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: f57cae418af1e3c353d164c85a2027b18645e5d70e9a2187 (good)
; CLIENT-SUBNET: 0/0/0
;; QUESTION SECTION:
;filippo.io.			IN	A

;; ANSWER SECTION:
filippo.io.		300	IN	A	104.20.145.15
filippo.io.		300	IN	A	104.20.144.15

;; AUTHORITY SECTION:
filippo.io.		83174	IN	NS	jim.ns.cloudflare.com.
filippo.io.		83174	IN	NS	beth.ns.cloudflare.com.

;; ADDITIONAL SECTION:
jim.ns.cloudflare.com.	23151	IN	A	173.245.59.125
beth.ns.cloudflare.com.	40084	IN	A	173.245.58.103
jim.ns.cloudflare.com.	23151	IN	AAAA	2400:cb00:2049:1::adf5:3b7d
beth.ns.cloudflare.com.	40084	IN	AAAA	2400:cb00:2049:1::adf5:3a67

;; Query time: 105 msec
;; SERVER: 127.0.0.1#5342(127.0.0.1)
;; WHEN: Thu Nov 30 15:45:57 GMT 2017
;; MSG SIZE  rcvd: 392

$ dig @127.0.0.1 -p5342 filippo.io +cd

; <<>> DiG 9.11.2 <<>> @127.0.0.1 -p5342 filippo.io +cd
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9973
;; flags: qr rd cd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;filippo.io.			IN	A

;; Query time: 3002 msec
;; SERVER: 127.0.0.1#5342(127.0.0.1)
;; WHEN: Thu Nov 30 15:46:02 GMT 2017
;; MSG SIZE  rcvd: 28

My config:

resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 256
edns_client_subnet_private : 1
idle_timeout: 60000
listen_addresses:
  - 127.0.0.1@5342
round_robin_upstreams: 0
tls_backoff_time: 300
timeout: 3000
upstream_recursive_servers:
  - address_data: 145.100.185.15
    tls_auth_name: "dnsovertls.sinodun.com"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 62lKu9HsDVbyiPenApnc4sfmSYTHOVfFgL3pyB+cBL4=
  - address_data: 145.100.185.16
    tls_auth_name: "dnsovertls1.sinodun.com"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: cE2ecALeE5B+urJhDrJlVFmf38cJLAvqekONvjvpqUA=
  - address_data: 185.49.141.37
    tls_auth_name: "getdnsapi.net"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=
  - address_data: 89.233.43.71
    tls_auth_name: "unicast.censurfridns.dk"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: wikE3jYAA6jQmXYTr/rbHeEPmC78dQwZbQp6WdrseEs=
  - address_data: 51.15.70.167
    tls_auth_name: "dns1.darkmoon.is"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 8sx8niFUiJvMM3C1qLE9cH79TuQQztzMVDtbKjpD/IQ=
  - address_data: 146.185.167.43
    tls_auth_name: "securedns.eu"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 2EfbwDyk2zSnAbBJSpCSWZKKGUD+a6p/yg2bxdC+x2A=
  - address_data: 81.187.221.24
    tls_auth_name: "dns-tls.bitwiseshift.net"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: YmcYWZU5dd2EoblZHNf1jTUPVS+uK3280YYCdz4l4wo=
  - address_data: 194.130.110.185
    tls_auth_name: "ns1.dnsprivacy.at"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: vqVQ9TcoR9RDY3TpO0MTXw1YQLjF44zdN3/4PkLwtEY=
  - address_data: 94.130.110.178
    tls_auth_name: "ns2.dnsprivacy.at"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: s5Em89o0kigwfBF1gcXWd8zlATSWVXsJ6ecZfmBDTKg=

Curiously, Stubby sends a SERVFAIL precisely after the timeout has elapsed, but no timeout is logged.

[15:45:36.881302] STUBBY: Read config from file /usr/local/etc/stubby/stubby.yml
[15:45:36.883408] STUBBY: Starting DAEMON....
[15:45:39.027004] STUBBY: 145.100.185.15                           : Conn opened: TLS - Strict Profile
[15:46:29.712322] STUBBY: 145.100.185.15                           : Conn closed: TLS - Resps=     7, Timeouts  =     0, Curr_auth =Success, Keepalive(ms)= 60000
[15:46:29.712369] STUBBY: 145.100.185.15                           : Upstream   : TLS - Resps=     7, Timeouts  =     0, Best_auth =Success
[15:46:29.712379] STUBBY: 145.100.185.15                           : Upstream   : TLS - Conns=     1, Conn_fails=     0, Conn_shuts=      1, Backoffs     =     0

This is stopping me from using unbound behind stubby for caching and validation.

Installing stubby on Fedora 26 / Time out ?

Hi,

Using sys-net (Qubes 4) based on fedora-26 template, I am not able to install it:

fatal: clone of 'git://g.blicky.net/yxml.git into submodule path ':home/user/src/getdns/src/yxml failed
Failed to clone 'src/yxml'.
fatal: unable to connect to g.blicky.net: .... time out

If using nslookup I am able to resolv this address.

Thx

Wiki - instructions for saving current DNS config

Instructions for Windows on https://dnsprivacy.org/wiki/display/DP/Windows+installer+for+Stubby
say in section: Modify your upstream resolvers
'It might be useful to note your existing default nameservers before making this change!'
and
'If you encounter problems reverse this change to restore your default settings (no DNS Privacy). '
as the installation is done via PowerShell script "C:\Program Files\Stubby\stubby_setdns_windows.ps1" and reset is "C:\Program Files\Stubby\stubby_resetdns_windows.ps1" its not 100% clear from the current wording if the DNS setting get saved by installation and then restored by the reset script.

Looking at the scripts there is currently no backup & restore of DNS setting implemented, but it should be fairly easy to add. Then using backup & restore terms could help people to understand the involved risk better :)

PS: Is it technically feasible to change the 'Wiki' link in github to point to above mentioned wiki?

GETDNS_AUTHENTICATION_REQUIRED not authenticating?

I compiled stubby per the documentation, and when running it, it works, but I was trying to make sure it was actually authenticating servers, and it doesn't seem to, my example config is at the bottom.

This only has 1 IP with no way to authenticate and queries succeed.

I also tried having this as my only server:

  - address_data: 185.49.141.37
    tls_auth_name: "getdnsapi.net"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=

And when I change the name and digest to something invalid, like:

  - address_data: 185.49.141.37
    tls_auth_name: "getdnsapi-invalid.net"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: fonZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=

DNS resolution still works. This seems like a major security issue, am I doing something wrong?

#
# This is a yaml version of the stubby configuration file (it replaces the 
# json based stubby.conf file used in earlier versions of getdns/stubby).
#
# For more information see
# https://dnsprivacy.org/wiki/display/DP/Configuring+Stubby
#
# This format does not fully support all yaml features - the restrictions are:
#     - the outer-most data structure must be a yaml mapping
#     - mapping keys must be yaml scalars
#     - plain scalars will be converted to json unchanged
#     - non-plain scalars (quoted, double-quoted, wrapped) will be interpreted 
#       as json strings, i.e. double quoted
#     - yaml tags are not supported
#

# Logging is currently configured at runtime using command line arguments. See 
# > stubby -h
# for details.

# Specifies whether to run as a recursive or stub resolver 
# For stubby this MUST be set to GETDNS_RESOLUTION_STUB
resolution_type: GETDNS_RESOLUTION_STUB

# Ordered list composed of one or more transport protocols: 
# GETDNS_TRANSPORT_UDP, GETDNS_TRANSPORT_TCP or GETDNS_TRANSPORT_TLS
# If only one transport value is specified it will be the only transport used. 
# Should it not be available basic resolution will fail.
# Fallback transport options are specified by including multiple values in the list.
# Strict mode (see below) should use only GETDNS_TRANSPORT_TLS.
dns_transport_list:
  - GETDNS_TRANSPORT_TLS

# Selects Strict or Opportunistic Usage profile as described in
# https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/
# Strict mode requires that authentication information for the upstreams is
# specified below. Opportunistic may fallback to clear text DNS if UDP or TCP is
# included in the transport list above.
# For Strict use        GETDNS_AUTHENTICATION_REQUIRED
# For Opportunistic use GETDNS_AUTHENTICATION_NONE
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED

# EDNS0 option to pad the size of the DNS query to the given blocksize
# 256 is currently recommended by 
# https://tools.ietf.org/html/draft-ietf-dprive-padding-policy-01
tls_query_padding_blocksize: 256

# EDNS0 option for ECS client privacy as described in Section 7.1.2 of
# https://tools.ietf.org/html/rfc7871
edns_client_subnet_private : 1

# EDNS0 option for keepalive idle timeout in ms as specified in
# https://tools.ietf.org/html/rfc7828
# This keeps idle TLS connections open to avoid the overhead of opening a new 
# connection for every query.
idle_timeout: 10000

# Set the listen addresses for the stubby DAEMON. This specifies localhost IPv4
# and IPv6. It will listen on port 53 by default.
listen_addresses:
  - 127.0.0.1:8853
#  -  0::1

# Instructs stubby to distribute queries across all available name servers. 
# Set to 0 to treat the upstreams below as an ordered list and use a single upstream
# until it becomes unavailable, then use the next one.
round_robin_upstreams: 1

# Specify the list of upstream recursive name servers to send queries to
# In Strict mode upstreams need either a tls_auth_name or a tls_pubkey_pinset
# so the upstream can be authenticated.
# The list below includes some of the available test servers. If you don't have
# IPv6 then comment out the 
# In Opportunistic mode they only require an IP address in address_data.
# The information for an upstream can include the following:
#   address_data: IPv4 or IPv6 address of the upstream
#   port: Port for UDP/TCP (default is 53)
#   tls_auth_name: Authentication domain name checked against the server certificate
#   tls_pubkey_pinset: An SPKI pinset verified against the keys in the server certificate
#     digest: Only "sha256" is currently supported
#     value: Base64 encoded value of the sha256 fingerprint of the public key
#   tls_port: Port for TLS (default is 853)
upstream_recursive_servers:
# IPv4 addresses
# The uncensored DNS servers (no SPKI available)
  - address_data: 184.105.193.78
#    tls_auth_name: "unicast.censurfridns.dk"

# Require DNSSEC validation. For releases earlier than 1.2 a trust anchor must
# be configured configured manually. This can be done with unbound-anchor.
#dnssec_return_status: GETDNS_EXTENSION_TRUE

#Specify the location of the installed trust anchor file
#dnssec_trust_anchors: /etc/unbound/getdns-root.key

# Control the maximum number of connection failures that will be permitted before
# Stubby backs-off from using an individual upstream (default 2)
# tls_connection_retries: 5

# Control the maximum time in seconds Stubby will back-off from using an individual upstream
# after failures under normal circumstances (default 3600)
# tls_backoff_time: 300

# Limit the total number of outstanding queries permitted
# limit_outstanding_queries: 100

# Specify the timeout on getting a response to an individual request (default 5s)
# timeout: 1

typo in /Applications/StubbyManager.app/Contents/MacOS/stubby.yml

In the following config that's commented out, the IP addr should be 94.130.110.185.

# # ns1.dnsprivacy.at
# - address_data: 194.130.110.185
# tls_auth_name: "ns1.dnsprivacy.at"

no log when nslookup on windows

my config

>stubby -C stubby.yml -l -i
[16:53:58.834715] STUBBY: Read config from file stubby.yml
{
  "all_context":
  {
    "appdata_dir": <bindata of "C:\Users\CNMAN\AppData\Roaming\g"...>,
    "append_name": GETDNS_APPEND_NAME_TO_SINGLE_LABEL_FIRST,
    "dns_transport_list":
    [
      GETDNS_TRANSPORT_TLS
    ],
    "dnssec_allowed_skew": 0,
    "edns_client_subnet_private": 1,
    "edns_do_bit": 0,
    "edns_extended_rcode": 0,
    "edns_version": 0,
    "follow_redirects": GETDNS_REDIRECTS_FOLLOW,
    "idle_timeout": 10000,
    "limit_outstanding_queries": 0,
    "namespaces":
    [
      GETDNS_NAMESPACE_LOCALNAMES,
      GETDNS_NAMESPACE_DNS
    ],
    "resolution_type": GETDNS_RESOLUTION_STUB,
    "round_robin_upstreams": 1,
    "suffix": [],
    "timeout": 5000,
    "tls_authentication": GETDNS_AUTHENTICATION_REQUIRED,
    "tls_backoff_time": 3600,
    "tls_connection_retries": 2,
    "tls_query_padding_blocksize": 256,
    "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 9.9.9.9>,
        "address_type": <bindata of "IPv4">,
        "tls_auth_name": <bindata of "dns.quad9.net">
      },
      {
        "address_data": <bindata for 149.112.112.112>,
        "address_type": <bindata of "IPv4">,
        "tls_auth_name": <bindata of "dns.quad9.net">
      },
      {
        "address_data": <bindata for 2620:fe::fe>,
        "address_type": <bindata of "IPv6">,
        "tls_auth_name": <bindata of "dns.quad9.net">,
        "tls_pubkey_pinset":
        [
          {
            "digest": <bindata of "sha256">,
            "value": <bindata of MujBQ+U0p2eZLTnQ2KGEqs+fPLYV/1DnpZDjBDPwUqQ=>
          }
        ]
      }
    ]
  },
  "api_version_number": 132058112,
  "api_version_string": <bindata of "December 2015">,
  "compilation_comment": <bindata of "getdns 1.2.1rc1 configured on 20"...>,
  "implementation_string": <bindata of "https://getdnsapi.net">,
  "listen_addresses":
  [
    {
      "address_data": <bindata for 127.0.0.1>,
      "address_type": <bindata of "IPv4">,
      "port": 6666
    }
  ],
  "resolution_type": GETDNS_RESOLUTION_STUB,
  "trust_anchor_file": <bindata of "/mingw64/etc/unbound/getdns-root"...>,
  "version_number": 16908481,
  "version_string": <bindata of "1.2.1rc1">
}

>nslookup -port=6666 www.google.com 127.0.0.1
服务器:  localhost
Address:  127.0.0.1

非权威应答:
名称:    www.google.com
Address:  216.58.200.228

>dig -p 6666 www.google.com @127.0.0.1

; <<>> DiG 9.11.2 <<>> -p 6666 www.google.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53332
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.google.com.                        IN      A

;; ANSWER SECTION:
www.google.com.         185     IN      A       216.58.194.196

;; Query time: 1406 msec
;; SERVER: 127.0.0.1#6666(127.0.0.1)
;; WHEN: Tue Nov 21 00:50:46 ?D1ú±ê×?ê±?? 2017
;; MSG SIZE  rcvd: 73

but dig dose have log

>stubby -C stubby.yml -l
[16:43:56.137501] STUBBY: Read config from file stubby.yml
[16:43:56.139476] STUBBY: Starting DAEMON....
[16:50:44.860557] STUBBY: 149.112.112.112                          : Conn opened: TLS - Strict Profile
[16:50:47.266872] STUBBY: 149.112.112.112                          : Conn closed: TLS - Resps=     1, Timeouts  =     0, Curr_auth =Success, Keepalive(ms)= 10000
[16:50:47.266872] STUBBY: 149.112.112.112                          : Upstream   : TLS - Resps=     1, Timeouts  =     0, Best_auth =Success
[16:50:47.266872] STUBBY: 149.112.112.112                          : Upstream   : TLS - Conns=     1, Conn_fails=     0, Conn_shuts=      1, Backoffs     =     0

Correctly implement option processing

Only a subset of the options of getdns_query is relevant in stubby, so I didn't copy that over.
I'll try to implement the options relevant for stubby tonight (or else tomorrow morning), including the correctly processing of the -C option.... quoting:

I would like to change the config file handling in getdns_query so that it fails if either of the config files cannot be parsed. At the moment it runs but tends to fail which produces confusing logs. Especially if you give it a file with the -C option which is invalid, I don’t think the daemon should start.

Windows - cannot install Stubby

Windows 7 Ultimate: Service Pack 1
Stubby version: from day 3rd April 2018(newest right now)

What I did:

1. Downloaded windows installer from https://dnsprivacy.org/wiki/display/DP/Windows+installer+for+Stubby
2. Installed Stubby files in Program Files
3. Opening the .bat, .exes(getdns_query - flashes something once, stubby.bat - same thing as described below, stubby.exe - "no config file found...")
4. Starting install from administrator: command prompt

C:\Users\User>"C:\Program Files\Stubby\stubby.exe" -C "C:\Program Files\Stubby\stubby.yml" -1
[19:38:27.628784] STUBBY: Read config from file C:\Program Files\Stubby\stubby.yml
[19:38:27.633784] STUBBY: Starting DAEMON....

aaand that's it, after ~20 minutes still same thing is in administrator: command prompt

I don't know how long it installs but I have feeling it doesn't working as intended, halp.

Stubby 0.2.2 running well on macOS

Just wanted to say that we've been running the new Stubby version 0.2.2 since release on a handful of macOS systems (High Sierra 10.13.3) with no problems at all.

Upgrade via Homebrew was smooth.
We're using round_robin_upstreams: 1
4 IPv4 servers (quad9.net & sinodun) - getting very good performance
(no DNSSEC validation enabled)

the getdns_server_mon tool is very useful and much appreciated !

So a big thumbs up & thank you very much