dirmngr DNS resolution strategy

[Daniel Kahn Gillmor]

Hi GnuPG folks--

over in https://bugs.gnupg.org/gnupg/issue2745 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:

 a) SRV records for the pool (_hkp._tcp.hkps.pool.sks-keyservers.net)
    came back NXDOMAIN
   
 b) 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

 c) dirmngr subsequently looked up PTR records for each of those
    addressses

 d) 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:

 0) 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.

 1) 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.

 2) 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL: </pipermail/attachments/20161026/4481b7dc/attachment.sig>