unbound - DoT

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

Re: unbound - DoT

Post by ummeegge » February 23rd, 2019, 4:57 am

Thank you both for your feedback.
firewell wrote:
February 22nd, 2019, 12:08 am
Looking forward to C128 release!
In Core 128 is an unbound initscript update, even you already use it (is included in the last update from here) you will need to play back the patched unbound version for DoT. This can be done via in- uninstaller.
But beside this, some more features will arrive with Core 128 which can be used for DoT either. OpenSSL-1.1.1a and kdig might bring some interesting things with, also some further tests can then be done.

Anyways, thank you both for being active in here :) .

Best,

UE
Image
Image

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

Re: unbound - DoT

Post by ummeegge » March 12th, 2019, 6:00 pm

Hi all,
have already uploaded the changes for Core 129 --> https://git.ipfire.org/?p=ipfire-2.x.gi ... ce542d0814 but also the en.pl is on Core 129 state. I know Core 128 is already in testing state so Core 129 is a little longer away but the changes needs also a patched dnsforward.cgi so they can currently not be used. Only wanted to inform you if someone uses the installation script and find some updates.

As always, if the update makes DoT unusable, just use the script from the starting topic to get the actual changes including the DoT functionality.

Greetings,

UE
Image
Image

User avatar
FischerM
Community Developer
Community Developer
Posts: 1021
Joined: November 2nd, 2011, 12:28 pm

Re: unbound - DoT

Post by FischerM » March 12th, 2019, 7:36 pm

Hi,

FYI:

I'm testing 'unbound 1.9.1' since a few minutes - seems to run without problems.

Best,
Matthias

EDIT:
Changelog => https://nlnetlabs.nl/pipermail/unbound- ... 11415.html

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

Re: unbound - DoT

Post by ummeegge » March 13th, 2019, 5:17 pm

Heyho Matthias,
yes have build it also but also the new knot version -->

Code: Select all

Version 1.9.1
linked libs: libevent 2.1.8-stable (it uses epoll), OpenSSL 1.1.1b  26 Feb 2019
linked modules: dns64 respip validator iterator

Code: Select all

