dirmngr: proxy issues with dnslookup causing failure
Closed, InvalidPublic
Actions

Assigned To

Authored By

	gekkoman
	Apr 6 2017, 4:37 AM

Description

When trying to use dirmngr behind corporate firewall will not connect to proxy server due to dns failures.

gnupg is version 2.1.20-1, Arch linux std package

To reproduce:

On Corp network.....only local dns lookup, no remote lookup
All internet traffic via proxy (http/https ports only)
Environment http_proxy etc set eg wget www.google.com will return index.html from cli.

dirmngr.conf

honor-http-proxy

dirmngr

dirmngr[12889.0]: permanently loaded certificates: 158
dirmngr[12889.0]: runtime cached certificates: 0
dirmngr[12889.0]: trusted certificates: 158 (157,0,0,1)

Home: /root/.gnupg
Config: /root/.gnupg/dirmngr.conf

OK Dirmngr 2.1.20 at your service
KEYSERVER hkp://p80.pool.sks-keyservers.net:80
OK
KS_SEARCH anything
dirmngr[12889.0]: resolving 'p80.pool.sks-keyservers.net' failed: Server indicated a failure
dirmngr[12889.0]: number of system provided CAs: 167
dirmngr[12889.0]: can't connect to '10.10.3.137': no IP address for host
dirmngr[12889.0]: error connecting to 'http://p80.pool.sks-keyservers.net:80': Unknown host
dirmngr[12889.0]: marking host 'p80.pool.sks-keyservers.net' as dead
dirmngr[12889.0]: host 'p80.pool.sks-keyservers.net' marked as dead
dirmngr[12889.0]: command 'KS_SEARCH' failed: No keyserver available
ERR 167772346 No keyserver available <Dirmngr>

Obviously it can't find my proxy server address........it assumes it is a host instead of an IP address. DOH!

So change proxy setting to hostname instead of IP .....no change still cannot find ip for host.......resolves fine from cli.......is a proper dns lookup not a host file lookup.

Ok assume pass through proxy is broken. So lets force use of internal proxy setting.

Change dirmngr.conf to both

http-proxy <valid local dns name with reverse lookup>:3128

or http-proxy <valid proxy ip address>:3128

No change in behaviour.

Double checks

ping <valid local dns name with reverse lookup>

works

ping <valid proxy ip address>

works

host <ip of resolved server>

returns reverse lookup entry of <valid local dns name with reverse lookup>

Looks like something is seriously borked.

Event Timeline

gekkoman created this task.Apr 6 2017, 4:37 AM

gekkoman created this object in space S1 Public.

justus triaged this task as Normal priority.Jun 8 2017, 12:38 PM

justus added a project: gnupg (gpg22).

Is this still a problem with 2.2.1? IIRC, we fixed a few DNS things.

• werner added a project: Info Needed.Oct 26 2017, 1:05 PM

No more info received - assuming this has been fixed after 1.2.20

Hi,

same behavior on gpg 2.2.1

C:\>gpg --version
gpg (GnuPG) 2.2.1
libgcrypt 1.8.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later https://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: C:/Users/x/AppData/Roaming/gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,

CAMELLIA128, CAMELLIA192, CAMELLIA256

Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

C:\>dirmngr --version
dirmngr (GnuPG) 2.2.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later https://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

C:\>gpg --search-keys dadada
gpg: no keyserver known (use option --keyserver)
gpg: keyserver search failed: No keyserver available

dirmngr running in the background:

C:\>dirmngr --daemon -v --debug-level guru --http-proxy proxy.x.com:8080
dirmngr[13344]: enabled debug flags: x509 crypto memory cache memstat hashing ipc dns network lookup extprog
dirmngr[13344]: error opening 'C:\Users\x\AppData\Roaming\gnupg\dirmngr_ldapservers.conf': No such file or directory
dirmngr[13344]: listening on socket 'C:\Users\x\AppData\Roaming\gnupg\S.dirmngr'
dirmngr[13344]: DBG: certificate 'ROOT' already cached
dirmngr[13344]: DBG: number of certs loaded from store 'ROOT': 54
dirmngr[13344]: DBG: certificate 'CA' already cached
dirmngr[13344]: DBG: certificate 'CA' already cached
dirmngr[13344]: DBG: number of certs loaded from store 'CA': 35
dirmngr[13344]: permanently loaded certificates: 90
dirmngr[13344]: runtime cached certificates: 0
dirmngr[13344]: trusted certificates: 90 (89,0,0,1)
dirmngr[13344]: handler for fd 320 started
dirmngr[13344]: DBG: chan_0x00000140 -> # Home: C:\Users\x\AppData\Roaming\gnupg
dirmngr[13344]: DBG: chan_0x00000140 -> # Config: C:\Users\x\AppData\Roaming\gnupg\dirmngr.conf
dirmngr[13344]: DBG: chan_0x00000140 -> OK Dirmngr 2.2.1 at your service
dirmngr[13344]: DBG: chan_0x00000140 <- GETINFO version
dirmngr[13344]: DBG: chan_0x00000140 -> D 2.2.1
dirmngr[13344]: DBG: chan_0x00000140 -> OK
dirmngr[13344]: DBG: chan_0x00000140 <- KS_SEARCH -- dadada
dirmngr[13344]: resolving 'hkps.pool.sks-keyservers.net' failed: No name
dirmngr[13344]: can't connect to 'proxy.x.com': no IP address for host
dirmngr[13344]: error connecting to 'https://hkps.pool.sks-keyservers.net:443': Unknown host
dirmngr[13344]: marking host 'hkps.pool.sks-keyservers.net' as dead
dirmngr[13344]: resolving 'hkps.pool.sks-keyservers.net' failed: No name
dirmngr[13344]: host 'hkps.pool.sks-keyservers.net' marked as dead
dirmngr[13344]: command 'KS_SEARCH' failed: No keyserver available
dirmngr[13344]: DBG: chan_0x00000140 -> ERR 167772346 No keyserver available <Dirmngr>
dirmngr[13344]: DBG: chan_0x00000140 <- BYE
dirmngr[13344]: DBG: chan_0x00000140 -> OK closing connection
dirmngr[13344]: handler for fd 320 terminated
set DIRMNGR_INFO=C:\Users\x\AppData\Roaming\gnupg\S.dirmngr;13344;1
^C

proxy: proxy.x.com is resolvable from cmd and operational (tested with wget)

@Ainahir thanks for the info. However, your problem might be different because you are on Windows and not on Linux.
Please use for dirmngr --debug=ipc,dns instead of --debug-level=guru

There might be a problem with IPv4 vs. IPv6, so please try also with the options --disable-ipv4 and --disable-ipv6.

• werner edited projects, added dirmngr, dns; removed Info Needed.Feb 27 2018, 3:45 PM

