dirmngr DNS resolution strategy
Neal H. Walfield
neal at walfield.org
Fri Jan 6 13:03:00 CET 2017
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.
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
> c) dirmngr subsequently looked up PTR records for each of those
> 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?
> [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
More information about the Gnupg-devel