DNSSEC and traffic encryption questions

Beeblebrox · February 24, 2014, 11:37am

I'm using Unbound for recursive caching (serving internal network). I
would like to use DNSSEC and also encrypt the outbound traffic, but I
have doubts about foloowing:

* Unbound does not support encryption natively (from own code base)
AFAIK. I have come across two methods to encrypt DNS traffic: TOR and
DNSCrypt. Are there any other alternatives?
* Will DNSSEC be disabled when using any encryption method or if the
DNS query is forwarded to listening daemon (like TOR/DNSCrypt)?
* When forwarding to a locally listening daemon,
"do-not-query-localhost: no" must be enabled for forwarding to work.
Is this a security risk?
* Does one specify a forward-zone when using DNSSEC, or is it left up
to Unbound to decide (or maybe either method is acceptable)? I think
without forward-zone, Unbound just uses the list from root.hints?
* I have setup DNSSEC using the unbound-anchor command, and root.key
shows date as: Feb 1 15:12:15 2014. Tests show however, that server
is NOT using DNSSEC. Debug is set to verbosity: 4, and log shows no
errors. All files in /var/unbound are owned by unbound:unbound with
exception of unbound.conf.

Regards

Wouter · February 24, 2014, 12:24pm

Hi Beeblebrox,

I'm using Unbound for recursive caching (serving internal network).
I would like to use DNSSEC and also encrypt the outbound traffic,
but I have doubts about foloowing:

* Unbound does not support encryption natively (from own code
base) AFAIK. I have come across two methods to encrypt DNS traffic:
TOR and DNSCrypt. Are there any other alternatives?

You would need answers from other member of this mailing list for
that. ssl-upstream is one option, but it needs an upstream resolver
that performs this weird style of encryption (i.e. another unbound).

* Will DNSSEC be disabled when using any encryption method or if
the DNS query is forwarded to listening daemon (like
TOR/DNSCrypt)?

No, dnssec can work if enabled.

* When forwarding to a locally listening daemon,
"do-not-query-localhost: no" must be enabled for forwarding to
work. Is this a security risk?

It is there as a second-order-mitigation for certain self-recursion
exploits. But if you disable it I would consider it no security risk.

* Does one specify a forward-zone when using DNSSEC, or is it left
up to Unbound to decide (or maybe either method is acceptable)? I
think without forward-zone, Unbound just uses the list from
root.hints?

This is independent from DNSSEC. You will have to set the
forward-zone to forward to another place, if you want. Otherwise it
uses the root.hints.

* I have setup DNSSEC using the unbound-anchor command, and
root.key shows date as: Feb 1 15:12:15 2014. Tests show however,
that server is NOT using DNSSEC. Debug is set to verbosity: 4, and
log shows no errors. All files in /var/unbound are owned by
unbound:unbound with exception of unbound.conf.

You (most likely I think) have not configured auto-trust-anchor-file:
"/var/unbound/root.key" in unbound.conf.

Best regards,
Wouter

Tony_Finch · February 24, 2014, 12:50pm

The same is true for DNScrypt, and Tor is sort-of analogous.

There is not currently any common way to encrypt DNS. There is going
to be a discussion at the London IETF meeting next week about possible
approaches, but it is still very early days.

Tony.

Beeblebrox · February 24, 2014, 12:52pm

Hi Wouter. Thanks for your explanation.

For the dnssec not-enabled problem, my unbound.conf has that file
enabled. Other settings (edited to save space). Currently no
forward-zoned defined
port: 53 \ do-ip4: yes \ do-ip6: no \ do-udp: yes \ do-tcp: yes
root-hints: "/var/unbound/root.hints"
hide-identity: yes \ hide-version: yes
harden-dnssec-stripped: yes \ harden-short-bufsize: yes \
harden-large-queries: yes
auto-trust-anchor-file: "/var/unbound/root.key" \ val-clean-additional: yes

Leen_Besselink · February 24, 2014, 1:01pm

Hi Wouter. Thanks for your explanation.