@werner Problem persists (same results with disabling ipv4 or ipv6

What I can observe or conclude from the logs:
1.Attempt to resolve key server happens before resolving proxy (is it to try connecting directly without the proxy?)
2.proxy address is resolved
3.proxy IP address is not passed to connecting routine and connection to proxy fails
4.subsequent connection attempts fail due to proxy bypass (since no connection)

C:\>dirmngr --daemon -v --debug=ipc,dns --http-proxy proxy.x.com:8080
dirmngr[3980]: reading options from 'C:\Users\x\AppData\Roaming\gnupg\dirmngr.conf'
dirmngr[3980]: enabled debug flags: ipc dns
dirmngr[3980]: error opening 'C:\Users\x\AppData\Roaming\gnupg\dirmngr_ldapservers.conf': No such file or directory
dirmngr[3980]: listening on socket 'C:\Users\x\AppData\Roaming\gnupg\S.dirmngr'
dirmngr[3980]: permanently loaded certificates: 90
dirmngr[3980]: runtime cached certificates: 0
dirmngr[3980]: trusted certificates: 90 (89,0,0,1)
dirmngr[3980]: handler for fd 320 started
dirmngr[3980]: DBG: chan_0x00000140 -> # Home: C:\Users\x\AppData\Roaming\gnupg
dirmngr[3980]: DBG: chan_0x00000140 -> # Config: C:\Users\x\AppData\Roaming\gnupg\dirmngr.conf
dirmngr[3980]: DBG: chan_0x00000140 -> OK Dirmngr 2.2.1 at your service
dirmngr[3980]: DBG: chan_0x00000140 <- GETINFO version
dirmngr[3980]: DBG: chan_0x00000140 -> D 2.2.1
dirmngr[3980]: DBG: chan_0x00000140 -> OK
dirmngr[3980]: DBG: chan_0x00000140 <- KS_SEARCH -- dadada
dirmngr[3980]: DBG: dns: dnsserver[0] '131.97.140.4'
dirmngr[3980]: DBG: dns: dnsserver[1] '131.97.143.4'
dirmngr[3980]: DBG: dns: dnsserver[2] '172.31.250.1'
dirmngr[3980]: DBG: dns: libdns initialized
dirmngr[3980]: DBG: dns: getsrv(_pgpkey-https._tcp.hkps.pool.sks-keyservers.net) -> 0 records
dirmngr[3980]: DBG: dns: resolve_dns_name(hkps.pool.sks-keyservers.net): No name
dirmngr[3980]: resolving 'hkps.pool.sks-keyservers.net' failed: No name
dirmngr[3980]: DBG: dns: resolve_dns_name(proxy.x.com): Success
dirmngr[3980]: can't connect to 'proxy.x.com': no IP address for host
//dirmngr[3980]: error connecting to 'https://hkps.pool.sks-keyservers.net:443': Unknown host
dirmngr[3980]: marking host 'hkps.pool.sks-keyservers.net' as dead
dirmngr[3980]: DBG: dns: resolve_dns_name(hkps.pool.sks-keyservers.net): No name
dirmngr[3980]: resolving 'hkps.pool.sks-keyservers.net' failed: No name
dirmngr[3980]: host 'hkps.pool.sks-keyservers.net' marked as dead
dirmngr[3980]: command 'KS_SEARCH' failed: No keyserver available
dirmngr[3980]: DBG: chan_0x00000140 -> ERR 167772346 No keyserver available <Dirmngr>
dirmngr[3980]: DBG: chan_0x00000140 <- BYE
dirmngr[3980]: DBG: chan_0x00000140 -> OK closing connection
dirmngr[3980]: handler for fd 320 terminated
set DIRMNGR_INFO=C:\Users\x\AppData\Roaming\gnupg\S.dirmngr;3980;1
^C

C:\>dirmngr --daemon -v --disable-ipv6 --debug=ipc,dns --http-proxy proxy.x.com:8080
dirmngr[5252]: reading options from 'C:\Users\x\AppData\Roaming\gnupg\dirmngr.conf'
dirmngr[5252]: enabled debug flags: ipc dns
dirmngr[5252]: error opening 'C:\Users\x\AppData\Roaming\gnupg\dirmngr_ldapservers.conf': No such file or directory
dirmngr[5252]: listening on socket 'C:\Users\x\AppData\Roaming\gnupg\S.dirmngr'
dirmngr[5252]: permanently loaded certificates: 90
dirmngr[5252]: runtime cached certificates: 0
dirmngr[5252]: trusted certificates: 90 (89,0,0,1)
dirmngr[5252]: handler for fd 320 started
dirmngr[5252]: DBG: chan_0x00000140 -> # Home: C:\Users\x\AppData\Roaming\gnupg
dirmngr[5252]: DBG: chan_0x00000140 -> # Config: C:\Users\x\AppData\Roaming\gnupg\dirmngr.conf
dirmngr[5252]: DBG: chan_0x00000140 -> OK Dirmngr 2.2.1 at your service
dirmngr[5252]: DBG: chan_0x00000140 <- GETINFO version
dirmngr[5252]: DBG: chan_0x00000140 -> D 2.2.1
dirmngr[5252]: DBG: chan_0x00000140 -> OK
dirmngr[5252]: DBG: chan_0x00000140 <- KS_SEARCH -- dadada
dirmngr[5252]: DBG: dns: dnsserver[0] '131.97.140.4'
dirmngr[5252]: DBG: dns: dnsserver[1] '131.97.143.4'
dirmngr[5252]: DBG: dns: dnsserver[2] '172.31.250.1'
dirmngr[5252]: DBG: dns: libdns initialized
dirmngr[5252]: DBG: dns: getsrv(_pgpkey-https._tcp.hkps.pool.sks-keyservers.net) -> 0 records
dirmngr[5252]: DBG: dns: resolve_dns_name(hkps.pool.sks-keyservers.net): No name
dirmngr[5252]: resolving 'hkps.pool.sks-keyservers.net' failed: No name
dirmngr[5252]: DBG: dns: resolve_dns_name(proxy.x.com): Success
dirmngr[5252]: can't connect to 'proxy.x.com': no IP address for host
dirmngr[5252]: error connecting to 'https://hkps.pool.sks-keyservers.net:443': Unknown host
dirmngr[5252]: marking host 'hkps.pool.sks-keyservers.net' as dead
dirmngr[5252]: DBG: dns: resolve_dns_name(hkps.pool.sks-keyservers.net): No name
dirmngr[5252]: resolving 'hkps.pool.sks-keyservers.net' failed: No name
dirmngr[5252]: host 'hkps.pool.sks-keyservers.net' marked as dead
dirmngr[5252]: command 'KS_SEARCH' failed: No keyserver available
dirmngr[5252]: DBG: chan_0x00000140 -> ERR 167772346 No keyserver available <Dirmngr>
dirmngr[5252]: DBG: chan_0x00000140 <- BYE
dirmngr[5252]: DBG: chan_0x00000140 -> OK closing connection
dirmngr[5252]: handler for fd 320 terminated
set DIRMNGR_INFO=C:\Users\x\AppData\Roaming\gnupg\S.dirmngr;5252;1
^C

C:\>dirmngr --daemon -v --disable-ipv4 --debug=ipc,dns --http-proxy proxy.x.com:8080
dirmngr[9832]: reading options from 'C:\Users\x\AppData\Roaming\gnupg\dirmngr.conf'
dirmngr[9832]: enabled debug flags: ipc dns
dirmngr[9832]: error opening 'C:\Users\x\AppData\Roaming\gnupg\dirmngr_ldapservers.conf': No such file or directory
dirmngr[9832]: listening on socket 'C:\Users\x\AppData\Roaming\gnupg\S.dirmngr'
dirmngr[9832]: permanently loaded certificates: 90
dirmngr[9832]: runtime cached certificates: 0
dirmngr[9832]: trusted certificates: 90 (89,0,0,1)
dirmngr[9832]: handler for fd 320 started
dirmngr[9832]: DBG: chan_0x00000140 -> # Home: C:\Users\x\AppData\Roaming\gnupg
dirmngr[9832]: DBG: chan_0x00000140 -> # Config: C:\Users\x\AppData\Roaming\gnupg\dirmngr.conf
dirmngr[9832]: DBG: chan_0x00000140 -> OK Dirmngr 2.2.1 at your service
dirmngr[9832]: DBG: chan_0x00000140 <- GETINFO version
dirmngr[9832]: DBG: chan_0x00000140 -> D 2.2.1
dirmngr[9832]: DBG: chan_0x00000140 -> OK
dirmngr[9832]: DBG: chan_0x00000140 <- KS_SEARCH -- dadada
dirmngr[9832]: DBG: dns: dnsserver[0] '131.97.140.4'
dirmngr[9832]: DBG: dns: dnsserver[1] '131.97.143.4'
dirmngr[9832]: DBG: dns: dnsserver[2] '172.31.250.1'
dirmngr[9832]: DBG: dns: libdns initialized
dirmngr[9832]: DBG: dns: getsrv(_pgpkey-https._tcp.hkps.pool.sks-keyservers.net) -> 0 records
dirmngr[9832]: DBG: dns: resolve_dns_name(hkps.pool.sks-keyservers.net): No name
dirmngr[9832]: resolving 'hkps.pool.sks-keyservers.net' failed: No name
dirmngr[9832]: DBG: dns: resolve_dns_name(proxy.x.com): Success
dirmngr[9832]: can't connect to 'proxy.x.com': no IP address for host
dirmngr[9832]: error connecting to 'https://hkps.pool.sks-keyservers.net:443': Unknown host
dirmngr[9832]: marking host 'hkps.pool.sks-keyservers.net' as dead
dirmngr[9832]: DBG: dns: resolve_dns_name(hkps.pool.sks-keyservers.net): No name
dirmngr[9832]: resolving 'hkps.pool.sks-keyservers.net' failed: No name
dirmngr[9832]: host 'hkps.pool.sks-keyservers.net' marked as dead
dirmngr[9832]: command 'KS_SEARCH' failed: No keyserver available
dirmngr[9832]: DBG: chan_0x00000140 -> ERR 167772346 No keyserver available <Dirmngr>
dirmngr[9832]: DBG: chan_0x00000140 <- BYE
dirmngr[9832]: DBG: chan_0x00000140 -> OK closing connection
dirmngr[9832]: handler for fd 320 terminated
set DIRMNGR_INFO=C:\Users\x\AppData\Roaming\gnupg\S.dirmngr;9832;1
^C//

The stripped down log is

dirmngr[3980]: DBG: dns: dnsserver[0] '131.97.140.4'
dirmngr[3980]: DBG: dns: dnsserver[1] '131.97.143.4'
dirmngr[3980]: DBG: dns: dnsserver[2] '172.31.250.1'
dirmngr[3980]: DBG: dns: libdns initialized
dirmngr[3980]: DBG: dns: getsrv(_pgpkey-https._tcp.hkps.pool.sks-keyservers.net) -> 0 records
dirmngr[3980]: DBG: dns: resolve_dns_name(hkps.pool.sks-keyservers.net): No name
dirmngr[3980]: resolving 'hkps.pool.sks-keyservers.net' failed: No name
dirmngr[3980]: DBG: dns: resolve_dns_name(proxy.x.com): Success
dirmngr[3980]: can't connect to 'proxy.x.com': no IP address for host

So you have 3 configured resolvers. They are not able to resolve the sks-keyserver.net names. They are able to resolve proxy.x.com but finally no IP addresses are found (SRV records issue?). Next step to debug this is to use

--debug=ipc,dns,network  --verbose

which will also show http detail. No need to test with --disable-ip* . Note that an HTTP proxy is independent of the DNS resolver because it works at the HTTP layer.

Just to clarify:
1.I'm behind corporate network
2.Network resolves only local addresses, so this is correct: dirmngr[7416]: resolving 'hkps.pool.sks-keyservers.net' failed: No name
3.Network address of the proxy is resolvable (I can see it's address and it responds to ping
4.Internet browser without proxy will not work
5,Internet browser with the proxy below works
6.When using gpg on this computer outside of corporate network everything works

C:\>dirmngr --daemon --debug=ipc,dns,network --verbose --http-proxy proxy.x.com:8080
<cut>
dirmngr[7416]: DBG: dns: libdns initialized
dirmngr[7416]: DBG: dns: getsrv(_pgpkey-https._tcp.hkps.pool.sks-keyservers.net) -> 0 records
dirmngr[7416]: DBG: dns: resolve_dns_name(hkps.pool.sks-keyservers.net): No name
dirmngr[7416]: resolving 'hkps.pool.sks-keyservers.net' failed: No name
dirmngr[7416]: DBG: http.c:connect_server: trying name='proxy.x.com' port=8080
dirmngr[7416]: DBG: dns: resolve_dns_name(proxy.x.com): Success
dirmngr[7416]: can't connect to 'proxy.x.com': no IP address for host
dirmngr[7416]: error connecting to 'https://hkps.pool.sks-keyservers.net:443': Unknown host
dirmngr[7416]: marking host 'hkps.pool.sks-keyservers.net' as dead
<cut>

Well, if your proxy inhibits GnuPG to retrieve information about the keyservers, GnuPG can't do anything about it.

I did some digging with Wireshark:

there are DNS queries for proxy records A & AAAA (ipv4 & ipv6 - both regardless of --disable-ipv6)
DNS reply returns correct IP address in A record
there are no outgoing connections to proxy IP address

considering above it's not a proxy problem - it is software not connecting to proxy

That will be the IP of proxy.x.com - the log shows that it finds that. But the log also shows that it can't find the address for the other names. "No Name" is EAI_NONAME.

I think we did not yet tried the option --standard-resolver which uses the system resolver and not dirmngr's own one.

I am running into the same exact issue. It seems that dirmng is incorrectly attempting to resolve the addresses for the keyservers despite having been given an HTTP proxy to connect through.

This is what I am running:

$ gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv 2EE0EA64E40A89B84B2DF73499E82A75642AC823
gpg: keyserver receive failed: No keyserver available

Output from dirmngr.log:

$ cat ~/.gnupg/dirmngr.log
2018-08-21 11:31:15 dirmngr[5962.0] permanently loaded certificates: 139
2018-08-21 11:31:15 dirmngr[5962.0] runtime cached certificates: 0
2018-08-21 11:31:15 dirmngr[5962.0] trusted certificates: 139 (138,0,0,1)
2018-08-21 11:31:15 dirmngr[5962.6] handler for fd 6 started
2018-08-21 11:31:15 dirmngr[5962.6] DBG: chan_6 -> # Home: /home/wlaw/.gnupg
2018-08-21 11:31:15 dirmngr[5962.6] DBG: chan_6 -> # Config: /home/wlaw/.gnupg/dirmngr.conf
2018-08-21 11:31:15 dirmngr[5962.6] DBG: chan_6 -> OK Dirmngr 2.2.4 at your service
2018-08-21 11:31:15 dirmngr[5962.6] connection from process 5961 (1000:1000)
2018-08-21 11:31:15 dirmngr[5962.6] DBG: chan_6 <- GETINFO version
2018-08-21 11:31:15 dirmngr[5962.6] DBG: chan_6 -> D 2.2.4
2018-08-21 11:31:15 dirmngr[5962.6] DBG: chan_6 -> OK
2018-08-21 11:31:15 dirmngr[5962.6] DBG: chan_6 <- KEYSERVER --clear hkp://keyserver.ubuntu.com:80
2018-08-21 11:31:15 dirmngr[5962.6] DBG: chan_6 -> OK
2018-08-21 11:31:15 dirmngr[5962.6] DBG: chan_6 <- KS_GET -- 0x2EE0EA64E40A89B84B2DF73499E82A75642AC823
2018-08-21 11:31:15 dirmngr[5962.6] DBG: get_dns_cname(keyserver.ubuntu.com): No name
2018-08-21 11:31:15 dirmngr[5962.6] DBG: dns: resolve_dns_name(keyserver.ubuntu.com): No name
2018-08-21 11:31:15 dirmngr[5962.6] resolving 'keyserver.ubuntu.com' failed: No name
2018-08-21 11:31:15 dirmngr[5962.6] number of system provided CAs: 138
2018-08-21 11:31:15 dirmngr[5962.6] DBG: http.c:connect_server: trying name='localhost' port=3128
2018-08-21 11:31:15 dirmngr[5962.6] DBG: dns: resolve_dns_name(localhost): Success
2018-08-21 11:31:15 dirmngr[5962.6] can't connect to 'localhost': no IP address for host
2018-08-21 11:31:15 dirmngr[5962.6] error connecting to 'http://keyserver.ubuntu.com:80': Unknown host
2018-08-21 11:31:15 dirmngr[5962.6] marking host 'keyserver.ubuntu.com' as dead
2018-08-21 11:31:15 dirmngr[5962.6] DBG: get_dns_cname(keyserver.ubuntu.com): No name
2018-08-21 11:31:15 dirmngr[5962.6] DBG: dns: resolve_dns_name(keyserver.ubuntu.com): No name
2018-08-21 11:31:15 dirmngr[5962.6] resolving 'keyserver.ubuntu.com' failed: No name
2018-08-21 11:31:15 dirmngr[5962.6] host 'keyserver.ubuntu.com' marked as dead
2018-08-21 11:31:15 dirmngr[5962.6] command 'KS_GET' failed: No keyserver available
2018-08-21 11:31:15 dirmngr[5962.6] DBG: chan_6 -> ERR 167772346 No keyserver available <Dirmngr>
2018-08-21 11:31:15 dirmngr[5962.6] DBG: chan_6 <- BYE
2018-08-21 11:31:15 dirmngr[5962.6] DBG: chan_6 -> OK closing connection
2018-08-21 11:31:15 dirmngr[5962.6] handler for fd 6 terminated

This is my ~/.gnupg/dirmngr.conf:
log-file /home/wlaw/.gnupg/dirmngr.log
verbose
debug all
standard-resolver

I tried without the standard resolver, and I get the same problem.

Good to see that gpg is picking up the http_proxy variable, however it looks like the HTTP client isn't handling proxy variables correctly with regards to DNS.

A workaround for this until the HTTP client is fixed is to just use curl instead:

$ curl -fsSL "https://keyserver.ubuntu.com/pks/lookup?op=get&options=mr&search=0x2EE0EA64E40A89B84B2DF73499E82A75642AC823" | gpg --import
gpg: key 99E82A75642AC823: public key "sbt build tool <scalasbt@gmail.com>" imported
gpg: Total number processed: 1
gpg: imported: 1

If you specify a pool of keyservers dirmngr selects a keyserver on its won from the pool. This is so that it can use its own heuristics to detect whether a keyserver is dead and then retry another one. Now the default is a pool and your specified keyserver.ubuntu.com is also a pool (of two servers). So if your DNS resolver does not tell us the IP addresses, we can't do anything about it.

As a workaround, you can use a single keyserver, e.g. zimmermann.mayfirst.org .

• werner edited projects, added FAQ; removed gnupg (gpg22).Dec 11 2018, 3:48 PM

So if your DNS resolver does not tell us the IP addresses, we can't do anything about it.

Yes you can, you can connect through the specified HTTP proxy, like virtually every other application that handles HTTP proxies correctly.

wheelerlaw edited projects, added gnupg (gpg22); removed FAQ.Dec 14 2018, 7:29 PM

No we can't we need to know the IP addresses to handle the pools. I have given a workaround for you in my previous comment. You can also use install Tor which we can use for DNS resolving.

Yes you can, and no you do not. Don't believe me? Then read the spec. At no point does the spec say that there is "nothing that can be done" when a hostname cannot be resolved when connecting through a proxy. In fact, it states precisely the opposite, describing the exact procedure a client should take when making a request through a proxy. See section 5.3, paragraph 3:

If the request is not satisfied by a cache, then a typical client will check its configuration to determine whether a proxy is to be used to satisfy the request. Proxy configuration is implementation-dependent, but is often based on URI prefix matching, selective authority matching, or both, and the proxy itself is usually identified by an "http" or "https" URI. If a proxy is applicable, the client connects inbound by establishing (or reusing) a connection to that proxy.

So I ask you to please stop being dense. The process that dirmngr uses to select a keyserver from the pool on its own, or that it uses internal heuristics, is irrelevant. The fact of the matter is that dirmngr's HTTP implementation does not conform to the RFC defining correct HTTP communication, and is therefore broken, and needs to be rectified.

I am re-opening this issue because it is now infinitely clear that this is a bug.

Please show an example regarding something else than a failed access to a pool of keyservers. I explained why it can't work for pools for you.

Why? Your explanation is invalid because it implicates dirmngr's HTTP client as not comforming to the spec laid out by the RFC. I've quite clearly explained--and backed up with the spec itself--that when a proxy variable is configured, a client should not be doing DNS lookup of the destination hostname. Is there something about that you are not understanding?

At the very least, dirmngr's should skip the heuristics when a proxy variable is configured so that it can at least attempt to make a connection.

Also might I add, this used to work perfectly fine in gnupg14. It seems that somewhere along the line a regression was introduced that is causing this erroneous non-compliant behavior in the HTTP client.

I explained why the keyserver access requires access to the DNS. If that is not possible the keyserver code will not work. If you don't allow DNS to work you either have to use Tor (which we use to also tunnel DNS requests) or get your keys from elsewhere. Also note that the keyserver network is current several broken and under DoS and thus it is unlikely that it can be operated in the future.

Please do not -re-open this issue again. If you want to discuss the problem you have please use the gnupg mailing lists.

Are you not reading what I am saying to you?? Once again, your explanation is INVALID because that would mean that gnupg would be BROKEN, because it would be a NON-COMPLIANT http client according to the RFC I quoted.

This used to work at one point, then something changed and now it doesn't work. That's called a regression, since it sounds like you don't know what that is. A regression is a Bad Thing, and should be fixed.

Read. My. Responses. I don't know how much simpler I can make this for you, but it seems you are intentionally sandbagging and being difficult and it is most certainly not appreciated.

I asked you to carry this to a mailing list and not re-open this task.

• werner changed the edit policy from "All Users" to "Administrators".Jul 3 2019, 6:19 PM

dirmngr: proxy issues with dnslookup causing failureClosed, InvalidPublicActions

Description

Event Timeline

dirmngr: proxy issues with dnslookup causing failure
Closed, InvalidPublic
Actions