Ticket created by ~nickbp on ~nickbp/originz
Grab the existing benchmark harness code to test various end-to-end query scenarios, checking behavior for various query scenarios such as:
- If the request is filtered, does it skip the cache and client? How does the filtered response look?
- If the request is cached, does it skip querying the client? How does the cached response look?
- If the request lacks an OPT record, does the response lack an OPT record? (For each of filtered/cached/upstream)
Keeping it at a high level of "send request, check resulting external behavior and response" should keep it pretty resilient to refactoring etc.
This can later be expanded to validate server+client functionality for e.g. #21 (COOKIE) and #35 (NSID).
Ticket created by ~nickbp on ~nickbp/originz
At the moment the Resolver passes through original external client request as-is. We should probably switch this to instead explicitly construct a new request based on the RequestInfo.
This avoids weird "leakage" from the original client request that could affect the result, or worse poison the cache in some way.
A catch with this route is that it does suddenly imply additional checks for things that the client may be asking for, but this was already sort of the case and was just implicitly being ignored by taking and caching the first response for an as-is query. Some examples where this came up:
- With DNSSEC where the cache key now has a dnssec_ok bit to avoid cross-pollination between queries that have it enabled and queries that don't.
- With EDNS/OPT records where we need to explicitly strip out the OPT record in the response to the client if their request didn't ask for it.
Ticket created by ~nickbp on ~nickbp/originz
See RFC5001
Can exercise via
dig
with the+nsid
option, or with+ednsopt=NSID[:value]
If the server gets an OPT containing NSID, include originz info (project URL) in response. But don't include the NSID request or response in the cache - this is sort of like the per-client udp size handling.
Some other server-side modifications relating to EDNS to cover while in there:
- Omit all EDNS options (including NSID) from requests upstream. As another example, PADDING can be tested via
dig +padding=<length>
. Ref: https://datatracker.ietf.org/doc/html/rfc6891#section-6.2.6- If the client doesn't include an EDNS header, we shouldn't include one in the response either, test via
dig +noedns
. Interestingly filtered entries honor this while upstream queries (cached or not) do not, so it feels like a filtering issue on the response. It makes sense for the upstream query to contain EDNS even if the original client request didn't have it.
Comment by ~nickbp on ~nickbp/originz
Can exercise via
dig
with the+cookie=value
/+nocokie
options, or maybe with+ednsopt=COOKIE[:value]
Ticket created by ~nickbp on ~nickbp/originz
See also the CoreDNS
erratic
plugin as an example:
- drop: drop 1 per AMOUNT of queries, the default is 2.
- truncate: truncate 1 per AMOUNT of queries, the default is 2.
- delay: delay 1 per AMOUNT of queries for DURATION, the default for AMOUNT is 2 and the default for DURATION is 100ms.
We've already got an equivalent
delay
test in the benchmarks, but could also try testingdrop
andtruncate
behavior in those tests as well.
Comment by ~nickbp on ~nickbp/originz
Thinking it'd make sense to get this off the list, there's been similar support added for EDNS PADDING recently in the DoT/DoH clients and this isn't too different from that. There's server and client halves that would behave a bit differently:
Server:
- After testing some queries in
dig
, it looks like at least both UDP and TCP queries will include a client cookie, so we may as well implement server-side support for both of those.- sha256 of concatenated clientip+clientcookie+secretdata, then truncate the hash from 32 bytes to 8 bytes (ref https://www.rfc-editor.org/rfc/rfc7873.html#appendix-B)
- The server randdata is tricky in HA situations. By default can generate a random secret on startup, then allow override with a secret provided via envvar. The same secret would be shared for both UDP and TCP endpoints.
- When generating the server secret, could give an informational message if starting in a docker container and no secret is provided via env (using a hint envvar added to our
Dockerfile
)Client:
- I imagine it doesn't hurt to just include support in all of the clients (UDP/TCP/DoT/DoH), where each one would have its own cached client secret and server key pair
- sha256 of concatenated clientip+serverip/serverhost+randdata then truncate the hash from 32 bytes to 8 bytes (ref https://www.rfc-editor.org/rfc/rfc7873.html#appendix-A)
- The client randdata could be fully randomized and generated per client object
Comment by ~nickbp on ~nickbp/originz
Fixed via
5577abe
, ended up being pretty straightforward to include in cache keys.
REPORTED
RESOLVED FIXEDComment by ~nickbp on ~nickbp/originz
This would theoretically tie into EDNS COOKIE support (#21) - valid cookies could be given a better rate limit.
But that also depends on EDNS COOKIE support being pretty common, which I suspect it isn't...
Ticket created by ~nickbp on ~nickbp/originz
If the client includes the EDNS
dnssec_ok
flag enabled then we should treat that as a different query from one that has the flag disabled.Can exercise like this:
$ dig @127.0.0.1 -p 5353 +dnssec example.com # should include RRSIG record in response
vs
$ dig @127.0.0.1 -p 5353 example.com # should omit RRSIG