unbound - DoT

Help on building IPFire & Feature Requests
ummeegge
Community Developer
Community Developer
Posts: 4893
Joined: October 9th, 2010, 10:00 am

unbound - DoT

Post by ummeegge » November 26th, 2018, 4:36 pm

Hi all,
since a couple of topics i try to bring some custom forwarders for DNS-over-TLS (DOT) to life whereby the starting idea comes from here --> viewtopic.php?t=21072 .

29.01.2019:
EDIT: The current state is to integrate a webuserinterface which includes all DNS sections into one. Actually there is a DNS-over-TLS webuserinterface available (regular DNS servers can also be added) example can e.g. looks like this -->
Image

All in here edited servers will be integrated into /etc/unbound/forward.conf. Since IPFire have more locations where DNS can be configure but also be overviewed a lot more work is to do but this topic should be there to test DNS-over-TLS which is already functional and available, the rest is currently a little future sound.

There is also a in- uninstaller to test all that which can be executed via the following commands:

Code: Select all

cd /tmp || exit 1 &&
wget https://gitlab.com/ummeegge/dot-for-ipfire/raw/master/dot_wui/dot_in-uninstaller.sh &&
chmod +x dot_in-uninstaller.sh
./dot_in-uninstaller.sh
All changes can be overviewed in here --> https://gitlab.com/ummeegge/dot-for-ipf ... er/dot_wui .
The DNS-over-TLS menu can be found under the IPFire menu of the WUI.
Regular DNS server can also be configured.

A short (fast made) video is also available in here --> https://people.ipfire.org/~ummeegge/vid ... vertls.mp4 . Hope this is somehow useful.
[/EDIT]

Some debugging ideas:

tcpick says:

Code: Select all

$ tcpick -i red0 -C "port 853"  
Starting tcpick 0.2.1 at 2018-11-28 19:42 CET
Timeout for connections is 600
tcpick: listening on red0
setting filter: "port 853"
1      SYN-SENT       192.168.123.2:43276 > 89.234.186.112:853
1      SYN-RECEIVED   192.168.123.2:43276 > 89.234.186.112:853
1      ESTABLISHED    192.168.123.2:43276 > 89.234.186.112:853
2      SYN-SENT       192.168.123.2:44456 > 185.49.141.37:853
1      FIN-WAIT-1     192.168.123.2:43276 > 89.234.186.112:853
2      SYN-RECEIVED   192.168.123.2:44456 > 185.49.141.37:853
2      ESTABLISHED    192.168.123.2:44456 > 185.49.141.37:853
1      FIN-WAIT-2     192.168.123.2:43276 > 89.234.186.112:853
1      TIME-WAIT      192.168.123.2:43276 > 89.234.186.112:853
1      CLOSED         192.168.123.2:43276 > 89.234.186.112:853
2      FIN-WAIT-1     192.168.123.2:44456 > 185.49.141.37:853
2      FIN-WAIT-2     192.168.123.2:44456 > 185.49.141.37:853
2      RESET          192.168.123.2:44456 > 185.49.141.37:853
3      SYN-SENT       192.168.123.2:51602 > 159.69.198.101:853
3      SYN-RECEIVED   192.168.123.2:51602 > 159.69.198.101:853
3      ESTABLISHED    192.168.123.2:51602 > 159.69.198.101:853
4      SYN-SENT       192.168.123.2:48720 > 145.100.185.15:853
3      FIN-WAIT-1     192.168.123.2:51602 > 159.69.198.101:853
3      FIN-WAIT-2     192.168.123.2:51602 > 159.69.198.101:853
3      RESET          192.168.123.2:51602 > 159.69.198.101:853
4      SYN-RECEIVED   192.168.123.2:48720 > 145.100.185.15:853
4      ESTABLISHED    192.168.123.2:48720 > 145.100.185.15:853
5      SYN-SENT       192.168.123.2:48722 > 145.100.185.15:853
4      FIN-WAIT-1     192.168.123.2:48720 > 145.100.185.15:853
6      SYN-SENT       192.168.123.2:36930 > 158.64.1.29:853
4      FIN-WAIT-2     192.168.123.2:48720 > 145.100.185.15:853
4      RESET          192.168.123.2:48720 > 145.100.185.15:853
5      SYN-RECEIVED   192.168.123.2:48722 > 145.100.185.15:853
5      ESTABLISHED    192.168.123.2:48722 > 145.100.185.15:853
6      SYN-RECEIVED   192.168.123.2:36930 > 158.64.1.29:853
6      ESTABLISHED    192.168.123.2:36930 > 158.64.1.29:853
7      SYN-SENT       192.168.123.2:44466 > 185.49.141.37:853
5      FIN-WAIT-1     192.168.123.2:48722 > 145.100.185.15:853
7      SYN-RECEIVED   192.168.123.2:44466 > 185.49.141.37:853
7      ESTABLISHED    192.168.123.2:44466 > 185.49.141.37:853
5      FIN-WAIT-2     192.168.123.2:48722 > 145.100.185.15:853
^C5      RESET         
127 packets captured
7 tcp sessions detected

Shortend check for encryption with tcpdump --> https://wiki.ipfire.org/addons/tcpdump/start