For the dnssec not-enabled problem, my unbound.conf has that file
enabled. Other settings (edited to save space). Currently no
forward-zoned defined
port: 53 \ do-ip4: yes \ do-ip6: no \ do-udp: yes \ do-tcp: yes
root-hints: "/var/unbound/root.hints"
hide-identity: yes \ hide-version: yes
harden-dnssec-stripped: yes \ harden-short-bufsize: yes \
harden-large-queries: yes
auto-trust-anchor-file: "/var/unbound/root.key" \ val-clean-additional: yes
------------------------
drill com. SOA +dnssec
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 56264
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION: \ ;; +dnssec. IN SOA
;; ANSWER SECTION:
;; AUTHORITY SECTION: 86400 IN SOA a.root-servers.net.
nstld.verisign-grs.com. 2014022400 1800 900 604800 86400
-----------------------

Also, if I set "include: /var/unbound/ad_servers" in unbound.conf is
breaking the server start-up for some reason. The file has parsed list
from yoyo-ad-servers, in the form:
local-zone: "101com.com" redirect
local-data: "101com.com A 127.0.0.1" ...etc
What's the correct syntax for "include"?

I believe it needs quotes:

include: "/var/unbound/ad_servers"

Beeblebrox · February 24, 2014, 2:37pm

Leen: Thanks for the tip. It still would not start, then I deleted
most of the entries in the included file, leaving 15 or so records in
it. Unbound then started correctly. Apparently there was entry in the
file that Unbound disliked. I wish it would have complained instead
of dying silently. (verbose is now 5)

There is not currently any common way to encrypt DNS.

(Tony) - well then, it's dnscrypt / tor until encryption becomes available.
I have dnscrypt working and Unbound correctly forwardS to that. I do
want to get tor-dns working as well however, specially since socks-5
has a dns-listener on 9053 (udp). I tried as below, but it did not
work probably because Unbound used tcp? Is there a way to inform
Unbound that the forward should be udp?
forward-addr: 192.168.2.xx@9053

Back to the DNSSEC issue. Debug output for Unbound start-up below. Is
there any verbose output I can provide?
setup SSL certificates
chdir to /var/unbound
drop user privileges, run as unbound
module config: "validator iterator"
reading autotrust anchor file /var/unbound/root.key
validator nsec3cfg keysz 1024 mxiter 150
validator nsec3cfg keysz 2048 mxiter 500
validator nsec3cfg keysz 4096 mxiter 2500
target fetch policy for level 0 is 3
target fetch policy for level 1 is 2
target fetch policy for level 2 is 1
target fetch policy for level 3 is 0
target fetch policy for level 4 is 0
total of 59567 outgoing ports available
start threads
vent mini-event-1.4.20 uses not_obtainable method.
Reading root hints from /var/unbound/root.hints
    ip6 2001:dc3::35 port 53 (len 28)
    ip4 202.12.27.33 port 53 (len 16)
    ip6 2001:500:3::42 port 53 (len 28)
    ip4 199.7.83.42 port 53 (len 16)
    ip6 2001:7fd::1 port 53 (len 28)
    ip4 193.0.14.129 port 53 (len 16)
    ip6 2001:503:c27::2:30 port 53 (len 28)
    ip4 192.58.128.30 port 53 (len 16)
    ip6 2001:7fe::53 port 53 (len 28)
    ip4 192.36.148.17 port 53 (len 16)
    ip6 2001:500:1::803f:235 port 53 (len 28)
    ip4 128.63.2.53 port 53 (len 16)
    ip4 192.112.36.4 port 53 (len 16)
    ip6 2001:500:2f::f port 53 (len 28)
    ip4 192.5.5.241 port 53 (len 16)
    ip4 192.203.230.10 port 53 (len 16)
    ip6 2001:500:2d::d port 53 (len 28)
    ip4 199.7.91.13 port 53 (len 16)
    ip4 192.33.4.12 port 53 (len 16)
    ip4 192.228.79.201 port 53 (len 16)
    ip6 2001:503:ba3e::2:30 port 53 (len 28)
    ip4 198.41.0.4 port 53 (len 16)
cache memory msg=66072 rrset=66072 infra=2600 val=66280
autotrust probe timer callback

Jaap · February 24, 2014, 2:43pm

