with 2.1.7, i see no hang, but i do see failure with certain large certificates,
like 0xB27B944E34884E85:

0 dkg@alice:~$ gpg2 --send 0xB27B944E34884E85
gpg: sending key 0xB27B944E34884E85 to hkps server hkps.pool.sks-keyservers.net
gpg: keyserver send failed: Too much data for IPC layer
gpg: keyserver send failed: Too much data for IPC layer
2 dkg@alice:~$

maybe the boundary is 500KiB? I don't have this problem with my own OpenPGP cert:

0 dkg@alice:~$ gpg2 --export 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 | wc

3126   11384  481051

0 dkg@alice:~$ gpg2 --export 0xB27B944E34884E85 | wc

4310   13779  541937

0 dkg@alice:~$

Re-assigning to gnupg. libassuan works correctly, afaics.
When trying to send back Zack's key I had the same problem last week and
increased the limit in dirmngr (84f4c8811fc5bdd78693c4dc289389a8337cc257).
I also mentioned that in a comment to another Debian bug report.

However, their should not be a hang but a proper error diagnostic; it is on my list.

Oh well, the hang is indeed a libassuan bug. The assuan_inquire fucntion
stopped reading as soon as a supplied limit was reached and returned to the
caller. The caller (dirmngr), printed an error and sends back an ERR line.
Hwoever, the client kept on sending the remaining lines and thus messed uo the
protocol.

Just fixed it in libassuan (5a52404) by reading up the extra lines before
returing from assuan_inquire.

The limit set by dirmngr is in general useful. Shall we make the limit
configurable at runtime?

can you explain why the limit is useful? e.g. does it increase efficiency in
some metric? defend against certain classes of attack? something else? sorry
that i don't understand the tradeoff fully.

a runtime configuration would be better than a hard fail, but in either case it
seems like we're asking the user to fiddle with things that they shouldn't have
to think about or understand. is there a way that we can automatically detect
the reason for the failure and make things Just Work for normal users without
opening up the tooling to more problems?

Originally dirmngr was a system wide daemon. Thus a limit made a lot of sense
so that users could not oincrease the memory usage of dirmngr. As a user daemon
this is not too problematic anymore but (in contrast to GNU policy), having
limits is still good to avoid DoS. The packet parser also employs certain
limits, like 2K for a user ID or 16M for an attribute packet.

I assume keyservers also have some limit - or at least they should have one to
help against misuse as cheap storage provider. What about using this limit?

Kristian Fiskerstrand told me that the SKS keyservers currently have a 5 MB
limit for parsing incoming header, pre-merge.

As an additional point, the client max body size in nginx defaults to 1 MiB[0].
Currently no checking is done for larger request bodies for inclusion in the
keyserver pools. Apache does not have such a limit by default.

Reference:
[0] http://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size

FWIW, with commit 19545e3a from 2015-09-09 I had bumped the limit up to 20MiB.
This should solve all current practical problems.