Check with normal DNS:

Code: Select all

$ tcpdump -vv -x -X -s1500 -i red0 'port 53' 
tcpdump: listening on red0, link-type EN10MB (Ethernet), capture size 1500 bytes
08:17:34.724408 IP (tos 0x0, ttl 64, id 59365, offset 0, flags [none], proto UDP (17), length 69)
    ipfire.local.43864 > google-public-dns-b.google.com.domain: [udp sum ok] 22286+ [1au] A? nETzMAfia.dE. ar: . OPT UDPsize=4096 DO (41)
	0x0000:  4500 0045 e7e5 0000 4011 c40c c0a8 0202  E..E....@.......
	0x0010:  0808 0404 ab58 0035 0031 486a 570e 0100  .....X.5.1HjW...
	0x0020:  0001 0000 0000 0001 096e 4554 7a4d 4166  .........nETzMAf
	0x0030:  6961 0264 4500 0001 0001 0000 2910 0000  ia.dE.......)...
	0x0040:  0080 0000 00                             .....
08:17:34.724833 IP (tos 0x0, ttl 64, id 63640, offset 0, flags [none], proto UDP (17), length 69)
Check with Dns-over-TLS on the same address:

Code: Select all

$ tcpdump -vv -x -X -s1500 -i red0 'port 853'
tcpdump: listening on red0, link-type EN10MB (Ethernet), capture size 1500 bytes
08:18:52.944440 IP (tos 0x0, ttl 64, id 26616, offset 0, flags [none], proto TCP (6), length 60)
    ipfire.local.60164 > dns.de.blahdns.com.853: Flags [S], cksum 0x8dcc (correct), seq 1121951880, win 29200, options [mss 1460,sackOK,TS val 1608642090 ecr 0,nop,wscale 7], length 0
	0x0000:  4500 003c 67f8 0000 4006 ea6e c0a8 0202  E..<g...@..n....
	0x0010:  9f45 c665 eb04 0355 42df a088 0000 0000  .E.e...UB.......
	0x0020:  a002 7210 8dcc 0000 0204 05b4 0402 080a  ..r.............
	0x0030:  5fe1 ee2a 0000 0000 0103 0307            _..*........
08:18:52.946428 IP (tos 0x0, ttl 64, id 16626, offset 0, flags [none], proto TCP (6), length 60)
with loglevel 5 (extensive) you can also debug how the connections are authenticated. Example with dot-de.blahdns.com:

Code: Select all

Nov 28 21:11:38 ipfire-prime unbound: [2648:3] debug: peer certificate: #012        Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3#012        Validity#012            Not Before: Oct 26 02:11:30 2018 GMT#012            Not After : Jan 24 02:11:30 2019 GMT#012        Subject: CN=dot-de.blahdns.com#012        X509v3 extensions:#012            X509v3 Key Usage: critical#012                Digital Signature, Key Encipherment#012            X509v3 Extended Key Usage: #012                TLS Web Server Authentication, TLS Web Client Authentication#012            X509v3 Basic Constraints: critical#012                CA:FALSE#012            X509v3 Subject Key Identifier: #012                B9:16:FB:86:E5:D9:D9:62:70:14:DA:BB:21:39:57:00:96:1B:2C:89#012            X509v3 Authority Key Identifier: #012                keyid:A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1#012#012            Authority Information Access: #012                OCSP - URI:http://ocsp.int-x3.letsencrypt.org#012                CA Issuers - URI:http://cert.int-x3.letsencrypt.org/#012#012            X509v3 Subject Alternative Name: #012                DNS:dns.de.blahdns.com, DNS:doh-de.blahdns.com, DNS:doh.de.blahdns.com, DNS:dot-de.blahdns.com#012            X509v3 Certificate Policies: #012                Policy: 2.23.140.1.2.1#012                Policy: 1.3.6.1.4.1.44947.1.1.1#012                  CPS: http://cps.letsencrypt.org#012                  User Notice:#012                    Explicit Text: This Certificate may only be relied upon by Relying Parties and only in accordance with the Certificate Policy found at https://letsencrypt.org/repository/#012#012            CT Precertificate SCTs: #012                Signed Certificate Timestamp:#012                    Version   : v1 (0x0)#012                    Log ID    : 74:7E:DA:83:31:AD:33:10:91:21:9C:CE:25:4F:42:70:#012                                C2:BF:FD:5E:42:20:08:C6:37:35:79:E6:10:7B:CC:56#012                    Timestamp : Oct 26 03:11:30.128 2018 GMT#012                    Extensions: none#012                    Signature : ecdsa-with-SHA256#012                                30:45:02:20:32:E7:A8:D5:74:30:F9:AF:49:E2:6A:BA:#012                                05:51:B9:27:E7:2C:38:BA:54:47:60:FE:D4:C3:76:A5:#012                                CC:45:CC:A4:02:21:00:9F:CE:6A:3E:58:CD:C3:09:4F:#012                                53:4A:03:89:FB:79:3B:79:A8:E9:B5:1A:EB:B3:9D:C0:#012                                D4:47:04:E3:DC:1A:60#012                Signed Certificate Timestamp:#012                    Version   : v1 (0x0)#012                    Log ID    : 29:3C:51:96:54:C8:39:65:BA:AA:50:FC:58:07:D4:B7:#012                                6F:BF:58:7A:29:72:DC:A4:C3:0C:F4:E5:45:47:F4:78#012                    Timestamp : Oct 26 03:11:30.764 2018 GMT#012                    Extensions: none#012                    Signature : ecdsa-with-SHA256#012                                30:46:02:21:00:C6:21:F9:E1:80:E5:F3:9A:FC:54:7B:#012                                B2:2C:83:20:60:37:3D:C0:E8:16:65:2E:F9:E3:7C:FD:#012                                52:43:82:28:EF:02:21:00:C7:64:62:9A:26:50:F2:74:#012                                23:C1:5D:96:07:A0:63:46:89:32:CC:32:1D:6F:05:9B:#012                                7D:48:35:7B:76:6B:21:2D
Nov 28 21:11:38 ipfire-prime unbound: [2648:3] debug: SSL connection to dot-de.blahdns.com authenticated ip4 159.69.198.101 port 853 (len 16)
If the TLS verification do not works, something like this appears in messages:

Code: Select all

Nov 28 19:06:16 ipfire-prime unbound: [27450:0] info: start of service (unbound 1.8.1).
Nov 28 19:06:17 ipfire-prime unbound: [27450:3] error: ssl handshake failed crypto error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
Nov 28 19:06:17 ipfire-prime unbound: [27450:3] notice: ssl handshake failed 80.67.188.188 port 853
<-- See https://www.nlnetlabs.nl/bugs-script/sh ... id=658#c15 and https://blog.stigok.com/2018/06/19/veri ... d-dns.html for a short/handy description.

DNSSEC check is possibly deactivated nevertheless DNSSEC works if it is supported
Image
check via https://dnssec.vs.uni-due.de/ ) and the DNS servers configured via setup are also still present and shown on the starting page of the WUI, if the DoT server will be disabled, unbound will use the old DNS servers from the setup after an unbound init restart which does also the uninstaller above. The host entries are working with this the dnsforward.cgi should also works as expected.

If may someone do see that i delete the internet in that way ;) please let it me know.

Best,

UE

EDIT(s):

- Some online DNS testing addresses: - Causing DoT in general, i know the client handshake delivers also in the 'client hello' the domain name which will be delivered in clear text but TLSv1.3 seems to deliver salvation --> https://tools.ietf.org/html/draft-ietf- ... ryption-02 -->https://blog.cloudflare.com/encrypted-sni/ and OpenSSL-1.1.1 for IPFire is also not that far away --> https://bugzilla.ipfire.org/show_bug.cgi?id=11913 already there so let´s invest into the future :D and give it some good testings .

Some news:

- DNS Query Name Minimisation to Improve Privacy RFC 7816 --> https://tools.ietf.org/html/rfc7816 --> https://nlnetlabs.nl/downloads/presenta ... oarc24.pdf has been added to DoT configuration.
Even "DNS Query Name Minimisation" has been enabled by default in unbound.conf since unbound-1.7.2 , tests via

Code: Select all

dig txt qnamemintest.internet.nl +short
delivered

Code: Select all

a.b.qnamemin-test.internet.nl.
"NO - QNAME minimisation is NOT enabled on your resolver :("

this directive is now fixed integrated inDoT section in forward.conf.

By executing the dig command from above the following results should be seen:

Code: Select all

$ dig txt qnamemintest.internet.nl +short
a.b.qnamemin-test.internet.nl.
"HOORAY - QNAME minimisation is enabled on your resolver :)!"
otherwse Qname minimization does not work...

- If someone is interested in testing tools, in here --> https://people.ipfire.org/~ummeegge/tshark/ tshark can be found, here --> https://people.ipfire.org/~ummeegge/TCPick/ a patched Tcpick version (Debian Patch series) can be found.
Since kdig is meanwhile available in IPFire it might be the easiest way to debug the connections --> https://www.mankier.com/1/kdig .

Current testing environment looks like this:

Current /var/ipfire/dns/tlsconfig:

Code: Select all

