dirmngr DNS resolution strategy

Neal H. Walfield neal at walfield.org
Fri Jan 6 13:03:00 CET 2017

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.



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

More information about the Gnupg-devel mailing list