DNS Lookups == Number of Concurrent Connections

[huntharo]

Motivations

• The n DNS requests for n concurrent connections are not necessarily useful and skew the performance results for short tests (e.g. -z 10s or -z 20s)
• Sending 100-400 DNS packets in under 1 second can lead to rate limiting and drop/retries (typically defaulting to 5 seconds for UDP DNS requests that are dropped to be retried, but not confirmed with the library in use in this case)
  • For example, an AWS VPC DNS will blackhole DNS packets beyond 1000 requests in one second from any single source IP - If oha is run on an EC2 instance with other processes running, it could easily cause DNS requests for that machine to fail completely, for a few seconds, by breaching this aggregate limit
• It would be a rare DNS record that did both of the following:
  • Had more than 100 unique IPs to cycle through for a single geographically located source IP
  • Was not cached by the recursive DNS resolver used by the client, allowing the variation in values to get all the way back to the client (e.g. Google Public DNS is going to cache the results and serve the same answer to you for the TTL and you can watch the TTL count dropping as you keep querying the same record such as dig @8.8.8.8 www.shutterstock.com)
• CloudFront has hundreds of thousands of IPs, but from a single source location, for a few minutes of time, you're only going to see the ~4-8 of them within a 60 second period for any single target site
• oha is already picking a random IP out of the DNS answer, which is best practice 👍

Proposals

• Simple:
  • Personally I would select this option as it is easiest and I think it's a better solution that potentially making up to 400 DNS requests in parallel by default
  • Always only make 1 DNS request and continue selecting a random IP from the result for each connection, possibly give a CLI option to make 1 request per connection (existing behavior)
• Complex:
  • Under 10 connections, make 1 DNS request as above
  • Over 10 connections: make 10% as many DNS requests as there are connections, but no more than 10 DNS requests in total, in parallel, take the answers, de-duplicate the IPs, and select random IPs out of that set
  • For 400 connections this would make 10 DNS requests and get either the same IPs for all of them (most likely), or it would get semi-unique values for some of the requests and have up to 250 unique IPs to choose from (up to 25 A records in each response, but more typically no more than 8-10)
• Super Complex:
  • I think this is beyond overkill
  • Start out same as complex
  • Add a degenerate case catch for when, say, 90% of the IPs collected from the 2-10 parallel DNS requests are unique: when that happens, fail open and make n - (# of DNS requests made already) more DNS requests before making the TCP connections and use the de-duped IPs out of that for random IPs for each connection

Screenshot of Sending 100 Repeat DNS Requests for 100 Connections

[hatoo]

@huntharo Nice catch! I've come up with a solution. Please see #391