on,unicast.censurfridns.dk,89.233.43.71,853,Censurfridns DK
on,rec1.dns.lightningwirelabs.com,81.3.27.54,853,Lightningwirelabs DoT rec1
on,kaitain.restena.lu,158.64.1.29,853,Kaitan lu
on,dnsovertls.sinodun.com,145.100.185.15,853,Sinodun 1
on,dnsovertls1.sinodun.com,145.100.185.16,853,Sinodun 2
on,dns.cmrg.net,199.58.81.218,853,CMRG
on,dns.neutopia.org,89.234.186.112,853,Neutopia
on,dot-jp.blahdns.com,108.61.201.119,853,BlahDNS JP
on,dot-de.blahdns.com,159.69.198.101,853,BlahDNS DE
on,iana.tenta.io,99.192.182.200,853,Tenta iana
on,opennic.tenta.io,99.192.182.100,853,Tenta opennic
on,dns2.digitalcourage.de,46.182.19.48,853,Digitalcourage
on,dns.quad9.net,9.9.9.9,853,Quad9 Sec
on,cloudflare-dns.com,1.1.1.1,853,Cloudflair
on,security-filter-dns.cleanbrowsing.org,185.228.168.9,853,Security Filter
on,dns.adguard.com,176.103.130.130,853,Adguard
on,getdnsapi.net,185.49.141.37,853,GetDNS API
on,dot.securedns.eu,146.185.167.43,853,securedns.eu
on,dns-tls.bitwiseshift.net,81.187.221.24,853,dns-tls.bitwiseshift.net
on,dot1.dnswarden.com,213.136.85.253,853,DNSWarden1
on,dot2.dnswarden.com,213.136.83.50,853,DNSwarden2
on,dns.google,8.8.8.8,853,GoogleDNS
on,dns.google,8.8.4.4,853,GoogleDNS2
on,security-filter-dns.cleanbrowsing.org,185.228.169.9,853,Security-Filter2
on,dns.adguard.com,176.103.130.131,853,Adguard2
on,dns.quad9.net,9.9.9.10,853,Quad9 Insec
on,cloudflare-dns.com,1.0.0.1,853,Cloudflair 2
on,public-dns-b.dns.sb,185.222.222.222,853,DNS.SB
off,dns1.dnsfilter.com,103.247.36.36,853,DNSfilter

/etc/unbound/forward.conf

Code: Select all

# This file is automatically generated and any changes
# will be overwritten. DO NOT EDIT!

# DNS-over-TLS configuration block
server:
    tls-cert-bundle: /etc/ssl/certs/ca-bundle.crt
    qname-minimisation-strict: yes

forward-zone:
    name: "."
    forward-tls-upstream: yes

    forward-addr: 89.233.43.71@853#unicast.censurfridns.dk
    forward-addr: 81.3.27.54@853#rec1.dns.lightningwirelabs.com
    forward-addr: 158.64.1.29@853#kaitain.restena.lu
    forward-addr: 145.100.185.15@853#dnsovertls.sinodun.com
    forward-addr: 145.100.185.16@853#dnsovertls1.sinodun.com
    forward-addr: 199.58.81.218@853#dns.cmrg.net
    forward-addr: 89.234.186.112@853#dns.neutopia.org
    forward-addr: 108.61.201.119@853#dot-jp.blahdns.com
    forward-addr: 159.69.198.101@853#dot-de.blahdns.com
    forward-addr: 99.192.182.200@853#iana.tenta.io
    forward-addr: 99.192.182.100@853#opennic.tenta.io
    forward-addr: 46.182.19.48@853#dns2.digitalcourage.de
    forward-addr: 9.9.9.9@853#dns.quad9.net
    forward-addr: 1.1.1.1@853#cloudflare-dns.com
    forward-addr: 185.228.168.9@853#security-filter-dns.cleanbrowsing.org
    forward-addr: 176.103.130.130@853#dns.adguard.com
    forward-addr: 185.49.141.37@853#getdnsapi.net
    forward-addr: 146.185.167.43@853#dot.securedns.eu
    forward-addr: 81.187.221.24@853#dns-tls.bitwiseshift.net
    forward-addr: 213.136.85.253@853#dot1.dnswarden.com
    forward-addr: 213.136.83.50@853#dot2.dnswarden.com
    forward-addr: 8.8.8.8@853#dns.google
    forward-addr: 8.8.4.4@853#dns.google
    forward-addr: 185.228.169.9@853#security-filter-dns.cleanbrowsing.org
    forward-addr: 176.103.130.131@853#dns.adguard.com
    forward-addr: 1.0.0.1@853#cloudflare-dns.com

Testings which ones are working looks like this:

Code: Select all

=====================================================================================================

                    Will check now your configured DNS-over-TLS servers from '/etc/unbound/forward.conf'


=====================================================================================================
From Host: unicast.censurfridns.dk ---- With IP: 89.233.43.71 ---- Date: Fri May 17 10:56:56 CEST 2019

;; WARNING: can't connect to 89.233.43.71@853(TCP)
;; ERROR: failed to query server 89.233.43.71@853(TCP)

Encryption do not works, this server seems to be OFF

=====================================================================================================
From Host: rec1.dns.lightningwirelabs.com ---- With IP: 81.3.27.54 ---- Date: Fri May 17 10:56:56 CEST 2019

in 182.1 ms

The encryption is OK and works with: TLS1.3-ECDHE-SECP256R1-ECDSA-SECP384R1-SHA384-CHACHA20-POLY1305

The certificate is trusted and OK

The DNSSEC validation works and is OK

=====================================================================================================
From Host: kaitain.restena.lu ---- With IP: 158.64.1.29 ---- Date: Fri May 17 10:56:56 CEST 2019

in 28.9 ms

The encryption is OK and works with: TLS1.2-ECDHE-SECP256R1-RSA-SHA512-AES-256-GCM

The certificate is trusted and OK

The DNSSEC validation works and is OK

=====================================================================================================
From Host: dnsovertls.sinodun.com ---- With IP: 145.100.185.15 ---- Date: Fri May 17 10:56:57 CEST 2019

in 33.3 ms

The encryption is OK and works with: TLS1.2-ECDHE-SECP256R1-RSA-SHA512-AES-256-GCM