kdig (Knot DNS), version 2.8.0
and it runs nice but also fast but a shady downside appears currently. kdig do not displays TLSv1.3 :( . Did some tests to check if there is a problem with unbound causing the new OpenSSL lib so i checked with tshark a little around -->

Code: Select all

$ tshark -i red0 port 853 | grep TLSv1.3
Running as user "root" and group "root". This could be dangerous.
Capturing on 'red0'
    5 0.023727828     9.9.9.10 → 192.168.32.234  TLSv1.3 2946 Server Hello, Change Cipher Spec, Application Data, Application Data
    7 0.023975963     9.9.9.10 → 192.168.32.234  TLSv1.3 194 Application Data, Application Data
    9 0.040179299  192.168.32.234 → 9.9.9.10     TLSv1.3 146 Change Cipher Spec, Application Data
   10 0.050384404     9.9.9.10 → 192.168.32.234  TLSv1.3 145 Application Data
   11 0.050552114  192.168.32.234 → 9.9.9.10     TLSv1.3 145 Application Data
   12 0.050615542     9.9.9.10 → 192.168.32.234  TLSv1.3 145 Application Data
   13 0.063588209     9.9.9.10 → 192.168.32.234  TLSv1.3 299 Application Data
   16 0.064821222  192.168.32.234 → 9.9.9.10     TLSv1.3 90 Application Data
   18 0.075265210     9.9.9.10 → 192.168.32.234  TLSv1.3 90 Application Data
44    61 0.322884305      8.8.8.8 → 192.168.32.234  TLSv1.3 2920 Server Hello, Change Cipher Spec, Application Data
   63 0.328614830  192.168.32.234 → 8.8.8.8      TLSv1.3 130 Change Cipher Spec, Application Data
73    65 0.339647495  192.168.32.234 → 8.8.8.8      TLSv1.3 133 Application Data
   66 0.346933762      8.8.8.8 → 192.168.32.234  TLSv1.3 556 Application Data
   68 0.358089364      8.8.8.8 → 192.168.32.234  TLSv1.3 854 Application Data
   70 0.359134888  192.168.32.234 → 8.8.8.8      TLSv1.3 90 Application Data
   95 1.062951917      8.8.8.8 → 192.168.32.234  TLSv1.3 2920 Server Hello, Change Cipher Spec, Application Data
   97 1.068785290  192.168.32.234 → 8.8.8.8      TLSv1.3 130 Change Cipher Spec, Application Data
   99 1.078971774  192.168.32.234 → 8.8.8.8      TLSv1.3 155 Application Data
  101 1.088492227      8.8.8.8 → 192.168.32.234  TLSv1.3 556 Application Data
135   102 1.114922839      8.8.8.8 → 192.168.32.234  TLSv1.3 324 Application Data
  105 1.116241577  192.168.32.234 → 8.8.8.8      TLSv1.3 90 Application Data
  154 2.045863267 146.185.167.43 → 192.168.32.234  TLSv1.3 4162 Server Hello, Change Cipher Spec, Application Data
  156 2.047959439 146.185.167.43 → 192.168.32.234  TLSv1.3 1637 Application Data, Application Data, Application Data
  158 2.052284540  192.168.32.234 → 146.185.167.43 TLSv1.3 130 Change Cipher Spec, Application Data
  159 2.071599482 146.185.167.43 → 192.168.32.234  TLSv1.3 321 Application Data
  160 2.071772008  192.168.32.234 → 146.185.167.43 TLSv1.3 129 Application Data
  161 2.071830179 146.185.167.43 → 192.168.32.234  TLSv1.3 321 Application Data
  162 2.094840592 146.185.167.43 → 192.168.32.234  TLSv1.3 838 Application Data
  164 2.096341406  192.168.32.234 → 146.185.167.43 TLSv1.3 90 Application Data
  166 2.115308743 146.185.167.43 → 192.168.32.234  TLSv1.3 90 Application Data
  177 2.200459058      8.8.8.8 → 192.168.32.234  TLSv1.3 2920 Server Hello, Change Cipher Spec, Application Data
  179 2.205777764  192.168.32.234 → 8.8.8.8      TLSv1.3 130 Change Cipher Spec, Application Data
  181 2.217456444  192.168.32.234 → 8.8.8.8      TLSv1.3 146 Application Data
  182 2.224987929      8.8.8.8 → 192.168.32.234  TLSv1.3 556 Application Data
  184 2.247730101      8.8.8.8 → 192.168.32.234  TLSv1.3 264 Application Data
  187 2.248978959  192.168.32.234 → 8.8.8.8      TLSv1.3 90 Application Data
206   214 2.407554122      8.8.4.4 → 192.168.32.234  TLSv1.3 2920 Server Hello, Change Cipher Spec, Application Data
  216 2.412944312  192.168.32.234 → 8.8.4.4      TLSv1.3 130 Change Cipher Spec, Application Data
  218 2.424086009  192.168.32.234 → 8.8.4.4      TLSv1.3 134 Application Data
  219 2.431382461      8.8.4.4 → 192.168.32.234  TLSv1.3 556 Application Data
  221 2.443915127      8.8.4.4 → 192.168.32.234  TLSv1.3 853 Application Data
  224 2.446099204  192.168.32.234 → 8.8.4.4      TLSv1.3 90 Application Data
  231 2.469316871     9.9.9.10 → 192.168.32.234  TLSv1.3 2946 Server Hello, Change Cipher Spec, Application Data, Application Data
  233 2.469563603     9.9.9.10 → 192.168.32.234  TLSv1.3 195 Application Data, Application Data
  235 2.486038071  192.168.32.234 → 9.9.9.10     TLSv1.3 146 Change Cipher Spec, Application Data
  236 2.496340254     9.9.9.10 → 192.168.32.234  TLSv1.3 145 Application Data
  237 2.496502445  192.168.32.234 → 9.9.9.10     TLSv1.3 132 Application Data
  238 2.496564881     9.9.9.10 → 192.168.32.234  TLSv1.3 145 Application Data
  239 2.507635120     9.9.9.10 → 192.168.32.234  TLSv1.3 853 Application Data
272   241 2.508892995  192.168.32.234 → 9.9.9.10     TLSv1.3 90 Application Data
  243 2.519706157     9.9.9.10 → 192.168.32.234  TLSv1.3 90 Application Data
  277 3.558888948 146.185.167.43 → 192.168.32.234  TLSv1.3 4162 Server Hello, Change Cipher Spec, Application Data
  279 3.560108086 146.185.167.43 → 192.168.32.234  TLSv1.3 1637 Application Data, Application Data, Application Data
  281 3.564520651  192.168.32.234 → 146.185.167.43 TLSv1.3 130 Change Cipher Spec, Application Data
  282 3.587611110 146.185.167.43 → 192.168.32.234  TLSv1.3 321 Application Data
  283 3.587787090  192.168.32.234 → 146.185.167.43 TLSv1.3 137 Application Data
  284 3.587847135 146.185.167.43 → 192.168.32.234  TLSv1.3 321 Application Data
  285 3.614210453 146.185.167.43 → 192.168.32.234  TLSv1.3 195 Application Data
  288 3.615378143  192.168.32.234 → 146.185.167.43 TLSv1.3 90 Application Data
  293 3.639069570 146.185.167.43 → 192.168.32.234  TLSv1.3 90 Application Data
  340 3.944165284 146.185.167.43 → 192.168.32.234  TLSv1.3 4162 Server Hello, Change Cipher Spec, Application Data
  342 3.946512975 146.185.167.43 → 192.168.32.234  TLSv1.3 1637 Application Data, Application Data, Application Data
348   344 3.949957038  192.168.32.234 → 146.185.167.43 TLSv1.3 130 Change Cipher Spec, Application Data
  345 3.969412952 146.185.167.43 → 192.168.32.234  TLSv1.3 321 Application Data

...
and all looked good but kdig thinks in other ways (example with securedns.eu):

Code: Select all

;; DEBUG: Querying for owner(www.isoc.org.), class(1), type(1), server(146.185.167.43), port(853), protocol(TCP)
;; DEBUG: TLS, imported 135 certificates from '/etc/ssl/certs/ca-bundle.crt'
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, CN=securedns.eu
;; DEBUG:      SHA-256 PIN: h3mufC43MEqRD6uE4lz6gAgULZ5/riqH/E+U+jE3H8g=
;; DEBUG:  #2, C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
;; DEBUG:      SHA-256 PIN: YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
;; DEBUG:  #3, CN=securedns.eu
;; DEBUG:      SHA-256 PIN: h3mufC43MEqRD6uE4lz6gAgULZ5/riqH/E+U+jE3H8g=
;; DEBUG:  #4, C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
;; DEBUG:      SHA-256 PIN: YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted. 
;; TLS session (TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 52135
;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 2; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: do; UDP size: 4096 B; ext-rcode: NOERROR
;; PADDING: 239 B

;; QUESTION SECTION:
;; www.isoc.org.       		IN	A

;; ANSWER SECTION:
www.isoc.org.       	300	IN	A	46.43.36.222
www.isoc.org.       	300	IN	RRSIG	A 7 3 300 20190327085001 20190313085001 54512 isoc.org. YRI3Oko8e2R6ob3orLxmJK2qZfrjDY/GkCCVEzZb2FNh5zZc1ZdBUnW3yYVlsT87gO6hpaQJp0vfRmDAPmpVRyyv7p2z4XfQlf401lluVFnZSs8+AbBRGZUSI6TjDckjcz/6d3jrOKHjytkMjCEF5yrt+XgjT+7HrGjOxzud00E=

;; Received 468 B
;; Time 2019-03-13 18:03:20 CET
;; From 146.185.167.43@853(TCP) in 37.8 ms

Exit status: 0

same with Quad9, Cloudflare, Google, ... :( . If someone is too lazy to tcpdump it, have build tshark (only for 64 bit) which can be found in here --> https://people.ipfire.org/~ummeegge/tshark/ .

So am happy that OpenSSL-1.1.1 works but unhappy with kdig.

So what, this will also be cleared.

Best,

UE
Image
Image

User avatar
FischerM
Community Developer
Community Developer
Posts: 1021
Joined: November 2nd, 2011, 12:28 pm

Re: unbound - DoT

Post by FischerM » March 13th, 2019, 7:33 pm

Hi,

All confirmed for Core 127 with 'unbound 1.9.1' and 'knot 2.8.0'. ::)

We'll see...

Best,
Matthias

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

Re: unbound - DoT

Post by ummeegge » April 19th, 2019, 7:49 am

Hi all,
update for Core 131 is meanwhile up. Changes from en.pl and unbound initscript are integrated. Update as always via in- uninstaller --> viewtopic.php?f=50&t=21954#p120691 .

Best,

UE
Image
Image

tikok974
Posts: 77
Joined: January 3rd, 2017, 9:53 am

Re: unbound - DoT

Post by tikok974 » May 6th, 2019, 9:08 am

Hi Ummeegge,

I have the Ipfire Squid proxy in transparent mode. I currently have a HTTPS filtering problem with Ipfire on my network, it works on some browsers and not on others. Also, filtering of mobile phones or tablets is not automatic:

See my post on the forum here: viewtopic.php?f=27&t=20478&start=15#p122718

I have chosen as a solution to go through a DNS filtering service in order to solve the problem but this brings another one because the DNS filtering service I use (DNSfilter) does not accept the DNSSEC activation required by the Unbound service on Ipfire.

So I was advised to use your patch to fix my problem. Will your patch actually allow me to force Unbound to accept DNSfilter DNS ?
I currently have the core 130 of Ipfire...does your patch work on this latest release of Ipfire ?

Thank you

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

Re: unbound - DoT

Post by ummeegge » May 6th, 2019, 10:39 am

Hi tikok974,
OK we have two parts in the answer :) .
tikok974 wrote:
May 6th, 2019, 9:08 am
I have the Ipfire Squid proxy in transparent mode. I currently have a HTTPS filtering problem with Ipfire on my network, it works on some browsers and not on others. Also, filtering of mobile phones or tablets is not automatic:
The OT one: Do you know this topic --> viewtopic.php?f=17&t=18667 ? I did not use the HTTPS filtering cause this could breaks a lot also it might be illegal under specific circumstances in some countries but it seems that armageddon keeps this up-to-date.
tikok974 wrote:
May 6th, 2019, 9:08 am
So I was advised to use your patch to fix my problem. Will your patch actually allow me to force Unbound to accept DNSfilter DNS ?
We are here really in a testing scenario but i try to keep everything up-to-date as good as possible but the life in this topic depends on feedback if something goes wrong, so you have been warned ;) ! Now to your question. It seems that DNSFilter do provides DNS-over-TLS --> https://docs.dnsfilter.com/docs/dns-over-tls (reading the docs it seems that they provide also TLSv1.3 which IPFire does too and which is good) so use their settings from the doc if you have decided to use this patch. Another thing is, if DoT servers are in usage, this patch ignores the 'update_forwarders' function from unbound init which might possibly causes your problems but i am also not really sure about ?! This needs to be tested from your side then. It is also possible to use unencrypted connections with this patch but i would not use it in that way.
You can find in here --> viewtopic.php?f=50&t=21954#p120691 a more detailed description including the in- uninstaller + a little video howto in- uninstall it but also to test the environment.
tikok974 wrote:
May 6th, 2019, 9:08 am
I currently have the core 130 of Ipfire...does your patch work on this latest release of Ipfire ?
This patch is nearly Core 131 ready --> viewtopic.php?f=50&t=21954&start=30#p123875 so yes, it should include Core 130 completely and a little more. Will update this patch if things will change for Core 131 which is currently in testing but again, feedback if something does not work (but also feedback in general) and surely also own implementation ideas/development/donations keeps this here alive.