Leen: Thanks for the tip. It still would not start, then I deleted
    most of the entries in the included file, leaving 15 or so records in
    it. Unbound then started correctly. Apparently there was entry in the
    file that Unbound disliked. I wish it would have complained instead
    of dying silently. (verbose is now 5)

unbound-checkconf is your friend

jaap

Beeblebrox · February 24, 2014, 3:31pm

unbound-checkconf is your friend

Thank you Jaap. The error was "duplicate zone entry" which checkconf
showed, and was corrected.

The dnssec check at http://dnssectest.sidnlabs.nl/test.php shows
Permissive mode detected: Your DNSSEC is configured in "permissive
mode" (or you use a combination of validating- and non-validating
resolvers) and as such you are not protected.

I don't have "dnssec-accept-expired" or "val-permissive-mode" set in
the config file, and google did not turn up much else. I don't imagine
any "private-address" entry to cause permissive diagnosis.

One final thought: I have Unbound (and dnscrypt-proxy) running in a
FreeBSD jail that has devfs mounted but nothing else. Jail rules do
not allow the likes of "creating raw sockets" from inside the jail.
Are there any special socket/devfs requirements for dnssec that are
apart from the requirements for Unbound to run properly? Since Unbound
is in a jail, no need for chroot ( chroot: "" )

Beeblebrox · February 26, 2014, 9:03am

Could someone tell me what this output means when checking dnssec
status? Using dnscrypt-proxy as forward-zone, which in turn forwards
to dnssec enabled resolver (176.56.237.171 holland)

$ drill -TD com. SOA
Warning: No trusted keys were given. Will not be able to verify authenticity!
;; Domain: .
;; Signature ok but no chain to a trusted key or ds record
[S] . 172800 IN DNSKEY 256 3 8 ;{id = 33655 (zsk), size = 1024b}
. 172800 IN DNSKEY 257 3 8 ;{id = 19036 (ksk), size = 2048b}
Checking if signing key is trusted:
New key: . 172800 IN DNSKEY 256 3 8
AwEAAb8sU6pbYMWRbkRnEuEZw9NSir707TkOcF+UL1XiK4NDJOvXRyX195Am5dQ7bRnnuySZ3daf37vvjUUhuIWUAQ4stht8nJfYxVQXDYjSpGH5I6Hf/0CZEoNP6cNvrQ7AFmKkmv00xWExKQjbvnRPI4bqpMwtHVzn6WybBZ6kuqED
;{id = 33655 (zsk), size = 1024b}
[S] com. 86400 IN DS 30909 8 2
e2d3c916f6deeac73294e8268fb5885044a833fc5459588f4a9184cfc41a5766
;; Domain: com.
;; Signature ok but no chain to a trusted key or ds record
[S] com. 86400 IN DNSKEY 256 3 8 ;{id = 45932 (zsk), size = 1024b}
com. 86400 IN DNSKEY 257 3 8 ;{id = 30909 (ksk), size = 2048b}
[S] com. 900 IN SOA a.gtld-servers.net.
nstld.verisign-grs.com. 1393405023 1800 900 604800 86400
;;[S] self sig OK; [B] bogus; [T] trusted

Jelte_Jansen · February 26, 2014, 10:14am

Drill does not have a pre-configured or built-in trust anchor (e.g. the
root key); So the only thing it can say right now is that the crypto
*looks* ok, relative to the other records it finds, hence an [S] instead
of a [T].

If you pass it a key with -k it should print about the same, but with
[T] values.

$ drill -k ~/root.key -TD com. SOA

One insecure way to easily get the root key is ldns-keyfetcher -s (it
simply does a query and stores the result)

Beeblebrox · February 26, 2014, 2:23pm

Thank you for your reply.

It occurred to me when reading your message, that I'm actually using two keys:
1. var/unbound/root.key, which was generated by unbound-anchor
2. The key that dnscrypt-proxy needs to use, which is envoked by:
--provider-key 67C0:0F2C:21C5:5481:45DD:7CB4:6A27:1AF2:EB96:9931:40A3:09B6:2B8D:1653:1185:9C66
--provider-name=2.dnscrypt-cert.resolver1.dnscrypt.eu
--resolver-address=176.56.237.171:443"