The certificate is trusted and OK

The DNSSEC validation works and is OK

=====================================================================================================
From Host: dnsovertls1.sinodun.com ---- With IP: 145.100.185.16 ---- Date: Fri May 17 10:56:57 CEST 2019

in 173.6 ms

The encryption is OK and works with: TLS1.2-ECDHE-SECP256R1-RSA-SHA256-AES-256-GCM

The certificate is trusted and OK

The DNSSEC validation works and is OK

=====================================================================================================
From Host: dns.cmrg.net ---- With IP: 199.58.81.218 ---- Date: Fri May 17 10:56:57 CEST 2019

in 124.1 ms

The encryption is OK and works with: TLS1.2-ECDHE-SECP256R1-RSA-SHA256-AES-256-GCM

The certificate is trusted and OK

The DNSSEC validation works and is OK

=====================================================================================================
From Host: dns.neutopia.org ---- With IP: 89.234.186.112 ---- Date: Fri May 17 10:56:58 CEST 2019

in 57.4 ms

The encryption is OK and works with: TLS1.2-ECDHE-SECP256R1-RSA-SHA256-AES-256-GCM

The certificate is trusted and OK

The DNSSEC validation works and is OK

=====================================================================================================
From Host: dot-jp.blahdns.com ---- With IP: 108.61.201.119 ---- Date: Fri May 17 10:56:58 CEST 2019

in 858.6 ms

The encryption is OK and works with: TLS1.3-ECDHE-SECP256R1-RSA-PSS-RSAE-SHA256-AES-256-GCM

The certificate is trusted and OK

The DNSSEC validation works and is OK

=====================================================================================================
From Host: dot-de.blahdns.com ---- With IP: 159.69.198.101 ---- Date: Fri May 17 10:57:00 CEST 2019

in 79.0 ms

The encryption is OK and works with: TLS1.3-ECDHE-SECP256R1-RSA-PSS-RSAE-SHA256-AES-256-GCM

The certificate is trusted and OK

The DNSSEC validation works and is OK

=====================================================================================================
From Host: iana.tenta.io ---- With IP: 99.192.182.200 ---- Date: Fri May 17 10:57:00 CEST 2019

;; WARNING: TLS, handshake failed (Error in the certificate.)
;; ERROR: failed to query server 99.192.182.200@853(TCP)
The certificate is NOT trusted. The certificate chain uses expired certificate. 

Encryption do not works, this server seems to be OFF

=====================================================================================================
From Host: opennic.tenta.io ---- With IP: 99.192.182.100 ---- Date: Fri May 17 10:57:01 CEST 2019

;; WARNING: TLS, handshake failed (Error in the certificate.)
;; ERROR: failed to query server 99.192.182.100@853(TCP)
The certificate is NOT trusted. The certificate chain uses expired certificate. 

Encryption do not works, this server seems to be OFF

=====================================================================================================
From Host: dns2.digitalcourage.de ---- With IP: 46.182.19.48 ---- Date: Fri May 17 10:57:01 CEST 2019

in 42.7 ms

The encryption is OK and works with: TLS1.2-ECDHE-SECP256R1-RSA-SHA256-AES-256-GCM

The certificate is trusted and OK

The DNSSEC validation works and is OK

=====================================================================================================
From Host: dns.quad9.net ---- With IP: 9.9.9.9 ---- Date: Fri May 17 10:57:02 CEST 2019

;; WARNING: TLS, peer has closed the connection
;; WARNING: can't receive reply from 9.9.9.9@853(TCP)
;; ERROR: failed to query server 9.9.9.9@853(TCP)

Encryption do not works, this server seems to be OFF

=====================================================================================================
From Host: cloudflare-dns.com ---- With IP: 1.1.1.1 ---- Date: Fri May 17 10:57:02 CEST 2019

in 57.4 ms

The encryption is OK and works with: TLS1.3-ECDHE-SECP256R1-ECDSA-SECP256R1-SHA256-AES-256-GCM

The certificate is trusted and OK

The DNSSEC validation works and is OK

=====================================================================================================
From Host: security-filter-dns.cleanbrowsing.org ---- With IP: 185.228.168.9 ---- Date: Fri May 17 10:57:03 CEST 2019

in 88.0 ms

The encryption is OK and works with: TLS1.2-ECDHE-X25519-RSA-SHA512-CHACHA20-POLY1305

The certificate is trusted and OK

The DNSSEC validation works and is OK

=====================================================================================================
From Host: dns.adguard.com ---- With IP: 176.103.130.130 ---- Date: Fri May 17 10:57:03 CEST 2019

in 37.8 ms

The encryption is OK and works with: TLS1.2-ECDHE-X25519-RSA-SHA256-AES-256-GCM

The certificate is trusted and OK

The DNSSEC validation works and is OK

=====================================================================================================
From Host: getdnsapi.net ---- With IP: 185.49.141.37 ---- Date: Fri May 17 10:57:03 CEST 2019

in 31.1 ms

The encryption is OK and works with: TLS1.2-ECDHE-SECP256R1-RSA-SHA512-AES-256-GCM

The certificate is trusted and OK

The DNSSEC validation works and is OK

