mirror of
https://github.com/outbackdingo/firezone.git
synced 2026-01-27 18:18:55 +00:00
62a39a81d0
It appears that several systems (at least MacOS) may send DNS queries to the same server with the same query ID but from different source sockets. Within connlib, we operate multiple DNS servers (one for each upstream) and use the tuple of server address and query ID to remember the necessary state we need to map the response back once we have the response from the upstream server. Given the discovery that this tuple is not necessarily unique, we now need to also track the source socket that _we_ are using to send our queries in order to correctly remember, which socket we need to send the response back to. For that, we extend the layer 3 UDP and TCP clients to return us the socket they are using for each query that we queue. In very specific circumstances, this can still fail. In particular, when connlib receives an SRV or TXT query for a resource, it resolves that query in the context of the resource's site by sending it to port 53535 of the Gateway's TUN device. The Gateway listens to DNS queries on this port and resolves them using its configured system resolvers. It however only listens on a single address, meaning we may be forwarding queries from several of connlib's "servers" to a single query which again may break the uniqueness constraint if two queries with the same ID are received at the same time because we would reuse the TCP connection to the resolver running in the Gateway and thus send them from the same source port. We consider this case to be sufficiently rare and handle it by just failing the 2nd DNS query. There may be ways of resolving it but it requires a bigger refactoring of how we establish TCP connections to upstream resolvers.
Connlib
Firezone's connectivity library shared by all clients.
Building Connlib
You shouldn't need to build connlib directly; it's typically built as a dependency of one of the other Firezone components. See READMEs in those directories for relevant instructions.