For the record, we've removed the SRV record for keys.gentoo.org for now, to work around the problem. Without the SRV record, everything works as expected.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jun 26 2023
May 24 2023
May 22 2023
Seems it gets a record but is not able to parse it (gnupg/dirmngr/dns-stuff.c:getsrv-standard) in your setup. Not sure why it loops - need to debug it.
Apr 5 2023
Jan 19 2023
Apr 25 2022
Was fixed in 2.3.5
Mar 21 2022
Actually this is pretty obvious; we better ignore such misbehaving servers.
Mar 16 2022
Dec 6 2021
Hi guys, I just tested the git version (426d82fcf1c133bfc1d5c931109d71db3f3815a9) and it works well thank you.
Fixed in 2.2.33.
Oct 15 2021
I don't know if it's same in your case, but to fix my case, I pushed a change rG48359c723206: dns: Make reading resolv.conf more robust.
I managed to create a case. Put a line:
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.
Oct 14 2021
dots are not allowed in hostnames.
OK, I'll gdb in there to see what happens. My domain is a classic pgp.domain.com
Ah, other possible case is .. in hostname.
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).
Oct 13 2021
Aug 13 2021
Dec 22 2020
Granted I'm not familiar with the functions and it may not be applicable, but the DNS resolver functions in the GNU C Library have semi-recently gained parameters (RES_USE_DNSSEC) to check for DNSSEC validation IIRC. Recent versions of glibc also don't trust the 'ad' bit unless an indication of its trustworthiness is set in /etc/resolv.conf, say if using a local validating resolver, so one can be sure that it's trustworthy. It also appears musl libc may support this.