=====================================================================================================
From Host: dot.securedns.eu ---- With IP: 146.185.167.43 ---- Date: Fri May 17 10:57:04 CEST 2019

in 89.2 ms

The encryption is OK and works with: TLS1.3-ECDHE-SECP256R1-RSA-PSS-RSAE-SHA256-AES-256-GCM

The certificate is trusted and OK

The DNSSEC validation works and is OK

=====================================================================================================
From Host: dns-tls.bitwiseshift.net ---- With IP: 81.187.221.24 ---- Date: Fri May 17 10:57:04 CEST 2019

;; WARNING: can't connect to 81.187.221.24@853(TCP)
;; ERROR: failed to query server 81.187.221.24@853(TCP)

Encryption do not works, this server seems to be OFF

=====================================================================================================
From Host: dot1.dnswarden.com ---- With IP: 213.136.85.253 ---- Date: Fri May 17 10:57:04 CEST 2019

;; WARNING: can't connect to 213.136.85.253@853(TCP)
;; ERROR: failed to query server 213.136.85.253@853(TCP)

Encryption do not works, this server seems to be OFF

=====================================================================================================
From Host: dot2.dnswarden.com ---- With IP: 213.136.83.50 ---- Date: Fri May 17 10:57:04 CEST 2019

;; WARNING: can't connect to 213.136.83.50@853(TCP)
;; ERROR: failed to query server 213.136.83.50@853(TCP)

Encryption do not works, this server seems to be OFF

=====================================================================================================
From Host: dns.google ---- With IP: 8.8.8.8 ---- Date: Fri May 17 10:57:05 CEST 2019

;; WARNING: TLS, handshake failed (Error in the certificate.)
;; ERROR: failed to query server 8.8.8.8@853(TCP)
The certificate is NOT trusted. The certificate issuer is unknown. The name in the certificate does not match the expected. 

Encryption do not works, this server seems to be OFF

=====================================================================================================
From Host: dns.google ---- With IP: 8.8.4.4 ---- Date: Fri May 17 10:57:05 CEST 2019

;; WARNING: TLS, handshake failed (Error in the certificate.)
;; ERROR: failed to query server 8.8.4.4@853(TCP)
The certificate is NOT trusted. The certificate issuer is unknown. The name in the certificate does not match the expected. 

Encryption do not works, this server seems to be OFF

=====================================================================================================
From Host: security-filter-dns.cleanbrowsing.org ---- With IP: 185.228.169.9 ---- Date: Fri May 17 10:57:05 CEST 2019

in 99.9 ms

The encryption is OK and works with: TLS1.2-ECDHE-X25519-RSA-SHA512-CHACHA20-POLY1305

The certificate is trusted and OK

The DNSSEC validation works and is OK

=====================================================================================================
From Host: dns.adguard.com ---- With IP: 176.103.130.131 ---- Date: Fri May 17 10:57:05 CEST 2019

in 28.4 ms

The encryption is OK and works with: TLS1.2-ECDHE-X25519-RSA-SHA256-AES-256-GCM

The certificate is trusted and OK

The DNSSEC validation works and is OK

=====================================================================================================
From Host: dns.quad9.net ---- With IP: 9.9.9.10 ---- Date: Fri May 17 10:57:06 CEST 2019

in 1923.7 ms

The encryption is OK and works with: TLS1.3-ECDHE-SECP256R1-ECDSA-SECP256R1-SHA256-AES-256-GCM

The certificate is trusted and OK

The DNSSEC validation works and is OK

=====================================================================================================
From Host: cloudflare-dns.com ---- With IP: 1.0.0.1 ---- Date: Fri May 17 10:57:08 CEST 2019

in 52.4 ms

The encryption is OK and works with: TLS1.3-ECDHE-SECP256R1-ECDSA-SECP256R1-SHA256-AES-256-GCM

The certificate is trusted and OK

The DNSSEC validation works and is OK

=====================================================================================================
From Host: public-dns-b.dns.sb ---- With IP: 185.222.222.222 ---- Date: Fri May 17 10:57:08 CEST 2019

;; WARNING: TLS, handshake failed (Error in the certificate.)
;; ERROR: failed to query server 185.222.222.222@853(TCP)
The certificate is NOT trusted. The name in the certificate does not match the expected. 

Encryption do not works, this server seems to be OFF

=====================================================================================================
From Host: security.dns.nextdns.io ---- With IP: 5.182.208.1 ---- Date: Fri May 17 10:57:08 CEST 2019

;; WARNING: TLS, peer has closed the connection
;; WARNING: can't receive reply from 5.182.208.1@853(TCP)
;; ERROR: failed to query server 5.182.208.1@853(TCP)

Encryption do not works, this server seems to be OFF

=====================================================================================================

All DNS-over-TLS servers from /etc/unbound/forward.conf has been tested.
Image
Image

Mapa
Posts: 82
Joined: August 3rd, 2017, 10:25 am

Re: unbound - forwarder in local.d - dot

Post by Mapa » November 27th, 2018, 2:32 pm

One question for understanding :
Where were the names of the already dissolved domains and the corresponding IPs stored ?
Are these as "a local self-learning" Smart DNS Root Server stored physically in a local data base ?
Or are just further kept in cache till next reboot ?

