From mboxrd@z Thu Jan 1 00:00:00 1970
From: ummeegge <ummeegge@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [Fwd: Re: request for info: unbound via https / tls]
Date: Wed, 12 Dec 2018 18:44:12 +0100
Message-ID: <c0610d61e7dd43d8f623fb08c1b9f916cacec308.camel@ipfire.org>
In-Reply-To: <857F805E-CCD0-41B0-AEA6-DCE1AF4F425A@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2652220014574964224=="
List-Id: <development.lists.ipfire.org>
--===============2652220014574964224==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Hi Michael,
Am Mittwoch, den 12.12.2018, 15:25 +0000 schrieb Michael Tremer:
> Hey,
>=20
> > On 12 Dec 2018, at 13:42, ummeegge <ummeegge(a)ipfire.org> wrote:
> >=20
> > Hi Michael,
> >=20
> > Am Dienstag, den 11.12.2018, 19:54 +0000 schrieb Michael Tremer:
> > > Hey,
> > >=20
> > > On 11 Dec 2018, at 19:43, ummeegge <ummeegge(a)ipfire.org> wrote:
> > > >=20
> > > > Hi Michael,
> > > > tried that now with this one -->
> > > >=20
> >=20
> >=20
https://people.ipfire.org/~ummeegge/screenshoots/dns-over-tls_wui.png
> > >=20
> > > This looks good, but under no circumstances should there be
> > > *another*
> > > place where to configure DNS servers.
> >=20
> > Sure. I need to check for myself how this can be accomplished so i
> > take
> > it step-by-step and with a clear CGI it is simply easier for me.
> >=20
> >=20
> > > We already have three. They need to be unified to one.
> >=20
> > You mean dns.cgi and dnsforward.cgi ?
>=20
> No. We have the following places where users can configure their DNS
> servers:
>=20
> For RED =3D STATIC: setup
>=20
> For RED =3D DHCP: dns.cgi
>=20
> For RED =3D PPP: The PPP profile
>=20
OK i see. This is also a problem for me here to test or to check
further since RED is here static only.
> It can be argued that it makes sense to have different DNS servers in
> place for each PPP profile (I do not think that this has any users at
> all. Either you use your ISP=E2=80=99s DNS or not).
>=20
> But overall it is confusing and also quite complicated in the code
> that we are reading the DNS servers from so many different places all
> the time. This needs to be simplified. There is a ticket for it since
> 2015:
>=20
> https://bugzilla.ipfire.org/show_bug.cgi?id=3D10886
I think this topic might be a good reason to change this but as
mentioned am not able to do this here.
>=20
> >=20
> > >=20
> > > >=20
> > > > ... the HTML formatting kills me :D ...
> > > >=20
> > > > and it looks now good:
> > > >=20
> > > > $ kdig -d @81.3.27.54 +tls-ca=3D/etc/ssl/certs/ca-bundle.crt
> > > > +tls-
> > > > host=3Drec1.dns.lightningwirelabs.com google.com
> > > > ;; DEBUG: Querying for owner(google.com.), class(1), type(1),
> > > > server(81.3.27.54), port(853), protocol(TCP)
> > > > ;; DEBUG: TLS, imported 129 certificates from
> > > > '/etc/ssl/certs/ca-
> > > > bundle.crt'
> > > > ;; DEBUG: TLS, received certificate hierarchy:
> > > > ;; DEBUG: #1, CN=3Drec1.dns.lightningwirelabs.com
> > > > ;; DEBUG: SHA-256 PIN:
> > > > pOvVkJSj6rWNPM0vR3hoJr/21kZI6TfImhowIEdcEUQ=3D
> > > > ;; DEBUG: #2, C=3DUS,O=3DLet's Encrypt,CN=3DLet's Encrypt Authority
> > > > X3
> > > > ;; DEBUG: SHA-256 PIN:
> > > > YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=3D
> > > > ;; DEBUG: TLS, skipping certificate PIN check
> > > > ;; DEBUG: TLS, The certificate is trusted.=20
> > > > ;; TLS session (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(CHACHA20-
> > > > POLY1305)
> > > > ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 1349
> > > > ;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0;
> > > > ADDITIONAL:
> > > > 1
> > > >=20
> > > > ;; EDNS PSEUDOSECTION:
> > > > ;; Version: 0; flags: ; UDP size: 4096 B; ext-rcode: NOERROR
> > > >=20
> > > > ;; QUESTION SECTION:
> > > > ;; google.com. IN A
> > > >=20
> > > > ;; ANSWER SECTION:
> > > > google.com. 151 IN A 216.58.208.46
> > > >=20
> > > > ;; Received 55 B
> > > > ;; Time 2018-12-11 20:30:29 CET
> > > > ;; From 81.3.27.54(a)853(TCP) in 25.2 ms
> > >=20
> > > 25ms is actually quite good!
> >=20
> > Yes, i think so.
> >=20
> > >=20
> > > >=20
> > > > Great, will update my dot.conf.=20
> > > >=20
> > > > As a beneath one, try it currently with a seperat CGI to have a
> > > > better overview.=20
> > > > Patched now as you suggested the 'write_forward_conf()'
> > > > function,
> > > > needed to disable=20
> > > > nevertheless update_forwarder() function in initscript if
> > > > forward.conf should be used
> > > > ... (there is more)
> > > >=20
> > >=20
> > > As we talked about before, I think that we can skip the DNSSEC
> > > tests
> > > entirely. They are more damaging than anything else.=20
> >=20
> > Yes indeed, i think update_forwarders disables also any forwarder
> > via
> > unbound-control.
>=20
> Disables them? It is meant to overwrite them with the current DNS
> servers without restarting unbound.
I meant the update_forwarder() function -->
https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dblob;f=3Dsrc/initscripts/syste=
m/unbound;h=3Dcc46c33c9425cc85d95b1d7412a9db3e146fea4b;hb=3Drefs/heads/next#l=
154
as far i understand 'unbound-control -q forward off' .
But also for write_forward_conf() where i integrated DoT needed a restart
of unbound as far as i can see/tested since we need different unbound.conf
directives:
server:
tls-cert-bundle: /etc/ssl/certs/ca-bundle.crt
forward-zone:
forward-tls-upstream: yes
unbound needed to read out the config file again. The first version
started DoT via 'unbound-control start' but i couldn=C2=B4t manage this in
this version?!
>=20
> >=20
> > > That means that we should probably be looking at having a switch
> > > somewhere that enables DNS-over-TLS first and then all configured
> > > name servers are just used without further tests.
> >=20
> > Have tried it now in this way -->
> >=20
https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dblob;f=3Dsrc/initscripts/syste=
m/unbound;h=3Dcc46c33c9425cc85d95b1d7412a9db3e146fea4b;hb=3Drefs/heads/next#l=
154
> > . If unbound init finds an 'on' (enabled) in tlsconfig (which will
> > be produced by CGI),
> > it doesn=C2=B4t execute update_forwarders. Am currently not sure if we
> > need possibly
> > the same for dnsforward config. Have tested it with a dummy entry
> > but an
> > 'unbound-control list_forwarders' shows nothing.
> > If there is no entry or everything is 'off' unbound uses the old=20
> > DNS servers configured via setup.
>=20
> In case of =E2=80=9Coff=E2=80=9D, unbound is supposed to run in recursor mo=
de.
Haven=C2=B4t experienced this here. Did You ? unbound switched only back to
the initially configured DNS servers if "off" or not presant.
>=20
> > > In the default configuration that cannot be the case because of
> > > the
> > > problems we are trying to overcome by this script.
> >=20
> > Isn=C2=B4t forward.conf not a good place for this ?
>=20
> For what exactly?
For extending unbound.conf .
>=20
> > >=20
> > > But Erik, please let=E2=80=99s find a strategy first because everything
> > > is
> > > being implemented.=20
> >=20
> > Am happy with this but i really need to know first what=C2=B4s happen in
> > the
> > existing stuff, also i need to test for myself which ways may be
> > possible to overcome side affects. I need there also some new
> > knowledge
> > causing the whole DNS/unbound thing but also insides how all that
> > has
> > already been implemented.
> >=20
> > In here -->=20
> >=20
https://git.ipfire.org/?p=3Dpeople/ummeegge/ipfire-2.x.git;a=3Dcommit;h=3D90e=
45d849e5fa185e4dcf83844e85d68474a09f5
> > a first and also better tested version of DoT can be found whereby
> > i am=20
> > happy if someone comes around for some testings/enhancements.
> >=20
> > Merging all DNS CGI=C2=B4s can be one of the following parts (not sure
> > if i=C2=B4 am the right one for this)
> > but i need a working solution to see how the system is in harmony
> > with all that.
> > Also the dnsforwarding.cgi is in my humble opinion currently not
> > working
> > or i did there really something wrong.
> >=20
> > What strategy would you prefer ?
>=20
> I do not have one yet. I am just saying that there should be one and
> that it should be discussed before it is being implemented.
I see.
>=20
> I can say that I have a couple of things that are not working for me.
> That would be that I do not think that an extra CGI is required. We
> can use the one that we have (although for testing it can be
> implemented where ever you prefer) and that DNS-over-TLS cannot be
> enabled by default.
update_forwarders() was the main problem here in both developmant
stages. Anyways, DoT works for me good some testing scenarios and the
resulting informations are available for further development but sadly
i can not test all that but can offer the already working CGI and
sureley some trial and errors if this is needed.
>=20
> I also have a long list of issues that I would like to see tackled
> here as well. Those are that the unbound initscript is not behaving
> as intended. Extending it has to be done very careful to not break it
> even more or we make it shorter first and boil the problems down
> first and then add DNS-over-TLS.
That=C2=B4s plausible. Since i done also some testings in unbound
initscript, i can may try to do also some work in there but as you
already said, this would really need coordination/description of
what/how to do.
>=20
> > > I am absolutely happy that you are doing such good work here, but
> > > keep in mind that this needs to be integrated into IPFire in a
> > > slow
> > > and peer-reviewed way.
> >=20
> > Need to think about how we can split things here. Do you have some
> > ideas ?
>=20
> What is there to do?
Currently not sure how to find here a way of a release structure in a
peer-reviewed way.
>=20
> It looks like you have a working version of the initscript and the UI
> (almost?) done.
Yes, this version works for me. Installed it on a fresh installation
(OpenSSL-1.1.1a ;), tried to kill/test it on an old installation but it
worked so far (a little slow since it restart unboundctrl if things are
changing in there).
Haven=C2=B4t find bugs in the UI since now may someone have some for me ?
>=20
> > Another thing i have in account is the QNAME minimisation -->
> > https://tools.ietf.org/html/rfc7816
> > even in unbound.conf 'qname-minimisation: yes' is active it didn=C2=B4t
> > worked for me:
> >=20
> > $ dig txt qnamemintest.internet.nl +short
> > a.b.qnamemin-test.internet.nl.
> > "NO - QNAME minimisation is NOT enabled on your resolver :("
> >=20
> > needed to add also
> >=20
> > qname-minimisation-strict: yes
> > harden-below-nxdomain: yes
>=20
> Please open a ticket for that.
OK, will do that.
>=20
> Harden-below-nxdomain is deliberately disabled because it breaks
> loads of things and I do not consider it a correct solution.
Great info! 'harden-below-nxdomain: yes' is also not needed for QNAME
minimization.
>=20
> > at earlier tests in my local.d conf to get an
> >=20
> > a.b.qnamemin-test.internet.nl.
> > "HOORAY - QNAME minimisation is enabled on your resolver :)!"
> >=20
> > . Should we extend unbound.conf or should i add this one in
> > forward.conf if DoT is active ? Or is this may not wanted ?
> >=20
>=20
> This has nothing to do with DNS-over-TLS. Therefore this should be
> handled independently.
Yes, as mentioned will open a ticket for this.
Another thing has come to mind. A kdig check for the configured DoT
servers might be nice. May like it is managed in ddns.cgi with the
syncronisation function.
For example a kdig command can be used to grep for "is trusted" and the
"rd" flag and if true to set a green colored hostname in (currently)
dnsovertls.cgi, if not a red colored one can help the user for better
understanding if/or_which one is not working so possible
missconfiguration can be detected easier since the number of DNS
servers are not limited and open for randomization ?
As a beneath one, Cloudflair offers TLS1.3 support since a couple of
days/weeks now.
Best,
Erik
--===============2652220014574964224==--