Since the initial redacted data for those four keys is still accessible, I checked all of those keys manually and none of them are on the keyservers. Since the OP was connecting to the specified keyserver successfully prior to that failure, I believe this is the cause of the error and not another DNS vs. Dirmngr conflict.

That slipped my attention due to the missing gpg22 tag I should have added. Sorry.

Is there any ETA for when this might get fixed? We are having the same issue with our keyserver since it's behind a cname.

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 did some digging with Wireshark:

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

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

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

The stripped down log is

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

hm, i think this is the file:

I'm using gnupg 2.2.4 and this problem repros for me, and it impacts downstream things like pacman-key (Arch Linux) quite insidiously, which fails with an misleading error message that would not point a regular user to this line of investigation.

What is the output of

gpg-connect-agent --dirmngr 'getinfo dnsinfo' /bye

and what is the content of your /etc/nsswitch.conf and /etc/resolv.conf ? Is there anything special in your /etc/hosts? Are you using any kind of non mainstream DNS resolver on your system or network?

I am using an Antergos Linux (Arch Linux).

For reference here is @mcgrof's dump in a directly readable format:

00:29:33.472844 IP 192.168.4.7.10218 > 192.168.4.1.domain: 53039+ SRV? _pgpkey-https._tcp.hkps.pool.sks-keyservers.net. (65)
00:29:33.879268 IP 192.168.4.1.domain > 192.168.4.7.10218: 53039 FormErr 0/0/0 (65)
00:29:33.880719 IP 192.168.4.7.10218 > 192.168.4.1.domain: 51133+ Type0 (Class 8448)? _pgpkey-https._tcp.hkps.pool.sks-keyservers.net. (66)
00:29:33.902115 IP 192.168.4.1.domain > 192.168.4.7.10218: 51133 FormErr 0/0/0 (65)

Unconditionally retrying without SRV lookup is not a good idea. SRV record are there for a reason. What we could do is an option to skip SRV record lookups.