unbound - forwarder in local.d - dot

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

unbound - forwarder in local.d - 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 .

First try was like explained in there:

Code: Select all

echo "USE_FORWARDERS=0" > /etc/sysconfig/unbound
Create a custom forward configuration for DOT under /etc/unbound/local.d like e.g. this one:

Code: Select all

server:
  tls-cert-bundle: /etc/ssl/certs/ca-bundle.crt

forward-zone:
        name: "."
        forward-tls-upstream: yes
	forward-addr: 1.1.1.1@853
	forward-addr: 9.9.9.9@853

there was the need to execute

Code: Select all

unbound-control stop
unbound-control start
since the unbound initscript didn´t execute this.

Problems with this solution:
We tested in here --> viewtopic.php?f=6&t=21866 (sadly in german) that an

Code: Select all

/etc/init.d/unbound restart
crashed the host.cgi entries and a local resolution via host.cgi wasn´t possible anymore also if we reverse all back again. The only solution was to edit all host.cgi entries again (change|save|/or{change_back_again|save}). Also this changes didn´t survive a system reboot.
Another point was, unbound went into "local recursor" mode which wasn´t that good either.

Current solution:
Have tried a little around and rebuild the start) sequence of the initscript with a function to separate the existing functions step-by-step for testing purposes and to find the problem why 'USE_FORWARDERS=0' and the custom_configs under local.d didn´t work but do crashed parts of the system.

Until now the 'update_forwarders' seems to be the problem cause a 'USE_FORWARDERS=0' case seems to be ignored/mixed_up (and crashed some other stuff like above described). The plan was to build a function which checks also /etc/sysconfig/unbound (for USE_FORWARDERS=0) and /etc/unbound/local.d for 'forward addr' in local.d and if present, to read it out. The functions from the start) sequence (initscript) are all integrated except the 'update_forwarders' (exit 0 before) if 'USE_FORWARDERS=0' and local.d do have a forwarder config file.

Long talk, short code. Changes can be found in here --> https://git.ipfire.org/?p=people/ummeeg ... 81c0843744 .

My config under local.d look like this:

Code: Select all

server:
  tls-cert-bundle: /etc/ssl/certs/ca-bundle.crt

forward-zone:
        name: "."
  forward-tls-upstream: yes
  forward-addr: 158.64.1.29@853#kaitain.restena.lu
  forward-addr: 145.100.185.18@853#dnsovertls3.sinodun.com
  #forward-addr: 185.49.141.37@853#getdnsapi.net 
  forward-addr: 199.58.81.218@853#dns.cmrg.net
  forward-addr: 146.185.167.43@853#dot.securedns.eu
  forward-addr: 89.234.186.112@853#dns.neutopia.org
  forward-addr: 159.69.198.101@853#dot-de.blahdns.com
  forward-addr: 213.136.85.253@853#dot1.dnswarden.com
  #forward-addr: 99.192.182.100@853#opennic.tenta.io

Restart unbound with a

Code: Select all

/etc/init.d/unbound restart
looks then like this:

Code: Select all

Stopping Unbound DNS Proxy...                                                                                                        [  OK  ]
Use Custom Forwarders in local.d
. IN forward 158.64.1.29 145.100.185.15 145.100.185.18 185.49.141.37 199.58.81.218 146.185.167.43 89.234.186.112 159.69.198.101 213.136.85.253 99.192.182.100

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
Image
check via https://dnssec.vs.uni-due.de/ ) and the DNS servers configured via setup are also still presant and shown on the starting page of the WUI, if USE_FORWARDERS will be disable or if there is no config in local.d, unbound will use the old DNS servers after an restart. No "local recursor" mode with this anymore, the host entries are working and the DOT configuration survives also a system reboot or an initscript restart|stop|start .

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, i know the client handshake delivers also a 'client hello' so the domain name will be delivered in clear text but TLS1.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 so let´s invest into the future :D .

- Disabled getdnsapi.net since it delivers:

Code: Select all

Nov 29 07:58:36 ipfire-prime unbound: [6524:0] info: start of service (unbound 1.8.1).
Nov 29 07:58:36 ipfire-prime unbound: [6524:3] error: SSL_handshake syscall: Connection reset by peer
Nov 29 07:58:36 ipfire-prime unbound: [6524:3] error: SSL_handshake syscall: Connection reset by peer
Disabled also opennic.tenta.io since it delivers:

Code: Select all

Nov 29 08:00:40 ipfire-prime unbound: [7767:0] info: start of service (unbound 1.8.1).
Nov 29 08:00:41 ipfire-prime unbound: [7767:3] info: generate keytag query _ta-4a5c-4f66. NULL IN
Nov 29 08:00:41 ipfire-prime unbound: [7767:3] info: failed to prime trust anchor -- DNSKEY rrset is not secure . DNSKEY IN
Nov 29 08:00:41 ipfire-prime unbound: [7767:3] info: failed to prime trust anchor -- DNSKEY rrset is not secure . DNSKEY IN
- DNS Query Name Minimisation to Improve Privacy RFC 7816 --> https://tools.ietf.org/html/rfc7816 --> https://nlnetlabs.nl/downloads/presenta ... oarc24.pdf .
Even "DNS Query Name Minimisation" has been enabled by default with 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 :("

have added now the following directives

Code: Select all

  qname-minimisation-strict: yes
  harden-below-nxdomain: yes
to my custom forward configuration which looks now like this

Code: Select all

server:
  tls-cert-bundle: /etc/ssl/certs/ca-bundle.crt
  qname-minimisation-strict: yes
  harden-below-nxdomain: yes

forward-zone:
        name: "."
  forward-tls-upstream: yes
  forward-addr: 158.64.1.29@853#kaitain.restena.lu
  forward-addr: 145.100.185.18@853#dnsovertls3.sinodun.com
  forward-addr: 199.58.81.218@853#dns.cmrg.net
  forward-addr: 146.185.167.43@853#dot.securedns.eu
  forward-addr: 89.234.186.112@853#dns.neutopia.org
  forward-addr: 159.69.198.101@853#dot-de.blahdns.com
  forward-addr: 213.136.85.253@853#dot1.dnswarden.com

by executing the dig command from above i get the following results:

Code: Select all

$ dig txt qnamemintest.internet.nl +short
a.b.qnamemin-test.internet.nl.
"HOORAY - QNAME minimisation is enabled on your resolver :)!"
so it seems that the QNAME minimization works now.

- If someone is interested in testing tools, in here --> https://people.ipfire.org/~ummeegge/ldns/ an unpatched (--> https://tools.ietf.org/html/draft-ietf- ... ection-8.2 is not included) ldns (drill) version can be found. And in here --> a patched TCPick version (Debian Patch series) can be found.

Current actual development incl. small in- uninstall helper can be found in here --> https://gitlab.com/ummeegge/dot-for-ipfire
Image
Image
Image

Mapa
Posts: 55
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: 4676
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
Image

Mapa
Posts: 55
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: 4676
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
Image

Post Reply

Who is online

Users browsing this forum: No registered users and 5 guests