[tor-dev] Proposal: Handling Complex DNS Traffic for VPN usage in Tor

[Alexander Færøy]

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-dns

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 ---

-- 
Alexander Færøy