Hi Scott,

On 6/12/25 21:36, Hollenbeck, Scott wrote:
Earlier today I added text describing Verisign's RFC 9539 Experiment to GitHub:

https://github.com/ietf-wg-dprive/9539-data/blob/main/Verisign's%20RFC%209539%20Experiment

Interesting.

Are you also conducting / planning to conduct DoQ experiments?
Have you considered attempting TLS offloading in the kernel?

Best,
Peter

PS: I'm attaching the text file linked above for archiving purposes.
The lightweight and robust nature of DNS over UDP and TCP have enabled it to 
scale well with the growth of DNS transaction volumes over the past several 
decades. As DNS operators are well aware, this is particularly important when 
absorbing flash crowds, aggressive resolver behavior, and perhaps foremost, 
volumetric DDoS attacks. Protocol designers and operators alike should heavily 
weigh the implications of DNSo[*] offerings on the stability and availability 
of core internet services, particularly at the root and TLD levels of the DNS 
hierarchy, versus the benefit they provide. Verisign appreciates DPRIVE's 
emphasis on experimentation at this stage.

# Methodology

- Consistent with public statements made by Verisign, DNS resolution service 
availability remains one of our primary priorities.
- We conducted an experiment during 2024 and 2025 using Verisign’s proprietary 
authoritative name server software and internal environments.
- Our experimentation goal is to measure the impact of DNS over TLS (DoT) 
processing on Verisign’s authoritative name server resolution capabilities.
- Verisign's authoritative name servers are receiving connection attempts on 
TCP/853.  Our name servers are not responding to those connection attempts.
  - During a 7-day period in February, we measured approximately 1.1 billion 
connection attempts on TCP/853 on our servers, with an average of approximately 
1,800 attempts per second. 89% of those attempts were sent from a single 
autonomous system. The rest was received from many sources sending 
significantly fewer requests per autonomous system.
- We reached out to operators to do an experiment with test traffic but were 
unable to reach a mutually satisfying agreement on the goals of an experiment.
- As a result, we conducted our own experimental measurement study to determine 
how adding encryption would affect name server performance.
  - All test queries were synthetic and generated using Verisign proprietary 
tools.
  - All test queries were sent to a single commodity server running Verisign's 
proprietary software for DNS. The DoT implementation used OpenSSL version: 
3.0.15.1.
  - All test queries used the same small (< 100 bytes) packet query/response.
  - All tests used a DNS query for a four-letter .com domain with no EDNS 
options.

# Measurement Results

- Unlike DNS over UDP and TCP, DoT was CPU-bound.
- The maximum QPS for DoT without session re-use was more than three orders of 
magnitude lower than the maximum QPS for DNS over UDP, and almost three orders 
of magnitude lower than DNS over TCP.
- The open-source TLS library we used has internal bottlenecks that limit 
scaling and contributed to DoT hitting a maximum capacity after which more 
allocated CPUs did not increase DoT throughput.
- When we sent both UDP and DoT traffic to the same server, as the number of 
DoT queries increased to this maximum, UDP performance degraded by 44%, i.e., 
UDP became CPU-bound.
- Maximum DoT QPS achieved with session reuse using 2,000 queries/session was 
more than an order of magnitude lower than the maximum QPS achieved for DNS 
over UDP.
  - We didn't measure DNS over TCP session reuse.
_______________________________________________
dns-privacy mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to