dirmngr DNS resolution strategy
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Thu Oct 27 00:39:25 CEST 2016
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 --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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 930 bytes
Desc: not available
More information about the Gnupg-devel