2 Kvě
2019
2 Kvě
'19
22:56
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
3 Kvě
3 Kvě
9:21
Hi Christoph,
this is very interesting, please keep going!
We will look into it once there is clear reproducer. While collecting
statistics it would be super useful to know which part was using HTTP/1
and HTTP/2 as it might significantly affect results. I expect that
HTTP/2 implementation we use is not that mature as HTTP/1.
Petr Špaček @ CZ.NIC
On 02. 05. 19 22:56, Christoph wrote:
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
9:45
On 5/2/19 10:56 PM, Christoph wrote:
[...] we analyzed failure rates by looking at HTTP
response codes [...]
I'd suggest looking at the requests causing the 4xx responses, as these
code are meant for incorrect requests. It's even possible that kresd is
more strict about these.
--Vladimir
1 Čen
1 Čen
14:33
Vladimír Čunát:
On 5/2/19 10:56 PM, Christoph wrote:
We've a better understanding about why kresd has a lower fraction of
answers with the HTTP 200 OK response code when compared with other DoH
server implementations.
Unlike other implementations kresd apparently enforces
that no other / additional HTTP parameters are present in the request
that are not defined in RFC8484.
So while kresd refuses with 400 others still provide 200 with the answer
to the query.
RFC8484 does not say anything about how DoH servers should handle that
condition.
To increase the interoperability it would be great if you could
add an option that allows the operator to decide how strict he would
like his service to be:
a) current behavior
b) just parsethe relevant fields and ignore additional HTTP parameters
in DoH requests
What do you think?
thanks,
Christoph
[...] we analyzed failure rates by looking at
HTTP response codes [...]
I'd suggest looking at the requests causing the 4xx responses, as these
code are meant for incorrect requests. It's even possible that kresd is
more strict about these.
5 Čen
5 Čen
11:11
On 01. 06. 19 14:33, Christoph wrote:
Vladimír Čunát:
Hello,
that's very interesting! Thank you for reaching out.
Let's continue discussion on IETF DoH WG mailing list, this has impact
far beyond Knot Resolver implementation.
Petr Špaček @ CZ.NIC
On 5/2/19 10:56 PM, Christoph wrote:
We've a better understanding about why kresd has a lower fraction of
answers with the HTTP 200 OK response code when compared with other DoH
server implementations.
Unlike other implementations kresd apparently enforces
that no other / additional HTTP parameters are present in the request
that are not defined in RFC8484.
So while kresd refuses with 400 others still provide 200 with the answer
to the query.
RFC8484 does not say anything about how DoH servers should handle that
condition.
To increase the interoperability it would be great if you could
add an option that allows the operator to decide how strict he would
like his service to be:
a) current behavior
b) just parsethe relevant fields and ignore additional HTTP parameters
in DoH requests
What do you think? [...] we analyzed failure rates by looking at
HTTP response codes [...]
I'd suggest looking at the requests causing the 4xx responses, as these
code are meant for incorrect requests. It's even possible that kresd is
more strict about these.
6 Čen
6 Čen
1:07
that's very interesting! Thank you for reaching
out.
Let's continue discussion on IETF DoH WG mailing list, this has impact
far beyond Knot Resolver implementation.
There doesn't appear to be any more discussion on this on
the DoH WG mailing list.
The RFC 8484 authors made their opinion rather clear.
It would be interesting to hear knot-resolver developers' opinion
so we can get an idea whether the current behavior will remain,
changes or becomes configurable.
thanks,
Christoph
25 Čen
25 Čen
16:04
On 06. 06. 19 1:07, Christoph wrote:
Hi,
we have discussed this with other vendors and decided to follow suite
and ignore extra parameters in DoH GET calls.
This improvement was merged
https://gitlab.labs.nic.cz/knot/knot-resolver/merge_requests/832
and should be eventually available as part of Knot Resolver release.
In meantime we would appreaciate feedback on this change. Thank you!
--
Petr Špaček @ CZ.NIC
that's
very interesting! Thank you for reaching out.
Let's continue discussion on IETF DoH WG mailing list, this has impact
far beyond Knot Resolver implementation.
There doesn't appear to be any more discussion on this on
the DoH WG mailing list.
The RFC 8484 authors made their opinion rather clear.
It would be interesting to hear knot-resolver developers' opinion
so we can get an idea whether the current behavior will remain,
changes or becomes configurable.
1768
days inactive
1822
days old
knot-resolver-users@lists.nic.cz
6 comments
3 participants
participants (3)
-
Christoph -
Petr Špaček -
Vladimír Čunát