dirmngr DNS resolution strategy

[Neal H. Walfield]

Hi Daniel,

Thanks for raising this issue.  Since it was never replied to, I've
opened issue 2907 so that your comments don't get completely lost.

  https://bugs.gnupg.org/gnupg/issue2907

Thanks!

:) Neal

On Thu, 27 Oct 2016 00:39:25 +0200,
Daniel Kahn Gillmor wrote:
> 
> [1  <multipart/signed (7bit)>]
> [1.1  <text/plain (quoted-printable)>]
> 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
> [1.2 signature.asc <application/pgp-signature (7bit)>]
> Signature made by expired key 24ECFF5AFF68370A Daniel Kahn Gillmor <dkg at fifthhorseman.net>
> [2  <text/plain; us-ascii (7bit)>]
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel