23 Dub
2019
23 Dub
'19
20:43
Hi Tomas--
Thanks for continuing to think through these issues here.
I think one of the things we're grappling with here is the knot-resolver
is useful in several different situations. more on that below.
On Tue 2019-04-23 18:31:47 +0200, Tomas Krizek wrote:
On 19/04/2019 08.37, Daniel Kahn Gillmor wrote:> So
here's a new
that'd be interesting to document, but i agree that it's a different
topic. I don't particularly care which way we represent it, though i'd
assume that systemd would want the simpler representation to Just Work™
everywhere, since they seem to value interface simplicity. happy to set
this bit aside in this discussion though.
the ListenStream=443 directive means that, when
connected, it listens on
all interfaces, on the standard https port.
I'd have to test that across various distros with varying systemd
versions, because I have a strong feeling there's a reason we recommend
using this snippet in upstream documentation (instead of
ListenDatagram=53 in this case):
BindIPv6Only=both
ListenDatagram=[::]:53
However, that's a different topic. this is what I'd adjust: either (a) use
localhost:443 as a default for
kresd-doh.socket, instead of binding to all interfaces; or (b) find a
way for DNS/DoT to also default to listen all interfaces upon a manual
action, without explicitly specifying the interfaces with
ListenDatagram= and ListenStream=, as we currently recommend. (Note:
without this manual action, they should still listen on localhost)
I'm going to set aside how to transition from existing deployments here,
and just ask what the defaults should be for new deployments, as that
question is thorny enough.
I'm also going to set aside, for the moment, how to implement this
configuration in systemd. While that's a neat technical question, i
don't think it's the core of the issue. I think we're getting tripped
up earlier.
The baseline knot-resolver installation has three probable use cases as
i see it (i'm happy to hear corrections):
a) a local recursive or forwarding resolver, to be used only by
processes on the same host
b) a public-facing recursive or forwarding resolver, either within the
LAN or on a WAN
c) a resolver on a gateway or home router (e.g. Omnia Turris),
intending to serve the LAN, but not the WAN.
These cases all suggest very different defaults.
if (a) is the goal, then we should disable everything by default except
for UDP and TCP on port 53 on the loopback. There's no purpose in
offering DoH or DoT for a purely internal machine.
if (b) is the goal, then we should enable everything on all network
addresses by default, and expect the administrator to juggle/prune what
they need responsibly.
but if (c) is the goal, then we need something much more clever and
subtle, because (at least):
* an open UDP resolver on the WAN interface is a potential disaster
which might be used as a reflection point for DDoS attacks, so it
should not be enabled by default: the admin needs to designate the
addresses on which it should listen on UDP.
* gateways and home routers often have an https interface for user
configuration, so they're likely to conflict with port 443 for DoH.
So i think the core of the issue is: which use case do we want the
defaults to represent? and how do we want an administrator who wants to
deploy an alternate use case to deviate explicitly from those defaults?
If these questions are already answered somewhere, please point me to
it!
Hopefully this re-framing helps illuminate the problem a bit more! As a
debian package maintainer, it occurs to me that i could ship a distinct
package with different systemd configuration for each use case
(e.g. "knot-resolver-local", "knot-resolver-public", or
"knot-resolver-gateway"), but that might be too big of a hammer.
what do you think?
--dkg