I'm getting mixed results with this chain when dnssec is enabled - it
works ok for a while then seems to phase out. Some DNS queries return
empty string, while 1/2 hour ago the query returned normally. Not the
case when NOT using dnssec.

* Can the fluctuating performance of my setup be attributed to the
fact that two separate keys are being used? Shouldn't I be using just
one key?
* When doing drill -k, which key should I reference? root.key or
provider-key that dnscrypt-proxy is using? =>

$ drill -k var/unbound/root.key -TD com. SOA
;; Number of trusted keys: 1
;; Domain: .
[T] . 172800 IN DNSKEY 256 3 8 ;{id = 33655 (zsk), size = 1024b}
. 172800 IN DNSKEY 257 3 8 ;{id = 19036 (ksk), size = 2048b}
Checking if signing key is trusted:
New key: . 172800 IN DNSKEY <numbers> ; {id = 33655 (zsk),
size = 1024b}
Trusted key: . 172800 IN DNSKEY <numbers> ;{id = 19036
(ksk), size = 2048b}
Trusted key: . 172800 IN DNSKEY <numbers> ;{id = 33655
(zsk), size = 1024b}
Key is now trusted!
Trusted key: . 172800 IN <numbers> ;{id = 19036 (ksk), size = 2048b}
[T] com. 86400 IN DS 30909 8 2
e2d3c916f6deeac73294e8268fb5885044a833fc5459588f4a9184cfc41a5766
[B] ;; Error verifying denial of existence for name com.NS: No DNSSEC
signature(s)

Bright_Star · March 3, 2014, 3:00pm

Hi Beeblebrox,
About an year (and few months) back I/we created an online (hosting)
server account with both bind and unbound, where unbound was set to
listen on 10053, 10453, etc, and bind was listening on 53.

It was for "general" test purpose. (We were basically testing
various things related with DNSSEC + TLSA + stronger encryptions,
etc). I/we discontinued service around few months back.
(I/we will start such server again, when more spare/enough
time+money is available+possible).

My multiple different tests (via Tor network):

Local unbound (forwarding) -> Tor-network -> remote-Unbound: worked.
  * With unbound-encryption enabled, and without, both worked.
  * Other tools based encrypted connection also worked.
  * TLSA Validator for Firefox from CZ.NIC also worked (though not
100% bugless/perfect yet).
  * Other tools used: dns2socks, socat, PuTTY, OpenSSH, etc.
  * Multiple virtual/tap local NICs were needed, created & used.
  * Local firewall was configured to NOT-allow other apps to use the
local Unbound, which will go through Tor-network.
  * TBB/Tor-Firefox's DNSSEC/TLSA etc related addon were configured
to use the local Unbound, which will go through Tor-network.
  * About 5 to 15 users were testing+using the server. (I/we didn't
"publicly" offer/started the service, or else, there might have been
more public users, and then our Tests might have been interrupted or
produce incorrect results).
  * For SSH tunnels, we used much stronger encryption
certs+credentials, and was shared with users over pgp/gpg encrypted
emails.
  * For some tests, multiple local unbound in chain were used/needed.

Various combinations of tests were done, with
(local-)unbound-to-(remote-)unbound, and, unbound-to-bind, etc via
tor-network and also via direct-network.

My/our (local) side machines were Windows, (some of other users used
Linux locally). Remote server was (CentOS) Linux.

