19 Dub
2019
19 Dub
'19
8:37
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