mirror of
https://github.com/outbackdingo/firezone.git
synced 2026-01-27 18:18:55 +00:00
99d8fcb8fc
## Description We want to resolve DNS queries of type SRV & TXT for DNS resources within the network context of the site that is hosting the DNS resource itself. This allows admins to e.g. deploy dedicated nameservers into those sites and have them resolve their SRV and TXT records to names that are scoped to that particular site. SRV records themselves return more domains which - if they are configured as DNS resources - will be intercepted and then routed to the correct site. Prior to this PR, SRV & TXT records got resolved by the DNS server configured on the client (or the server defined in the Firezone portal), even if the domain in question was a DNS resource. This effectively meant that those SRV records have to be valid globally and could not be specific to the site that the DNS resource is hosted in. ## Example Say we have these wildcard DNS resources: - `**.department-a.example.com` - `**.department-b.example.com` Each of these DNS resources is assigned to a different site. If we now issue an SRV DNS query to `_my-service.department-a.example.com`, we may receive back the following records: - `_my-service.department-a.example.com. 86400 IN SRV 10 60 8080 my-service1.department-a.example.com.` - `_my-service.department-a.example.com. 86400 IN SRV 10 60 8080 my-service2.department-a.example.com.` - `_my-service.department-a.example.com. 86400 IN SRV 10 60 8080 my-service3.department-a.example.com.` Notice how the SRV records point to domains that will also match the wildcard DNS resource above! If that is the case, Firezone will also intercept A & AAAA queries for this service (which are a natural follow-up from an application making an SRV query). As a result, traffic for `my-service1.department-a.example.com` will be routed to the same site the DNS resource is defined in. If the returned domains don't match the wildcard DNS resource, the traffic will either not be intercepted at all (if it is not a DNS resource) or routed to whichever site defines the corresponding DNS resource. All of these scenarios may be what the admin wants. If the SRV records defined for the DNS resource are globally valid (and e.g. not even resources), then resolving them using the Client's system resolver may be all that is needed. If the services are running in a dedicated site, that traffic should indeed be routed to that site. As such, Firezone itself cannot make any assumption about the structure of these records at all. The only thing that is enabled with this PR is that IF the structure happens to match the same DNS resource, it allows admins to deploy site-specific services that resolve their concrete domains via SRV records. ## Testing The implementation is tested using our property-based testing framework. In order to cover these cases, we introduce the notion of site-specific DNS records which are sampled when we create each individual Gateway. When selecting a domain to query for, all global DNS records and the site-specific ones are merged and a domain name and query type is chosen at random. At present, this testing framework does not assert that the DNS response itself is correct, i.e. that it actually returned the site-specific record. We don't assert this for any other DNS queries, hence this is left for a future extension. We do assert using our regression grep's that we hit the codepath of querying an SRV or TXT record for a DNS resource. Related: #8221