BR
Mapa

ummeegge
Community Developer
Community Developer
Posts: 4893
Joined: October 9th, 2010, 10:00 am

Re: unbound - forwarder in local.d - dot

Post by ummeegge » November 27th, 2018, 4:55 pm

Hi Mapa,
i think unbound uses the TTL from the DNS record if no 'cache-min|max-ttl' value has been defined. Some TTLs are e.g. 300 seconds so it would not make much sense to store them on disk.
You can (not only --> https://abridge2devnull.com/posts/2016/ ... e-control/ ) overview the cache with a

Code: Select all

unbound-control dump_cache
Greetings,

UE
Image
Image

Mapa
Posts: 82
Joined: August 3rd, 2017, 10:25 am

Re: unbound - forwarder in local.d - dot

Post by Mapa » November 29th, 2018, 11:13 am

Wow, thanks !
I will try that "Unbound DNS Server Cache Control" .
To see if it is possible create a "smal own root server" on IpFire and what it results .

BR
Mapa

ummeegge
Community Developer
Community Developer
Posts: 4893
Joined: October 9th, 2010, 10:00 am

Re: unbound - forwarder in local.d - dot

Post by ummeegge » December 9th, 2018, 7:27 pm

Hi all,
- rudimentary DNSSEC check (information only) has been added to initscript --> https://gitlab.com/ummeegge/dot-for-ipf ... c095b8c730 .
- DoT config has been updated --> https://gitlab.com/ummeegge/dot-for-ipf ... 4c0e648ba7 .
- Script for debugging the TLS connection of the configured servers (kdig-ing) is available --> https://gitlab.com/ummeegge/dot-for-ipf ... est_tls.sh .
- Simple DoT In- Uninstaller helper is available --> https://gitlab.com/ummeegge/dot-for-ipf ... staller.sh .
- An open question collector (beneath content description) in beginning state can be found in here -- > https://gitlab.com/ummeegge/dot-for-ipfire
- kdig (knot + deps) only for 64bit system can be found in here --> https://people.ipfire.org/~ummeegge/knot/ .

As ever, if someone see that i delete the internet in that way, please let it me know...

Some news from here.

Best,

UE
Image
Image

ummeegge
Community Developer
Community Developer
Posts: 4893
Joined: October 9th, 2010, 10:00 am

Re: unbound - DoT

Post by ummeegge » December 22nd, 2018, 3:48 pm

Hi all,
since some good conversation the next step is now to integrate DNS-over-TLS into forward.conf, local.d has been dropped so far. Another step is to integrate it also into the webuserinterface (thanks to stevee for his dnsforward.cgi by the way). The goal is to bring all DNS configurations which can be handled via CGI together into one but for testing purposes i used now for the first only one CGI to have a better overview for testing results and possible enhancements.

All files can be found in here --> https://gitlab.com/ummeegge/dot-for-ipf ... er/dot_wui , dev mailinglist conversation has been warmed up and can be found in here --> https://lists.ipfire.org/pipermail/deve ... 05001.html , build files for knot (mainly because of kdig) is here --> https://gitlab.com/ummeegge/dot-for-ipf ... uild_files located. kdig is meanwhile available in IPFires core system.

Unencrypted DNS server (UDP 53) can also be configured even unbound log fires a warning but they will be used anyways.

If someone have ideas, bugs, critics, flowers just bring it on.

Best,

UE
Image
Image

firewell
Posts: 14
Joined: May 31st, 2018, 12:36 pm

Re: unbound - DoT

Post by firewell » January 25th, 2019, 1:17 am

Thank you ummeegge for your work on this! It's great to have a CLI based option so that we can start to specify our own forwarders.conf settings.

I agree with you that it's good to invest in the future as DoT matures and begins to be more viable. Your efforts are appreciated, I am testing this on one of my LAB VMs now.

ummeegge
Community Developer
Community Developer
Posts: 4893
Joined: October 9th, 2010, 10:00 am

Re: unbound - DoT

Post by ummeegge » January 29th, 2019, 8:56 pm

Hi firewell,
this version has been meanwhile expanded to an WUI version, the CLI version is outdated. Have wrote an in- uninstaller for this, an explanation how to use it can be found in here --> viewtopic.php?f=50&p=121996#p120691 at the beginning (in EDIT section).
A short (fast made) video is also available in here --> https://people.ipfire.org/~ummeegge/vid ... vertls.mp4 . Hope this is somehow useful.

unbound initscript has been patched on Core version 127 and should include all current actual IPFire features.

UE
Image
Image

JonM
Posts: 102
Joined: August 4th, 2017, 5:49 pm
Location: US

Re: unbound - DoT

Post by JonM » January 30th, 2019, 3:31 am

excellent video! thank you!

How do I find/locate DNSs that support DoT?
EDIT: found some here in a new DoT column --> https://wiki.ipfire.org/dns/public-servers
Production:
Image

Testing Raspi 3B+:
Image

ummeegge
Community Developer
Community Developer
Posts: 4893
Joined: October 9th, 2010, 10:00 am

Re: unbound - DoT

Post by ummeegge » January 30th, 2019, 7:19 am

Hi JonM,
and thanks for your feedback. Have forgot to give a good source of DoT servers. You can find in here --> https://dnsprivacy.org/wiki/display/DP/ ... st+Servers a bunch of so called "Experimental DNS Privacy Recursive Servers" whereby this note
Note that they are experimental offerings (mainly by individuals/small organisations) with no guarantees on the lifetime of the service, service level provided. The level of logging may also vary (see the individual websites where available) - the information here about logging has not been verified.Also note that the single SPKI pins published here for many of these servers are subject to change (e.g on Certificate renewal) and should be used with care!!
should be noticed. This list is held actual to my information and i use them now since couple weeks now.

Best,

UE
Image
Image

JonM
Posts: 102
Joined: August 4th, 2017, 5:49 pm
Location: US

Re: unbound - DoT

Post by JonM » January 30th, 2019, 7:27 pm

FYI concerning the video - near 4:29 it runs test_tls.sh and it is not included with the dot_in-uninstaller.sh. I added test_tls.sh but it errors with:
kdig is required but it's not installed. Aborting.
I am guessing other pakfire add-ons or other programs are needed. I see a reference to knot above but I'm not sure how to install that from https://people.ipfire.org/~ummeegge/knot/. I've only used the pakfire installers for the IPFire box.

You may want to remove test_tls.sh from the video. Or give instructions (more video?) on how to install and use.

EDIT: I am trying this with IPFire 2.21 (armv5tel) and I only see a 64bit installer.
Production:
Image

Testing Raspi 3B+:
Image

ummeegge
Community Developer
Community Developer
Posts: 4893
Joined: October 9th, 2010, 10:00 am

Re: unbound - DoT

Post by ummeegge » February 2nd, 2019, 6:23 am

Hi,
JonM wrote:
January 30th, 2019, 7:27 pm
I added test_tls.sh but it errors with:
kdig is required but it's not installed. Aborting.
I am guessing other pakfire add-ons or other programs are needed
there is the need to debug the TLS sessions, unbound gives in verbose level 5 also some informations but delivers also a vast amount of log portions but gives also only some authentification infos.
dig is currently not able to check DNS-over-TLS and kdig (respective knot) was the best way that i found which IPFire delivers now.
JonM wrote:
January 30th, 2019, 7:27 pm
You may want to remove test_tls.sh from the video. Or give instructions (more video?) on how to install and use.
I think it is better to leave this part in the video since mostly systems are 64 bit systems and for them it might be helpful. For instructions see above.
JonM wrote:
January 30th, 2019, 7:27 pm
EDIT: I am trying this with IPFire 2.21 (armv5tel) and I only see a 64bit installer.
Yes correct, see above.

Best,

UE
Image
Image

firewell
Posts: 14
Joined: May 31st, 2018, 12:36 pm

Re: unbound - DoT

Post by firewell » February 7th, 2019, 2:43 pm

Just to continue providing feedback, I'm now using the latest DoT script with IPfire 2.21 c127. The Web UI is nice but I also don't mind editing config files to get the results. Both manually editing config files and using the WebUI are giving me the same results. I say nice work! Will the WebUI DoT changes make it to the next c128 release? Is there anything else I can help to test to make sure this goes smoothly?

I primarily use Cloudflare (1.1.1.1) and Quad9 (9.9.9.9) for my DNS-TLS testing. Both the TCPdump and connection tracker show outbound DNS lookups going on 853 and the packets look to be encrypted (no plain text DNS address visible).

Thanks again for your efforts on this Ummeegge! :)