Best,

UE

EDIT(s):
- Made a fast test which seems to work:
You can check dns1 from DNSFilter with a -->

Code: Select all

kdig -d @103.247.36.36 +dnssec +tls-ca=/etc/ssl/certs/ca-bundle.crt +tls-host=dns1.dnsfilter.com www.isoc.org

Code: Select all

;; DEBUG: Querying for owner(www.isoc.org.), class(1), type(1), server(103.247.36.36), port(853), protocol(TCP)
;; DEBUG: TLS, imported 135 certificates from '/etc/ssl/certs/ca-bundle.crt'
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, CN=dns1.dnsfilter.com
;; DEBUG:      SHA-256 PIN: WaUGApvhk1u5OejuTRttQhX5c1X89yyVtBs9TTiv7/U=
;; DEBUG:  #2, C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
;; DEBUG:      SHA-256 PIN: YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted. 
;; TLS session (TLS1.2)-(ECDHE-X25519)-(RSA-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 671
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0

;; QUESTION SECTION:
;; www.isoc.org.       		IN	A

;; ANSWER SECTION:
www.isoc.org.       	30	IN	A	45.32.196.109

;; Received 46 B
;; Time 2019-05-06 12:52:05 CEST
;; From 103.247.36.36@853(TCP) in 14.0 ms

Exit status: 0

whereby DNSSEC does not work (no ad flag) but probably you know about this ;) :

