In order to bootstrap DoH servers, we need a way of reliably resolving the domain of the DoH server to an IP address. Initially, I thought that this would be tricky to do if we have to integrate this into the Client's state machine. Whilst implementing DoH however, I realised that we can instead put this responsibility onto the IO layer of connlib. Similar to other cases, we can reuse external triggers as our retry mechanism in case of failure. In particular, we can simply issue UDP DNS queries for the DoH domain to all system-defined DNS resolvers every time we are told to send a DNS query over DoH but the corresponding client isn't initialized yet. In other words, instead of building a retry mechanism ourselves, we attempt to repair any kind of broken state once per DNS query that we receive. Performing this DNS resolution does require a bit of code. We already started to do something similar in #10817. In order to reuse that code, we extract it into a `l4-udp-dns-client` crate and slightly refactor its semantics. In particular, we now wait for the response of all upstream servers (but at most 2s) and combine the result. The resulting `UdpDnsClient` can now be used inside the Client's event-loop to re-resolve the portal URL and will also be used as part of our DoH implementation to bootstrap the connection to the DoH server. Related: #4668
Rust development guide
Firezone uses Rust for all data plane components. This directory contains the Linux and Windows clients, and low-level networking implementations related to STUN/TURN.
We target the last stable release of Rust using rust-toolchain.toml.
If you are using rustup, that is automatically handled for you.
Otherwise, ensure you have the latest stable version of Rust installed.
Reading Client logs
The Client logs are written as JSONL for machine-readability.
To make them more human-friendly, pipe them through jq like this:
cd path/to/logs # e.g. `$HOME/.cache/dev.firezone.client/data/logs` on Linux
cat *.log | jq -r '"\(.time) \(.severity) \(.message)"'
Resulting in, e.g.
2024-04-01T18:25:47.237661392Z INFO started log
2024-04-01T18:25:47.238193266Z INFO GIT_VERSION = 1.0.0-pre.11-35-gcc0d43531
2024-04-01T18:25:48.295243016Z INFO No token / actor_name on disk, starting in signed-out state
2024-04-01T18:25:48.295360641Z INFO null
Benchmarking on Linux
The recommended way for benchmarking any of the Rust components is Linux' perf utility.
For example, to attach to a running application, do:
- Ensure the binary you are profiling is compiled with the
releaseprofile. sudo perf record -g --freq 10000 --pid $(pgrep <your-binary>).- Run the speed test or whatever load-inducing task you want to measure.
sudo perf script > profile.perf- Open profiler.firefox.com and load
profile.perf
Instead of attaching to a process with --pid, you can also specify the path to executable directly.
That is useful if you want to capture perf data for a test or a micro-benchmark.