DNS queries over TCP create a new socket per query, exhausting the available file descriptors

[postmodern]

I noticed when performing many queries over TCP (ex: [:tcp, '8.8.8.8', 53]) that the ruby process would create a new TCP socket per-query. These TCP sockets would not be closed fast enough (ex; waiting in TIME_WAIT), and would eventually cause the process to hit it's maximum number of open file descriptors (ex: Errno::EADDRNOTAVAIL).

Steps To Reproduce

1. ruby test.rb
2. In another terminal run watch "netstat -n" to observe connections

Gemfile

source 'https://rubygems.org/'

gem 'async-dns'

test.rb

require 'bundler/setup'
require 'async/dns'

nameservers = [[:tcp, '8.8.8.8', 53]]
resolver = Async::DNS::Resolver.new(nameservers)
hostname = 'google.com'

Async do
  loop do
    begin
      addresses = resolver.addresses_for(hostname)
    rescue Async::DNS::ResolutionFailure
    end
  end
end

Note: if :tcp is changed to :udp, then only one socket is created and reused.

[ioquatix]

This gem doesn't use a pool, we should update it - it's based on a 10 year old code base which didn't have access to such a abstraction at the time.

[postmodern]

I was looking through the code and it appears that UDP "sockets" are reused, where as the TCP "sockets" are used to create a new Transport for each request.

async-dns/lib/async/dns/resolver.rb

Lines 214 to 230 in 075264b

	def try_datagram_server(request, socket)
	socket.sendmsg(request.packet, 0)
	data, peer = socket.recvmsg(UDP_TRUNCATION_SIZE)
	return Async::DNS::decode_message(data)
	end
	def try_stream_server(request, socket)
	transport = Transport.new(socket)
	transport.write_chunk(request.packet)
	input_data = transport.read_chunk
	return Async::DNS::decode_message(input_data)
	end

[ioquatix]

I will sort this out but it won't be this month probably, I have a lot on my plate, but I'll clear some time to review this during February.