Hi,
I'd like to ask your opinion about knot-resolver's systemd integration -
in particular, about the network configuration which is currently done
via drop-in files for systemd sockets - kresd.socket, kresd-tls.socket,
kresd-doh.socket and kresd-webmgmt.socket. [network-config-doc]
Have you had any issues while trying to configure network interfaces for
kresd?
Do you find the benefits of socket activation worth the extra complexity
of network configuration? (socket activation enables kresd to be
executed under non-priviledged user and the process doesn't require any
extra capabilities)
All the newtork configuration could take place in kresd.conf via
net.listen() [net-listen-exmaple] if we decided to drop the socket
activation feature. However, this would require we start the service
with the CAP_NET_BIND_SERVICE capability, which could be dropped once
kresd binds to the ports.
Any feedback is welcome!
[network-config-doc] -
https://knot-resolver.readthedocs.io/en/stable/daemon.html#network-configur…
[net-listen-exmaple] -
https://knot-resolver.readthedocs.io/en/stable/daemon.html#c.net.listen
--
Tomas Krizek
PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869
Hi,
to see whether kresd 4.0.0 would do a comparable or better job
than doh-httpproxy we analyzed failure rates by looking at HTTP response
codes for each setup and found some significant differences
for HTTP response code 400:
sample size: 1 000 000 HTTP requests for each run
HTTP Code [1] [2] [3]
--------------------------------
200 93.96 97.04 96.33
499 3.28 2.45 3.11
400 2.07 0.18 0.22 <<<
415 0.68 0.32 0.34
408 0.002 0.002 0.002
413 0.001 0 0
Numbers show percent.
setups:
[1] nginx -> (http, no tls) kresd
[2] nginx -> (http, no tls) doh-httpproxy -> (udp/53) unbound
To reduce the likelihood of measuring unrelated issues (like issues
caused by qname minimization differences between unbound and kresd) we
also used kresd as DNS resolver without touching its DoH code path:
[3] nginx -> (http, no tls) doh-httpproxy -> (udp/53) kresd
The HTTP request rate for [1] was slightly lower when compared with [2]
and [3].
To be more precise, doh-httproxy services was configured with two
running instances as described here:
https://facebookexperimental.github.io/doh-proxy/tutorials/nginx-dohhttppro…
version information:
kresd 4.0.0
nginx 1.14.2
unbound 1.9.0
https://github.com/facebookexperimental/doh-proxy @
9f943a4c232bd018ae155b7839a6b4e13181a5fd
This information on its own is not very useful but it might help
motivate further tests in a test-environment with no real end-user
traffic that allows for more verbose logging.
We would also like to hear from other kresd DoH adopters if they
observe similar failure rates on their setups.
Some open questions for further tests:
- How reproducible are these results?
- Does the HTTP method (GET vs. POST) change the error rate?
- Can the error rate be reduced by running multiple kresd backends?
(nginx sending requests to two kresd bakcends)
- Is the DNS transaction ID of always 0 as per RFC8484 an issue when
kresd is not also terminating the initial HTTPS connection from the DoH
client? (from a backend's perspective two distinct queries might look
identical when a reverse proxy sits between the DoH client and kresd)
regards,
Christoph
