18 Dub
2019
18 Dub
'19
16:06
Hi, below is a continuation of a discussion regarding the default port
for DNS-over-HTTPS (DoH) in Knot Resolver. My argument is to use 44353
as a packaging default, since using port 443 by default makes an
unexpected collision likely. The DoH service requires configuration to
be exposed on public interfaces anyway, so users are free to override
this value as they see fit.
On 18/04/2019 15.16, Daniel Kahn Gillmor wrote:> On Thu 2019-04-18
10:01:39 +0200, Tomas Krizek wrote:
Sockets= is required, otherwise the socket won't be passed to any other
instance than kresd@1, which goes against our use-case of scaling up
using multiple independent systemd processes.
No documentation, mostly just trial and error (and a lot of swearing :)
If kresd-doh.service is masked by default, this places a symlink to
/etc/systemd/system, which is where users usually makes their changes
(as opposed to /usr/lib/systemd/system). Is this acceptable with various
packaging policies across distros?
Let's say it is. User unmasks this socket file and the uninstalls the
package. This will issue a warning, since the symlink was part of the
package.
A more problematic case is when you consider package upgrade. If
/etc/systemd/system/kresd-doh.service -> /dev/null is part of the
package, then the user removes this files via unmasking to actually use
the socket, it will get re-masked again during the next package upgrade.
I disagree. knot-resolver-module-http now provides two socket files:
kresd-doh.socket
kresd-webmgmt.socket
Now both are enabled by default after the installation, on localhost
only, and users simply need to load http module in their config.
It seems unnecessarily complicated to require additional handling of
kresd-doh.socket as opposed to kresd-webmgmt.socket (which has no reason
not to be enabled by default).
I don't consider the localhost default to be an issue. All other
sockets, i.e. plain DNS and DNS-over-TLS, are configured like this and
I'd like to keep it this way. If a user decides to expose the DNS
service, it should require a manual action.
The port, of course, is a matter of lively debate. However, perhaps the
default port in kresd-doh.socket file doesn't matter all that much. It's
easy to override and documented how to do that.
thanks for
these constructive suggestions. I've tried to use port 443
for kres-doh.socket and have the socket masked (simply disabling it
isn't enough, since kresd(a)*.service requsts it via Sockets=).
I think the answer there is, don't put it in Sockets= -- if it's
enabled, it will get associated properly because of the Service= line,
and if it's not enabled, it won't get associated. However, I
wasn't able to find a reasonable way to do it across all
ditros in a way that would work reliably in all cases (including
upgrades).
Do you have a pointer to documentation about what mechanisms you tried,
and how they failed on different distros? I'd like to understand what
you ran into, so i can try to help reason about it without having to
replicate all the work. I also think
that it'd be confusing for users that kresd-doh.socket
would require extra command to use, as opposed to kresd-webmgmt.socket
(both used by http module).
I don't think that's confusing. These are different interfaces, and
it's entirely reasonable that they would be controlled separately. In the end,
we've decided to go with 127.0.0.1:44353 as the default for
kresd-doh.socket in upstream and Fedora/EPEL packages. The documented
use case is how to remove this default and listen on port 443 on all
interfaces.
Hm, that makes me sad for a number of reasons (both the ephemeral-range
port *and* the 127.0.0.1, which doesn't make a lot of sense). I hope we
can figure out the details together about these tradeoffs, so that we
can make the default configuration something more useful. happy to talk about this on-list as well, if you
prefer (presumably
knot-resolver-users(a)lists.nic.cz).
--
Tomas Krizek
PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869
19 Dub
19 Dub
8:37
New subject: knot-resolver DoH port
Hi Tomas--
Thanks for your work on this, and these detailed notes!
On Thu 2019-04-18 16:06:07 +0200, Tomas Krizek wrote:
I disagree. knot-resolver-module-http now provides two socket files:
kresd-doh.socket
kresd-webmgmt.socket
Now both are enabled by default after the installation, on localhost
only, and users simply need to load http module in their config.
i haven't looked at it in detail, but if webmgmgt permits arbitrary
control or detailed/sensitive access to the internals knot-resolver, i'm
not convinced it should be enabled by default either, fwiw, even if it's
just on localhost.
Hi, below is a continuation of a discussion regarding
the default port
for DNS-over-HTTPS (DoH) in Knot Resolver. My argument is to use 44353
as a packaging default, since using port 443 by default makes an
unexpected collision likely. The DoH service requires configuration to
be exposed on public interfaces anyway, so users are free to override
this value as they see fit.
to be clear on where i stand, i think naive administrators are more
likely infer the wrong message from the non-standard port, and try to
operate a service there. Let me see if i can understand what our other
options are.
On 18/04/2019 15.16, Daniel Kahn Gillmor wrote:> On
Thu 2019-04-18
10:01:39 +0200, Tomas Krizek wrote:
Sockets= is required, otherwise the socket won't be passed to any other
instance than kresd@1, which goes against our use-case of scaling up
using multiple independent systemd processes.
Gotcha, thanks, i'd forgotten that aspect.
So here's a new proposal (and maybe if this still doesn't sit well we
should ask the systemd folks for their recommendation):
Ship a default-disabled (not masked) kresd-doh.socket, which has:
[Unit]
Description=Knot Resolver DoH (DNS-over-HTTP) network listener
Documentation=man:kresd.systemd(7)
Documentation=man:kresd(8)
Before=sockets.target
[Socket]
FreeBind=true
FileDescriptorName=doh
ListenStream=443
Slice=system-kresd.slice
[Install]
WantedBy=sockets.target
the ListenStream=443 directive means that, when connected, it listens on
all interfaces, on the standard https port. And note that it *doesn't*
have any Service= directive.
Then an admin that wants to have kresd@.service listen on DoH drops the
following snippet in /etc/systemd/system/kresd@.service.d/override.conf:
[Service]
Sockets=kresd-doh.socket
this override snippet won't be part of any distro, and won't get in the
way of anything during package upgrade.
Its presence basically says "yes, please offer DoH service".
thanks
for these constructive suggestions. I've tried to use port 443
for kres-doh.socket and have the socket masked (simply disabling it
isn't enough, since kresd(a)*.service requsts it via Sockets=).
I think the answer there is, don't put it in Sockets= -- if it's
enabled, it will get associated properly because of the Service= line,
and if it's not enabled, it won't get associated. No documentation, mostly just trial and error (and a
lot of swearing :)
If kresd-doh.service is masked by default, this places a symlink to
/etc/systemd/system, which is where users usually makes their changes
(as opposed to /usr/lib/systemd/system). Is this acceptable with various
packaging policies across distros?
Let's say it is. User unmasks this socket file and the uninstalls the
package. This will issue a warning, since the symlink was part of the
package.
A more problematic case is when you consider package upgrade. If
/etc/systemd/system/kresd-doh.service -> /dev/null is part of the
package, then the user removes this files via unmasking to actually use
the socket, it will get re-masked again during the next package upgrade.
I agree with you that using masking as a standard packaging mechanism
seems problematic, and we shouldn't do it.
I also think that it'd be confusing for users that
kresd-doh.socket
would require extra command to use, as opposed to kresd-webmgmt.socket
(both used by http module).
I don't think that's confusing. These are different interfaces, and
it's entirely reasonable that they would be controlled separately. I don't consider the localhost default to be an
issue. All other
sockets, i.e. plain DNS and DNS-over-TLS, are configured like this and
I'd like to keep it this way. If a user decides to expose the DNS
service, it should require a manual action.
Hm, i see the advantage to the parallelism. The manual action i've
proposed is dropping in the override snippet.
Alternately, we could use the same setup as plain DNS and DNS-over-TLS,
and just expect that people for whom a collision on the loopback's TCP
port 443 will use kresd-*.socket.d/override.conf to choose a different
port.
(or, if you like the above kresd@.service.d/override.conf approach, we
could consider converting kresd.socket and kresd-tls to use the same thing)
The port, of course, is a matter of lively debate.
However, perhaps the
default port in kresd-doh.socket file doesn't matter all that much. It's
easy to override and documented how to do that.
If it doesn't matter all that much, then we should *definitely* stick
with the standard port for HTTPS to avoid confusion :)
--dkg
23 Dub
23 Dub
18:31
New subject: knot-resolver DoH port
On 19/04/2019 08.37, Daniel Kahn Gillmor wrote:> So here's a new
proposal (and maybe if this still doesn't sit well we
should ask the systemd folks for their
recommendation):
Ship a default-disabled (not masked) kresd-doh.socket, which has:
[Unit]
Description=Knot Resolver DoH (DNS-over-HTTP) network listener
Documentation=man:kresd.systemd(7)
Documentation=man:kresd(8)
Before=sockets.target
[Socket]
FreeBind=true
FileDescriptorName=doh
ListenStream=443
Slice=system-kresd.slice
[Install]
WantedBy=sockets.target
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.
And note that it *doesn't*
have any Service= directive.
Then an admin that wants to have kresd@.service listen on DoH drops the
following snippet in /etc/systemd/system/kresd@.service.d/override.conf:
[Service]
Sockets=kresd-doh.socket
this override snippet won't be part of any distro, and won't get in the
way of anything during package upgrade.
Its presence basically says "yes, please offer DoH service".
Overall, your proposal seems doable. I have a couple objections:
1. Network interface configuration should be consistent. Either an
administrator has to configure interfaces for all our services - DNS,
DoT, DoH and webmgmt, or none of them. Assuming we'd use the proposed
drop-in to enable DoH socket, 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)
2. kresd-doh.socket would require special enablement through a drop-in
file for kresd@.service, which is unlike any other of our sockets. I
think our systemd integration/configuration is already quite confusing
for administrators, and adding a "special case" socket certainly won't
help, even with proper documentation.
I'd consider (1) to be a requirement. (2) is probably unavoidable if we
decide to use 443 as the default port for DoH. It seems like achieving a
configuration that's both reasonably simple and consistent across DNS /
DoT and DoH is just impossible when opting to use 443 as the default
port for DoH.
Alternately, we could use the same setup as plain DNS
and DNS-over-TLS,
and just expect that people for whom a collision on the loopback's TCP
port 443 will use kresd-*.socket.d/override.conf to choose a different
port.
I think this is unacceptable, mostly because:
a) The collision might not be obvious. The DoH service might start up
and appear to be operating correctly, until you try to access your
existing HTTPS service.
b) Except for those interested in DoH, almost nobody will even suspect
that installing a DNS resolver might break their existing and running
HTTPS service.
--
Tomas Krizek
PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869
20:43
New subject: knot-resolver DoH port
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
1838
days inactive
1843
days old
knot-resolver-users@lists.nic.cz
3 comments
2 participants
participants (2)
-
Daniel Kahn Gillmor -
Tomas Krizek