Code: Select all

From Host: dns1.dnsfilter.com ---- With IP: 103.247.36.36 ---- Date: Mon May  6 12:52:48 CEST 2019

in 12.6 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 do NOT works and is NOT OK
Also, even they use the X25519 curve which is nice, they do not use TLSv1.3, double checked it with tshark -->

Code: Select all

 1020 5.967802648 192.168.123.234 ? 103.247.36.36 TLSv1.2 151 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
 1021 5.981601680 103.247.36.36 ? 192.168.123.234 TLSv1.2 244 New Session Ticket, Change Cipher Spec, Encrypted Handshake Message
 1022 5.982061096 192.168.123.234 ? 103.247.36.36 TLSv1.2 138 Application Data
 1023 5.995524053 103.247.36.36 ? 192.168.123.234 TLSv1.2 89 Application Data
 1024 5.995630840 103.247.36.36 ? 192.168.123.234 TLSv1.2 125 Application Data
so if you pay for this, it might be an idea to ask for the outlined 'Implementation Details' since OpenSSL-1.1.1 is already released.

- Another point is, they would enable "TCP Fast Open" for DoT if Golang-1.11 is out, from my experience this won´t work cause TFO with DoT depends on an appropriate working OpenSSL not on Golang --> viewtopic.php?f=50&t=21954&start=15#p122372 but may they do use magic which i don´t know :D .
Image
Image

