dirmngr: libdns sends malformed dns requests
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	piec
	Oct 13 2021, 5:10 PM

Description

Hi All,

I'm using gnupg on Arch Linux with systemd-resolved stub mode (which means nameserver 127.0.0.53 in resolv.conf).

With the default setup operations like gpg --keyserver pgp.example.com --search-keys ... take ages on my PC. I tracked this down and found out it's related to dirmngr's dns resolver.
When I'm using dirmngr --standard-resolver ... the issue goes away.

I put systemd-resoved in debug mode (SYSTEMD_LOG_LEVEL=debug) and it complains about malformed dns queries

I took a look to queries using wireshark and as you can see it's missing the Type & Class fields (usually IN & A, or IN & AAAA, ...) Here's a screenshot:

systemd-resolved[896445]: Received dns UDP packet of size 62, ifindex=0, ttl=64, fragsize=0
systemd-resolved[896445]: Got DNS stub UDP query packet for id 59721
systemd-resolved[896445]: Failed to extract resources from incoming packet, ignoring packet: Bad message
systemd-resolved[896445]: Sending response packet with id 59721 on interface 1/AF_INET of size 12.
systemd-resolved[896445]: Received dns UDP packet of size 62, ifindex=0, ttl=64, fragsize=0
systemd-resolved[896445]: Got DNS stub UDP query packet for id 59721
systemd-resolved[896445]: Failed to extract resources from incoming packet, ignoring packet: Bad message
systemd-resolved[896445]: Sending response packet with id 59721 on interface 1/AF_INET of size 12.

Apparently this issue has been reported and fixed in the past https://dev.gnupg.org/T3803
So it may have reappeared?

Thank you,
Pierre

Details

Version: 2.2.29

Revisions and Commits

rG GnuPG
	rG152f0281552f dns: Make reading resolv.conf more robust.
	rG48359c723206 dns: Make reading resolv.conf more robust.

Related Objects

Mentioned In: T5654: Release GnuPG 2.3.4
T5641: Release GnuPG 2.2.33
Mentioned Here: rG426d82fcf1c1: gpg: Fix function prototype to match declaration.
T3803: dirmngr issues malformed DNS queries

Event Timeline

piec created this task.Oct 13 2021, 5:10 PM

piec created this object in space S1 Public.

It's hard to investigate your problem, with no information of host for the query.
I mean, there is no case to replicate (for us).

Anyway, if your host name start with ., following patch may help.

diff --git a/dirmngr/dns.c b/dirmngr/dns.c
index 3ac6a2d02..1b35d3ed5 100644
--- a/dirmngr/dns.c
+++ b/dirmngr/dns.c
@@ -5378,7 +5378,7 @@ struct dns_resolv_conf *dns_resconf_open(int *error) {
 	 * If gethostname() returned a string without any label
 	 * separator, then search[0][0] should be NUL.
 	 */
-	if (strchr (resconf->search[0], '.')) {
+	if (resconf->search[0][0] != '.' && strchr (resconf->search[0], '.')) {
 		dns_d_anchor(resconf->search[0], sizeof resconf->search[0], resconf->search[0], strlen(resconf->search[0]));
 		dns_d_cleave(resconf->search[0], sizeof resconf->search[0], resconf->search[0], strlen(resconf->search[0]));
 	} else {

If not, I can't imagine the cause...

• gniibe added a project: Info Needed.Oct 14 2021, 7:45 AM

Ah, other possible case is .. in hostname.

OK, I'll gdb in there to see what happens. My domain is a classic pgp.domain.com

dots are not allowed in hostnames.

• werner triaged this task as Normal priority.Oct 14 2021, 1:26 PM

BTW, in your screen shot (log is preferred here), it shows 1c00, that must be actually written as AAAA (0x1c). In the bug T3803, we saw byte sequence like that, additional 00 was added then resulted malformed DNS packet.