ummeegge
Community Developer
Community Developer
Posts: 4893
Joined: October 9th, 2010, 10:00 am

Re: unbound - DoT

Post by ummeegge » February 10th, 2019, 4:19 pm

Hi firewell,
and thanks for returning with informations but also for staying ready for some testings and feedback which is the basic reason for this topic.

This development will go further with configuration options via WUI so may you have ideas for additional configure options.
Another point is, please check the stability of this configuration.
Testing some more DoT servers might also be good for a potential extension of the DNS list on IPFire.
OpenSSL-1.1.1a will come with Core 128 so TLSv1.3 is available which can also be used with unbound.
With Core update 128 Unbound comes with TCP Fast Open support so possible speed differences can happens too.

May there are more things to check, in general, feedback in here is important to get there may a nice community development out.

Some news causing kdig. Have pushed now all needed files to IPFire --> https://patchwork.ipfire.org/project/ip ... series=562 . May it comes with the next updates.

Best,

UE
Image
Image

firewell
Posts: 14
Joined: May 31st, 2018, 12:36 pm

Re: unbound - DoT

Post by firewell » February 10th, 2019, 7:00 pm

More testing feedback:
I do notice that when I set DoT servers via the WUI and I reboot IPfire, Unbound will only work in local-recursor mode sending plain text lookups out on Port 53. I have to go back to the DoT WUI, edit one of the existing DoT entries, and re-save it. This seems to restart Unbound and then applies the DoT Port 853 outbound settings and Unbound starts using only the DNS servers that I have specified in the DoT WUI.

I can duplicate this behavior on two different VMs that I have. Both are running fresh installs of IPfire x86_64 c127.

Post Reply