dirmngr logging confusion when trying to connect to a local keyserver (more reverse DNS?)

Daniel Kahn Gillmor dkg at fifthhorseman.net
Thu Nov 9 22:29:57 CET 2017


Hi all--

over on reproducible-builds at lists.alioth.debian.org [0], Georg (cc'ed here)
described intermittent failures on some platforms for dirmngr talking to
a locally-configured keyserver running on 127.0.0.1 port 9999.

The most confusing/disturbing part of the logs is here:

   2017-10-01 06:16:58 dirmngr[32208.6] DBG: dns: resolve_dns_addr(): Connection closed in DNS
   2017-10-01 06:16:58 dirmngr[32208.6] resolve_dns_addr failed while checking '127.0.0.1': Connection closed in DNS
   2017-10-01 06:16:58 dirmngr[32208.6] DBG: dns: resolve_dns_name(127.0.0.1): Success
   2017-10-01 06:17:00 dirmngr[32208.6] DBG: dns: resolve_dns_addr(): Success
   2017-10-01 06:17:00 dirmngr[32208.6] number of system provided CAs: 148
   2017-10-01 06:17:00 dirmngr[32208.6] DBG: http.c:connect_server: trying name='127.0.0.1' port=9999
   2017-10-01 06:17:00 dirmngr[32208.6] DBG: dns: resolve_dns_name(127.0.0.1): Success
   2017-10-01 06:17:00 dirmngr[32208.6] can't connect to '127.0.0.1': no IP address for host
   2017-10-01 06:17:00 dirmngr[32208.6] error connecting to 'http://127.0.0.1:9999': Unknown host
   2017-10-01 06:17:00 dirmngr[32208.6] marking host '127.0.0.1' as dead
   2017-10-01 06:17:00 dirmngr[32208.6] DBG: dns: resolve_dns_name(127.0.0.1): Success
   2017-10-01 06:17:01 dirmngr[32208.6] DBG: dns: resolve_dns_addr(): Success
   2017-10-01 06:17:01 dirmngr[32208.6] host '127.0.0.1' marked as dead

Even if the local keyserver wasn't running at all, these log messages
would be (at best) misleading, if not downright confusing.

What do these messages mean?  "no IP address for host" doesn't make
sense when the host is itself an IP address.

I'd understand "Connection refused" (or even "Network is unreachable"
for hosts that don't have a loopback configured), but that's not what is
reported here.

Also, why is dirmngr trying to look up names for addresses? i don't know
whether "resolve_dns_name" is A/AAAA lookup and "resolve_dns_addr" is
PTR lookup or vice versa, but it appears that dirmngr is trying to do
both :/ I thought we'd gotten rid of all the PTR lookups in dirmngr
except for "gpg-connect-agent --dirmngr 'keyserver --hosttable' /bye"

in 2.2.2 it seems to be doing the same thing (learning "localhost" for
127.0.0.1, iiuc).  Perhaps that's contributing to the weird failure
state?  

So it looks to me like there might be (at least) two issues with
dirmngr:

 a) it is still trying to do some kind of reverse DNS lookups.  this
    seems like it can only be a source of failure, and is not a security
    measure.

 b) dirmngr is logging misleading warnings when the state of the reverse
    DNS is not what it is expecting.

I've been unable to replicate this exact failure state locally with
dimrngr 2.2.2 :(

   --dkg



[0] Message-ID: 20171030172139.GG7690 at riseup.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20171109/d50ee48b/attachment-0001.sig>


More information about the Gnupg-devel mailing list