fix(connlib): forward PTR queries for non-resources

[thomaseizinger]

When encountering a PTR query, connlib checks if the query is for a Firezone-managed resource and resolve it to the correct IP. If it isn't for a DNS resource, we should forward the query to the upstream resolver.

This isn't what is currently happening though. Instead of forwarding the query, we bail early from StubResolver::handle and thus attempt to route the packet through the tunnel. This however fails because the DNS query was targeted at connlib's stub resolver address which never corresponds to a resource IP.

When TRACE logs where activated, this resulted in several entries such as

Unknown resource dst=100.100.111.1

To ensure this doesn't regress, we now generate PTR and MX record queries in tunnel_test. We don't assert the response of those but we do assert that we always get a response. The inclusion of MX records asserts that unknown query types get correctly forwarded.

Resolves: #6749.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
firezone	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 18, 2024 10:34pm

[conectado]

Good catch! This could be causing issues with DNS in a lot of cases

[thomaseizinger]

This isn't what is currently happening though. Instead of forwarding the query, we bail early from StubResolver::handle and thus attempt to route the packet through the tunnel. This however fails because the DNS query was targeted at connlib's stub resolver address which never corresponds to a resource IP.

I'll send a follow-up where we I want to refactor the function signature to explicitly track the cases of "packet for our DNS resolver but failed otherwise".

[thomaseizinger]

I ran 10000 proptest cases locally. Appears to be stable :)

[thomaseizinger]

@conectado It just occurred to me that the chances of hitting one of these with a resource that we actually resolved are incredibly low. We should choose a much smaller netmask here (like 30 maybe?) to ensure we also generate some for the first IPs that we assign for DNS resources.