Personal projects go here
CTO of https://scie.nz
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).
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.
Can exercise via
+nsidoption, or with
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.
Can exercise via
+nocokieoptions, or maybe with
See also the CoreDNS
erraticplugin 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
delaytest in the benchmarks, but could also try testing
truncatebehavior in those tests as well.
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:
- 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
- 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
5577abe, ended up being pretty straightforward to include in cache keys.
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...
If the client includes the EDNS
dnssec_okflag 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
$ dig @127.0.0.1 -p 5353 example.com # should omit RRSIG