Thomas Eizinger

Unless there is a change in networks, I don't see how we would ever be able to upgrade to a direct connection from a relayed one. How likely is it...

I've always thought of this more as an optimisation actually. Now that we have https://github.com/firezone/firezone/pull/6060, it is a lot less critical :)

> The portal needs to know the utilisation of a relay in order to load-balance them for new connections. How valid is this usecase given that we now send relays...

Currently, `connlib` only supports DNS over UDP/53 which means we are bound a certain maximum size of DNS responses that we can send to the OS / application. If we...

For DNS servers that are IP/CIDR resources, I'd suggest that DoH should not have any effect for now. To implement that, we'd have to write a client-side TCP state machine...

> Related: #4249 The API between the portal & connlib could be something like: ```jsonc { "dns_transport": "udp / https" // udp would be default value } ``` This would...

> How do we resolve the DoH hostname initially? One option would be to use that service's UDP resolver to do it. So, ask `1.1.1.1` for the A record for...

I've done some research and it appears the recommended approach is to use the system resolver to initially resolve the DNS server hostname. The issue here is that by the...

> * Support the well-known, public DoH resolvers, allowing the customer to select them as upstreams. This will be a UI-only limitation, right? For the actual API between connlib and...

Also, I am afraid our current representation of DNS servers in the API is not forwards-compatible with new "kinds" of DNS servers: https://github.com/firezone/firezone/blob/3e30bab965a2f297e087db60b3396eb124f4ae29/rust/connlib/shared/src/messages.rs#L253-L257 (Same issue we've had with the Internet...