Adding this report from the ML here so that it does not get lost.

Hi GnuPG folks--

over in T2745 i did a bit of inspection of dirmngr DNS traffic during a simple lookup.

I did this from a temporary GNUPGHOME, via:

GNUPGHOME=$(mktemp -d) gpg-connect-agent --dirmngr

You can do this test yourself with:

keyserver hkps://pool.sks-keyservers.net
keyserver --resolve hkps://pool.sks-keyservers.net

If you record the DNS traffic that results from this, you'll see:

1. SRV records for the pool (_hkp._tcp.hkps.pool.sks-keyservers.net) came back NXDOMAIN
2. as soon as that response came back, dirmngr sent out a request for A records for hkps.pool.sks-keyservers.net, which was fulfilled with 10 addresses
3. dirmngr subsequently looked up PTR records for each of those addressses
4. dirmngr was fine continuing to use some of those 10 addresses.

This is all using the adns library, which should allow for asynchronous DNS requests. I'm assuming that the goal here is for dirmngr to be as fast as possible in its responses.

This raises several questions for me:

1. There's no reason to have the request for A records (step b) sent out *after* the SRV response comes in. Both requests could be sent concurrently, and dirmngr could update its host table with whatever answers it gets. If you prefer SRV records, then discard any A responses that come in after SRV records, while overwriting any A responses that are already present when SRV responses come in.
2. Each of the PTR records looked up in step c were done one after the other. There should be no need to wait on this; if you need PTR records, simply send all 10 PTR requests concurrently, and process them as they come back in. This parallelization will reduce the number of round trips dramatically.
3. More importantly -- why does dirmngr need PTR records at all? what's the advantage of having them? If the user is asking to connect to a pool, doing a reverse DNS lookup just seems to be an additional round trip requirement.
   
   any thoughts?

--dkg