30 Dub
2019
30 Dub
'19
22:46
On 4/30/19 10:22 PM, Christoph wrote:
I believe it's safe if you're careful with configuration differences,
i.e. know what sharing cache means. Still, it's true that the
possibility is mainly a by-product of the design and not tested in any
way. There are currently only RRs and packets along with some
meta-data, but people tend not to realize all consequences, e.g. around
aggressively generated answers from NSEC(3) records. Changes like
forwarding to different resolvers (or iterating) shouldn't be a problem,
assuming all of the targets serve the "original" (unfiltered/unmodified)
DNS tree.
Yeah, it might
work, but there be dragons as it is completely
untested setup. Please let us know what you find out!
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?
Yes, I think so; I had thought about that already. I expect the support
for x-forwarded-for would be easy to add and likely to be useful. We
only just released the first version with DoH, and on the whole DoH
hasn't seen that much real-life use yet.
--Vladimir