Basically, at end, i sticked with using this config for long time :
local unbound from local computers connected with a remote
unbound/bind (inside remote server) through SSH encrypted tunnel
going through Tor-SOCKS5-network to the remote server. (I didn't
need to use unbound's upstream encryption feature). This was faster
& stable & more consistent & more correct.

We didn't disable other configurations, all/they were simultaneously
running.

When unbound-to-unbound or unbound-to-bind via tor-socks5-network
(with & without encryption for unb-to-unb) configurations were used,
WITHOUT ssh tunnel(s), then communication responses were delayed
randomly, and often webpage refreshing was needed, for
Firefox's/TBB-firefox's DNSSEC-Validator or TLSA-Validator addon(s)
to show status correctly. Those firefox addon(s) is/are able to show
if dnssec + tlsa authentication(s) is/are succeeding or failing and
also show slightly more related status/info.

Very few (and very large) web service providers, use Geo IP location
based forwarding/redirection mechanism in their server collection to
provide slightly different webpage or service, on such cases, a
webpage obtained by firefox (using PORT 80 or 443 based traffic) and
shown dnssec/tlsa results (obtained from our server, which in turn
obtained result from service provider server's PORT 53) were
slightly less accurate, but for most other web sites, results were
correct (as all type of traffic were coming from same server, and
were usually tuned for same type of services from all of their servers).

Other DNS (dnssec+tlsa supported) related query tools were working
more accurately, via Tor-network, (than Firefox).

Best would be, when/if Tor-developers would/could include an
internal/built-in ldns/unbound library (inside "Tor" socks5 server),
which can/need-to perform its own DNSSEC + TLSA authenticated dns
resolving + communication with destination sites, then, firefox or
any dns tools, all will get very accurate results. And for this to
work correctly, some type of "integrity-test" mechanism is also
needed to be done by the "tor" core process/software, to figure out,
if exit-node's ldns/unbound library is always obtaining correct or
rigged results, and such "integrity-test"s must be done in a random
frequency, and TorButton addon also must/need-to show few more
(DNSSEC + TLSA, two) icons in addon bar or around firefox menu-bar.

-- Bright Star.

Received from Tony Finch, on 2014-02-24 4:50 AM:

Beeblebrox · March 6, 2014, 11:20am

It seems I finally figured out using dnscrypt + unbound + DNSSEC:

Stop Unbound and specify the dnscrypt-proxy IP:port as “forward-addr” in unbound.conf
Start dnscrypt-proxy with below, where provider-key / provider-name is whatever you choose from http://dnscrypt.org. For example: dnscrypt_proxy_flags=“-d -a :port --provider-key 67C0:0F2C:21C5:5481:45DD:7CB4:6A27:1AF2:EB96:9931:40A3:09B6:2B8D:1653:1185:9C66 --provider-name=2.dnscrypt-cert.resolver1.dnscrypt.eu --resolver-address=176.56.237.171:443”
Now re-run: # unbound-anchor -a “/var/unbound/root.key”, which will refresh/reset the root.key to signature of forward-addr, which in turn is the dnscrypt-proxy signature given when we started dnscrypt.
Start Unbound and try your DNSSEC validation: drill -k var/unbound/root.key -TD com. SOA => comes back all “[T] trusted”
One question: Should “unbound-anchor” be re-run periodically or on unbound startup, or is the root.key self-refreshed by Unbound internals?
Final bonus: I have all of this running in a FreBSD jail, and pf redirects to the dns-jail all port 53 traffic from internal LAN(s) and other jails. Awesome!

Bright Star: Very interesting information. Thank you.

For Tor, I did not realize what port 9053 setting was untill I got some IRC help fro the #tor channel. Apparently, 9053 listener just passes a regular DNS lookup to the Tor exit node and uses whatever that exit node has defined as DNS forward server. This is exactly the DNS leak problem (non-encrypted traffic) and should be completely avoided, not to mention the possibility of “malicious exit node” employing its own poisoned DNS server - Avoid Completely.

However I have since become hesitant to use Tor-encryption for DNS, since as you stated there currently is no DNSSEC structure inside Tor. DNSSEC is not mandatory of course, but for non-dnssec, we at least know who the counter party is (google, opendns or whomever), whereas inside a Tor layer, you have absolutely no idea regarding the trust level of the DNS on the exit node. Considering that Tor was designed for relaying (not authenticating), Tor-encrypted DNS opens the user to a wide possibility of DNS compromise IMHO. The sanest article I have come accross re setup of Tor-encrypted DNS lookups describes using dsocks (rather than socks): https://trac.torproject.org/projects/tor/wiki/doc/PreventingDnsLeaksInTor

Thanks to everyone for their help & Regards.

Tony_Finch · March 6, 2014, 1:48pm

Is there some re-signing going on? DNSSEC is supposed to be end-to-end so
the same root trust anchor should work regardless of where the DNS data
comes from.

Tony.