Hello!
Micah and I worked on this as part of the P101 work for the VPN. Some of the work that Q is looking into as part of its involvement with the Onion Services Working Group may impact some of these items.
Cheers, Alex
--- snip ---
``` Filename: XXX-complex-dns-traffic-for-vpn.md Title: Handling Complex DNS Traffic for VPN usage in Tor Authors: Alexander Færøy and Micah Anderson Created: 2024-05-22 Status: Open ```
[[_TOC_]]
# Introduction
## Background
As part of our work building a prototype for a VPN client that uses the Tor network, we have investigated the need for more modern DNS handling within the Tor network.
Presently, Tor exit nodes support hostname resolution and reverse DNS lookups for both IPv4 and IPv6 addresses. Reverse DNS queries are handled by sending a `RELAY_RESOLVE` cell containing an `in-addr.arpa` hostname, with successful responses returning a hostname in the reply cell.
Initially, a broader set of features was considered. However, with the introduction of proposal #348 (UDP Application Support in Tor), we have been able to conduct more direct experiments with the required DNS types on the Android platform, utilizing both TCP and UDP resolvers.
## Objective
This proposal aims to expand Tor's DNS resolution capabilities by supporting a broader range of DNS request types. Additionally, we will examine the potential impacts of this enhancement on various aspects of the Tor network.
## Audience
This proposal is largely designed for users who interact with Tor via the `DNSPort` or through Onionmasq's virtual DNS proxy. In this context, the additional round-trip time for DNS requests and responses is not a significant concern, as it is an expected characteristic of the VPN environment.
## Compatibility Considerations
A key requirement of this proposal is to maintain compatibility with common DNS debugging tools such as `dig` and `drill`. Users should be able to continue using these tools to troubleshoot the DNS layer in Tor, whether they're connecting through Tor's `DNSPort` or Onionmasq's virtual VPN DNS server.
# New DNS Records
This section outlines the additional DNS record types we propose to incorporate into the Tor protocol's DNS layer. Implementing these changes will require updates to the "Remote hostname lookup" section (6.4) of the `tor-spec.txt` document. Specifically, the new types need to be added in addition to the response format.
It's important to note that until fragmented cells are supported in C Tor, responses may be truncated due to Tor's cell size limitations.
## HTTPS and SVCB Records
In RFC 9460, the IETF defines the SVCB and HTTPS DNS resource records (RR).
These records are important in the VPN context to allow web application authors to both provide alternative ports to connect to for HTTP resources, but more importantly, it can be used together with modern HTTP implementation APIs to send pre-flight requests to determine if an end-point supports HTTP/3 (HTTP-over-Quic/UDP) as an alternative to HTTP-over-TCP. This is needed for additional usage of the UDP feature defined in proposal #348.
Although the wire format is defined in RFC 9460 section 2.2, Tor does not need to parse the wire format; it should simply propagate the response payload to the client.
Tor is currently limited to the 509 bytes per cell, which may be insufficient for complex payloads. Until fragmented cells are supported network-wide, Tor SHOULD trim over-sized payloads to fit within the 509-bit limit.
# Security Implications
DNS represents a potential attack vector for adversaries seeking to cause harm to the Tor network. As we expand DNS capabilities, we must carefully consider and mitigate associated security risks.
## Denial of Service (DoS) Attacks
A major risk involving DNS is Denial of Service attacks. In particular, amplification attacks are a powerful way where an adversary with relatively little effort and request size can cause an exit node to be flooded with significantly larger response sizes from its DNS provider, thus blocking its uplink with DNS responses instead of more useful traffic.
While Tor's relatively conservative support of the DNS protocol has mitigated this risk, past DoS attacks have targeted exit nodes with flooding DNS requests.
## Amplification Attacks
Because we are adding support for new types where the request-to-response ratio is different from the currently supported types (A, AAAA, and PTR), there is a potential for attackers to exploit these new record types to amplify their attacks more effectively. As such, we need to be cautious and implement feature toggles can be used to disable the ability to utilize certain record types, and keep track of the request-to-response ratio in the network.
## Mitigation Strategies
It is important that when this proposal is implemented, that we ensure the following:
1. Monitoring and Metrics: We MUST implement Tor's internal MetricsPort features to keep track of both the request type, the request size, and the response sizes. This will allow us to analyze DNS request-to-response ratios together with the Exit node operator community and determine if some DNS types are more prone to abuse than others.
We suggest the following records to be exposed via the MetricsPort (naming can be changed later):
``` dns_lookup_count{type=rr} = n dns_lookup_request_size{type=rr} = n dns_lookup_response_size{type=rr} = n ```
Where `rr` is all of A, AAAA, PTR, and SVCB/HTTPS.
2. Anomaly Detection: Network health SHOULD utilize these metrics to develop systems to detect unusual patterns in DNS request volume and implement automated alerts for potential attacks.
2. Feature Toggles: We MUST ensure that the directory authorities have the ability to disable specific DNS types globally in the network in case of catastrophic abuse of the feature. This can be done using consensus parameters.
3. Response Size Limits: We MUST enforce strict limits on DNS response sizes, especially for the new record types, and implement intelligent truncation for over-sized responses.
4. Rate Limiting: Consider implementing per-client and per-record-type rate limiting for DNS requests. Consider adaptive rate limiting based on network conditions and observed patterns.
5. Periodic Auditing: Regularly review and update security measures as new threats emerge. Conduct periodic testing focused on DNS-related vulnerabilities.
# Implementation Recommendations
1. Phased Rollout: Introduce new DNS capabilities gradually, monitoring for abuse at each stage.
2. Configurable Limits: Allow node operators to set custom limits on DNS usage.
3. Fallback Mechanisms: Implement fallback to basic DNS functionality if abuse is detected.
4. Collaborative Defense: Engage with the Network Health and Community team for developing analysis, response and coordination with the Exit operator community.
# External References
1. Cloudflare wrote a blog post of the usage of HTTPS records in https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dn...
2. PowerDNS already implemented automatic hints for SVCB records in their software. See: https://doc.powerdns.com/authoritative/guides/svcb.html#svc-autohints
# Testing and Debugging
Cloudflare has SVCB enabled on `blog.cloudflare.com` and `crypto.cloudflare.com`. Their record can be seen using:
$ dig blog.cloudflare.com -t TYPE65
If you have `drill` installed with modern HTTPS/SVCB support, you can also query it with a nicer response using:
$ drill HTTPS blog.cloudflare.com
This should make it easier to test the feature.
--- snip ---