30 Dub
2019
30 Dub
'19
22:22
Vladimír Čunát:
ok, we will document the knot-resolver(a)labs.nic.cz address as single
point of contact for non-public reports then.
Petr Špaček:
Do you specifically mean the "two kresd instances with non-identical
configurations (aim to) share a single cache" is dangerous/not supported?
In that case we would simply have have distinct caches - which is a bit
unfortunate but we prefer less dragons.
After all we will first see if there is actual demand for that use-case.
Thanks for elaborating on this, we will keep nginx then.
Does kresd aim to support x-forwarded-for or similar HTTP headers
to expose the client IP from the HTTP reverse proxy to kresd?
I could imagine using a solution very similar to
policy.RPZ, in future:
https://gitlab.labs.nic.cz/knot/knot-resolver/merge_requests/767
thanks for that info.
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/ On 30. 04. 19 14:28, Vladimír Čunát wrote:
yes, my description was not entirely clear, from the client point of
view we always do recursion but it is more how we resolve it for them
(do we involve forwarders or not, which ones, ..) The RD bit is not made
for that.
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…
looks like the same URL as the one in my email ;-)
thanks for confirming.
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.
Yeah, it might work, but there be dragons as it is completely
untested setup. Please let us know what you find out! 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.
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. 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).
Thanks that is a useful recommendation.
Christoph