30 Dub
2019
30 Dub
'19
16:29
On 30. 04. 19 14:28, Vladimír Čunát wrote:
Yeah, it might work, but there be dragons as it is completely untested
setup. Please let us know what you find out!
Let me make one thing clear:
We are DNS experts, not HTTP experts. It is a bad idea to expect that
DNS experts will produce perfect HTTP code. This is the reason why we
recommend against running "naked" DoH in kresd.
Also, personally I think it is architecturally much better to split HTTP
and DNS parts because proper DoH implementation with all the HTTP/2
bells and whistles (and potentially HTTP/3 also) is order of magnitude
more complex than any other transport used for DNS, and thus unsuitable
for tight integration into core of DNS software.
In other words, I believe that a separate HTTP<->DNS proxy is
architecturally much better idea than just DoH inside core of DNS software.
I agree that latency and complexity will be worse, but that's price to
pay for layering violations like the one in DoH protocol.
Personally I think it is much better to use full VPN to secure
everything instead of focusing just on DNS, that in my eyes spending too
much effort for marginal benefit.
I could imagine using a solution very similar to policy.RPZ, in future:
https://gitlab.labs.nic.cz/knot/knot-resolver/merge_requests/767
Let me add that generic auto-reload mechanisms have inherent problems
which might not be solvable for a reasonable price.
More details can be found here:
https://gitlab.labs.nic.cz/knot/knot-resolver/issues/268#note_76614
and the discussion around. The solution mentioned there allows full
kresd reconfiguration "on fly" as long as you have at least two
instances (e.g. kresd@1 and kresd@2).
Petr Špaček @ CZ.NIC
On 4/29/19 11:35 PM, Christoph wrote:
> We want to give users the freedom to choose their preferred
> configuration. By selecting an URL they can choose how we resolve
> their queries recursively or non-recursively (so they can make their own
> trade-off between small anonymity set size (= we handle recursion) and
> who gets to see their query data - without their IP addr (bigger
> anonymity set).
There is RD bit in DNS queries for this :-)
In case you still want to change URIs, have a look at
https://knot-resolver.readthedocs.io/en/latest/modules.html#how-to-expose-c…
especially line "-- copy all existing webmgmt endpoints" and below.
You can do things like
my_endpoints = { '/blah' = http.configs._builtin.doh.endpoints['/doh'] }
to rename /doh to something /blah etc.
In any case, as soon as you have more than one HTTP server you will need
a HTTP proxy/multiplexing service anyway, so I'm not sure it is even
worth the effort hacking it in kresd. It can and should be done in the
HTTP multiplexing layer.
Sounds like we
will need multiple kresd instances to cover this
use-case, which is fine. Multiple kresd instances with distinct configs
do not appear to be supported out of the box even though you ship a
multi-instance systemd service file, so a few systemd drop-in files
will be needed, which is also fine.
Yes, I expect now you'd best use multiple kresd instances... which means
you'll also need some kind of http proxy anyway, assuming you want these
to run on the same name/IP. We consider running multiple instances with
*different configs* quite a specific setup, so it isn't really
considered in the systemd services shipped by default. I expect you can
still share the cache among these differently configured instances, at
least based on the examples you wrote - I expect nothing changing the
DNS data itself or trust anchors for validation... e.g. filtering
actions via policy module aren't cached. It is interesting to read that consistently in
the kresd documentation
and here.
It's a warning. We're not aware of "large deployments" of lua-http,
contrary to e.g. nginx; that's some risk by itself, especially the
consequences around less testing, less people maintaining the code, etc. The files currently aren't watched for changes.
It will be easiest to
just restart the service, as cache is kept and occasional non-reply
tends to be handled well in DNS (and rotations tend to be rather
infrequent).
would be a nice to have kresd re-read files without needing a full
restart at some point. The reCAPTCHA
is post-authentication and happened when trying to submit
an issue (so the question still stands).
I don't know... I haven't heard of this problem from anyone else yet,
and I can't say I understand captcha stuff. In the worst case, any
communication channel is OK, especially for important issues. Apart
from this mailing-list, there's also non-public
knot-resolver(a)labs.nic.cz <mailto:knot-resolver@labs.nic.cz> and public
chat on gitter.im. In the extreme you can even encrypt e-mails by our
personal PGP keys from https://www.knot-resolver.cz/download/
--Vladimir