#37 Test various query scenarios 5 months ago

Next added by ~nickbp on ~nickbp/originz

#37 Test various query scenarios 5 months ago

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).

#36 Build separate request for querying upstreams 5 months ago

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.

#35 Support OPT NSID option in server, clean up EDNS handling 5 months ago

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.

#21 Support OPT COOKIE option in client and server 5 months ago

Comment by ~nickbp on ~nickbp/originz

Can exercise via dig with the +cookie=value/+nocokie options, or maybe with +ednsopt=COOKIE[:value]

#34 Test clients with simulated erratic upstreams 5 months ago

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 testing drop and truncate behavior in those tests as well.

#21 Support OPT COOKIE option in client and server 5 months ago

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

#33 Check for EDNS dnssec_ok for query caching 5 months ago

Comment by ~nickbp on ~nickbp/originz

Fixed via 5577abe, ended up being pretty straightforward to include in cache keys.

REPORTED RESOLVED FIXED

#8 Implement rate limiter for incoming queries 5 months ago

Comment 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...

#33 Check for EDNS dnssec_ok for query caching 5 months ago

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