tikok974
Posts: 77
Joined: January 3rd, 2017, 9:53 am

Re: unbound - DoT

Post by tikok974 » May 6th, 2019, 1:09 pm

Re,

Thank you very much for the speed of your answer and the many elements provided.
I will seriously study all this and I will come back to this post to share my experience.

Many thanks

tikok974
Posts: 77
Joined: January 3rd, 2017, 9:53 am

Re: unbound - DoT

Post by tikok974 » May 10th, 2019, 9:29 am

Hi Ummeegge,

I tested your patch (https://gitlab.com/ummeegge/dot-for-ipfire) today.
I have a few questions.
I followed DNSFilter's explanation here: https://docs.dnsfilter.com/docs/dns-over-tls and I added the settings like this to your "/etc/unbound/local.d/dot.conf" file:

Code: Select all

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

forward-zone:
        name: "."
  forward-tls-upstream: yes
  #### For DNSFilter ############
  forward-addr: 103.247.36.36@853
  forward-addr: 103.247.37.37@853
  ################################
  forward-addr: 158.64.1.29@853#kaitain.restena.lu
  forward-addr: 145.100.185.18@853#dnsovertls3.sinodun.com
  forward-addr: 145.100.185.17@853#dnsovertls2.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: 108.61.201.119@853#dns.jp.blahdns.com
  forward-addr: 89.233.43.71@853#unicast.censurfridns.dk
  forward-addr: 99.192.182.200@853#iana.tenta.io
Then, once Unbound restarted, I did a test and when I try to go to a prohibited site on a HTTPS site from my mobile phone via Wifi (not the same network as LAN), obviously the requests do not go through DNSfilter's DNS because I can see these sites. On the other hand, if I try from my computer (Ubuntu with Firefox) on the LAN, HTTPS requests are filtered...this is exactly the problem I had before :(

To solve Ipfire's HTTPS filtering problem, I want to do a DNS filtering and so...let my DNS requests be filtered by DNSFilter but here...it doesn't work.
Only the Ryan Jaeb patch found here: https://gitlab.com/snippets/1706804 ...works in all cases...except that I still have errors that appear in the "message" logs as mentioned HERE: viewtopic.php?f=27&t=20478&start=15#p122718

Why do you think, with your patch, not all requests go through DNSfilter's DNS ?
I also remind you that I am in "transparent proxy" mode on Ipfire.

I don't have enough development knowledge to understand the difference between your patch and Ryan Jaeb's :(
Many thanks

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

Re: unbound - DoT

Post by ummeegge » May 10th, 2019, 11:34 am

Hi tikok974,
it seems that you completely missed the regular setup which might possibly be a problem of the grown topic in here and some descriptions are not that clear separated. The current development does not use local.d anymore all is meanwhile located under the already existing /etc/unbound/forward.conf example -->

Code: Select all

$ cat /etc/unbound/forward.conf 
# 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: 46.182.19.48@853#dns2.digitalcourage.de
    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

. Also, there is a webuserinterface for DoT available -->
Image
which makes everything for you...
As mentioned above, a little video --> https://people.ipfire.org/~ummeegge/vid ... vertls.mp4 howto in- uninstall can also be found in the starting topic where the setup should be better explained, there are also some debugging ideas included (above too). Please check this out again.

Best,

UE

EDIT(s):
tikok974 wrote:
May 10th, 2019, 9:29 am
I don't have enough development knowledge to understand the difference between your patch and Ryan Jaeb's :(
As far as i can see is this a patch in 'update_forwarders' function so servers which do not provides DNSSEC will be accepted. My patch ignores this function completely if DoT servers has been configured.
tikok974 wrote:
May 10th, 2019, 9:29 am
I also remind you that I am in "transparent proxy" mode on Ipfire.
This makes no difference and should be no problem at all.
tikok974 wrote:
May 10th, 2019, 9:29 am

Why do you think, with your patch, not all requests go through DNSfilter's DNS ?
I don´t think that where does this believe comes from ?



-Have updated the starting topic to prevent wrong understanding causing of too much old informations.
Image
Image

tikok974
Posts: 77
Joined: January 3rd, 2017, 9:53 am

Re: unbound - DoT

Post by tikok974 » May 13th, 2019, 9:03 am

Hi ummeegge,

Many thanks for your reply.
Oh, yeah... I didn't get the right script on Github... I got this one: https://gitlab.com/ummeegge/dot-for-ipf ... staller.sh
...and apparently, in this one there is no webuser interface for DoT.

Now, I have the webuserinterface for DoT with this link and script: https://gitlab.com/ummeegge/dot-for-ipf ... staller.sh.
I put the DNS of DNSfilter but it doesn't work with their DNS... I no longer have a name resolution when I enable them and so:(
I did a test with Cloudflare's DNS and it works.

I don't understand why DNSFilter's DNS doesn't work !
The only difference is that it says to put "ssl-upstream: yes" as a parameter (see: https://docs.dnsfilter.com/docs/dns-over-tls)
when adding DNSfilter DNS via webuserinterface for DoT, this parameter does not appear in the configuration of the "forward.conf" file.

You can see below the configuration that appears after setting the DNS of DNSfilter:

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: 103.247.36.36@853#dns1.dnsfilter.com
Is something wrong ?
Many thanks

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

Re: unbound - DoT

Post by ummeegge » May 14th, 2019, 5:09 am

Hi tikok974,
tikok974 wrote:
May 13th, 2019, 9:03 am
I don't understand why DNSFilter's DNS doesn't work !
The only difference is that it says to put "ssl-upstream: yes" as a parameter (see: https://docs.dnsfilter.com/docs/dns-over-tls)
when adding DNSfilter DNS via webuserinterface for DoT, this parameter does not appear in the configuration of the "forward.conf" file
ssl-upstream is a alternate syntax for tls-upstream, 'forward-tls-upstream' is used for specific forward zones and is widely used out there --> https://nlnetlabs.nl/documentation/unbo ... ound.conf/ but if you want to check this, just edit /etc/unbound/forward.conf and restart unbound via commandline

Code: Select all

/etc/init.d/unbound restart
and don´t use the DoT WUI for this since it would overwrite your changes.
tikok974 wrote:
May 13th, 2019, 9:03 am
I put the DNS of DNSfilter but it doesn't work with their DNS... I no longer have a name resolution when I enable them and so:(
I did a test with Cloudflare's DNS and it works.
I have several DoT servers configured and added also DNSFilter for a fast test (like above explained) but i get only in Firefox the following answer:
Image
whereby e.g. Chromium do not shows there anything. The unbound log shows:

Code: Select all

May 13 22:25:26 ipfire unbound: [3246:3] info: validator operate: query detectportal.firefox.com. A IN
which seems to trigger the warning. At the top of Firefox i can click a register button wich leads me to:
Image
so DNSFilter do response here.
If you checkout now their troubleshooting page --> https://docs.dnsfilter.com/docs/not-connected you can find there some possible cases what can be wrong and how you can debug it. Have also seen there a hint which includes your concerns causing transparent proxying but in my opinion this should be then a possible ISP thing. Have Squid here also active and no problems with it and DoT.
tikok974 wrote:
May 13th, 2019, 9:03 am
Is something wrong ?
~20 DoT servers are running here and all operate with this configuration without problems.

Best,

UE
Image
Image

tikok974
Posts: 77
Joined: January 3rd, 2017, 9:53 am

Re: unbound - DoT

Post by tikok974 » May 14th, 2019, 1:30 pm

Hi Ummeegge,

Thank you for your tests and your answers ;)
It doesn't seem easy to find out where the problem comes from :(
While waiting to find a solution, I will continue to use Ryan Jaeb patch found here: https://gitlab.com/snippets/1706804 ...works in all cases...except that I still have errors that appear in the "message" logs as mentioned HERE: viewtopic.php?f=27&t=20478&start=15#p122718
Also, I'll check with DNSfilter support to see if they can help me.

If I uninstall your patch, does it also delete the webuserinterface for DoT in the Ipfire interface ?
thank you

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

Re: unbound - DoT

Post by ummeegge » May 14th, 2019, 2:33 pm

Hi,
tikok974 wrote:
May 14th, 2019, 1:30 pm
If I uninstall your patch, does it also delete the webuserinterface for DoT in the Ipfire interface ?
Yes.
tikok974 wrote:
May 14th, 2019, 1:30 pm
Also, I'll check with DNSfilter support to see if they can help me.
Wish you all the best.

Greetings,

UE
Image
Image

Post Reply