29 Dub
2019
29 Dub
'19
23:35
Hello Vladimir
It is interesting to read that consistently in the kresd documentation
and here. It sounds almost as if you really don't want people to use
kresd without a reverse proxy in-front of it :) We were hoping to cut
out nginx eventually to reduce the amount of software that is chained
together (latency) and give kresd more visibility as to whether requests
are coming from the same source.
Would be great if you could expose the DoH URI endpoint as a simple
configuration possibility via http.config in the future.
great to hear that.
The reCAPTCHA is post-authentication and happened when trying to submit
an issue (so the question still stands).
I'm replying here to
https://gitlab.labs.nic.cz/knot/knot-resolver/issues/465
(to workaround that reCAPTCHA)
I got lucky and have 3 "recorded" events of that issue from my firefox
session.
The less lucky part is that replaying the very same requests does
not trigger the issue again (or at least does not produce the same error
in the logs), so I'll have to do some more digging while probably
resetting the cache every time and maybe find something that these 3
occurrences have in common.
I'm not aware of any docs about this. By default
almost nothing gets
logged.
That sounds great for us.
- Is the DoH
URI configurable? (change /doh to our currently used URI)
or does that require something like
https://knot-resolver.readthedocs.io/en/stable/modules.html#how-to-expose-c…
?
- Is it possible to enable multiple DoH endpoints (URIs)
via a single kresd instance where every endpoint
has a distinct upstream configuration?
I don't think you can configure these easily, at least in 4.0.0. For
real production we expect you to want to use a battle-tested http
implementation as a proxy in front, and that setup makes the URL
irrelevant, I think. What do you mean by "upstream
configuration"? In any case we'd be
interested in what you're trying to achieve (and why, if you can share
that).
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).
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.
- Does kresd 4
(in the client position) support OOOR? [7]
Yes, all of UDP, TCP and TLS have out-of-order queries, and they get
pipelined over a single connection whenever going to the same IP (except
for UDP - What is the
canonical way to report security issues? (if [4] does not
work)
These reCAPTCHA errors were when you tried the "register" tab, right? 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.
Thanks. All fixed in 814
Thanks, much appreciated.
Thanks for shipping DoH support and properly supporting DoT.
Christoph