GETDNS_AUTHENTICATION_REQUIRED not authenticating?

[moparisthebest]

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

[saradickinson]

Hi. Can please you try 2 things:

1. run the command you normally use to run stubby but add '-i' at the end. This will display the configuration actually being used by Stubby and then exit. Please send the output.
2. run the command you normally use to run stubby but add '-l' at the end. This will provide minimal logging from stubby to see what connection and server it is using upstream for queries. Run your test and post the logs you see.

Also your listen address uses port 8853 so will work for testing if you direct queries to 127.0.0.1:8853 but it won't work when running stubby as a daemon unless you can specify the port for your system resolvers. Are you doing that? What OS are you using?

[moparisthebest]

Hi,

Here is what you requested:

1. stubby -C /etc/stubby/stubby.yml -i > stubby.txt
2. -l seems to be 'Set transport list', I didn't see anything mentioning debug or log. Here is the log while running:

$ stubby -C /etc/stubby/stubby.yml 
[01:58:35.640968] STUBBY: 185.49.141.37                            : Conn opened: TLS - Strict Profile
[01:58:46.313606] STUBBY: 185.49.141.37                            : Conn closed: TLS - Resps=     1, Timeouts  =     0, Curr_auth = Failed, Keepalive(ms)= 10000
[01:58:46.313667] STUBBY: 185.49.141.37                            : Upstream   : TLS - Resps=     1, Timeouts  =     0, Best_auth = Failed
[01:58:46.313685] STUBBY: 185.49.141.37                            : Upstream   : TLS - Conns=     1, Conn_fails=     0, Conn_shuts=      0, Backoffs     =     0

The command I ran was:

$ dig @127.0.0.1 -p 8853 +dnssec debian.org

; <<>> DiG 9.11.1-P1 <<>> @127.0.0.1 -p 8853 +dnssec debian.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8666
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
debian.org.             300     IN      A       149.20.4.15
debian.org.             300     IN      A       128.31.0.62
debian.org.             300     IN      A       130.89.148.14
debian.org.             300     IN      A       5.153.231.4
debian.org.             300     IN      RRSIG   A 8 2 300 20171105125506 20170926115506 52539 debian.org. HL/bCe29zZq5qorpJ7orGODSfh5wd95R88qk16kMKIgAfjDhYGMpYa7F /6942KSo6BipLnnouG8blwpShTPnTb82lTFG4bRkLyyP6OcAqWcqDjkL IYarBA0RMDzievlik9elBZykbqpVlQqB3q/4Mq7oL7FOMABspqjT1B2U TEBDPABirVGqc+uRcrtOCnYlAOCSq5YOQYke9AFRu0SWD8mWr/JSsnUf xQJuwAN0NozbhR7c/YiTN0aWfgcawP9K

;; Query time: 709 msec
;; SERVER: 127.0.0.1#8853(127.0.0.1)
;; WHEN: Tue Sep 26 21:58:36 EDT 2017
;; MSG SIZE  rcvd: 387

I'm using arch linux, yes I'm pointing to the proper port.

[saradickinson]

OK - after some more digging by @wtoorop there is indeed a bug in the authentication code in the release candidate. A fix is being worked on.

[wtoorop]

Yes, I'm afraid I broke it by rearranging some initialisations.
We did have a unit test for authentication, but that test itself was broken too (didn't actually return an error exit status when things failed). The unit test was fixed with commit getdnsapi/getdns@a9ba50d and doing authentication on the first query was restored in commit getdnsapi/getdns@23daf9a

[wtoorop]

Thanks for trying out and reporting on the release candidate!