Keyring issues

mdcclxv · 2023-09-08 11:15:54

seth wrote:

It does work with hkp://...:80.
Did you cross check this (ie. the same call w/ the same config failed w/o the port and then immediately succeeded after adding it)?
=> firewall?
=> proxy?

No firewall/proxy, just NAT with 100% unrestricted access. Also, my ISP is not blocking any ports, I am on a small enterprise contract with an explicit clause on that aspect.

mdcclxv · 2023-09-08 11:26:32

After I just posted my previous post, it hit me. My primary DNS server is hosted on my internal network. The secondary DNS is hosted by my ISP. So, I've switched the order, made the ISP's server primary, commented out standard-resolver from dirmngr.conf and killed dirmngr. Lo and behold, it works. Switched back to the internal DNS as primary, fails without standard-resolver, works with it.

What sort of DNS gimmick does dirmngr when not on standard-resolver? How come it worked for so long and started failing now?

Any clues on how would I be able to pin-point the actual issue in relation to my internal DNS server?

Last edited by mdcclxv (2023-09-08 11:56:52)

seth · 2023-09-08 12:34:32

What is your LAN DNS?

dig @8.8.8.8 keyserver.ubuntu.com
dig @<LAN.DNS.IP.HERE> keyserver.ubuntu.com
dig @<LAN.DNS.IP.HERE> 162.213.33.9 # this here is probably interesting…
dig @<ISP.DNS.IP.HERE> keyserver.ubuntu.com

mdcclxv · 2023-09-08 13:22:39

My DNS server is hosted on a Synology NAS, no idea what implementation they are using.

~: dig @10.1.1.1 keyserver.ubuntu.com

; <<>> DiG 9.18.18 <<>> @10.1.1.1 keyserver.ubuntu.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 44787
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

Well, I didn't have recursion enabled. Enabled it and now refreshing the keys works without the standard-resolver option.

I haven't touched my DNS in years. So the question remains: why did keyring tools suddenly stopped working?

seth · 2023-09-08 13:34:20

Disable the recursion again and try

dig +norecurse @10.1.1.1 keyserver.ubuntu.com

--recursive-resolver had different results so it probably didn't silently turn into the default, let's see wheter your local DNS' iterative behavior actually works… and if so, there's either a bug in dirmngr's interative DNS handling or somebody else touched your local DNS
(Do you *know* that recursive DNS has always been disabled?)

mdcclxv · 2023-09-10 16:38:19

Nobody touched the DNS server, I'm the only one administering the whole network infrastructure.

~: dig +norecurse @10.1.1.1 keyserver.ubuntu.com

; <<>> DiG 9.18.18 <<>> +norecurse @10.1.1.1 keyserver.ubuntu.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 18478
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

seth · 2023-09-10 18:26:37

I meant through eg. an update of the NAS firmware.

So the NAS had resursive resolution disabled and flat-out refuses your nonrecursive request.
My best guess is that either the system resolver doesn't use it or falls back to some other DNS while the gpg implementation just gets refused and then gives up.
I don't see how this can have worked previously unless
1. the NAS DNS (config) changed or
2. it was previously used as DNS by gpg (eg. because of changes to resolv.conf)

mdcclxv · 2023-09-10 18:46:15

My resolv.conf has always had 10.1.1.1 on the first line and the ISP's DNS server on the second. And the internal DNS server hasn't been touched in years. Of these two affirmations I'm 101% sure. I installed Arch on my machine more than a year ago and the resolv.conf has been the same since.

Even more, the internal DNS server is not caching anything, it only serves internal stuff and our internet domain. So any DNS requests for outside names would be refused by it and go via the second line in resolv.conf.

A third alternative would be that something has changed with the before-last update. It's too weird it stopped working all of a sudden.

seth · 2023-09-10 19:11:02

You could try to downgreade gnupg to 2.2.41-1 and see whether that's cascading your resolv.conf (ideally by wiresharking the interface to see where it's asking)

mdcclxv · 2023-09-10 23:44:09

Downgraded, same behavior. I'm in the dark ... again.

seth · 2023-09-11 05:29:59

Did you kill/restart dirmngr?

mdcclxv · 2023-09-11 10:47:06

Yes, I did.

seth · 2023-09-11 12:05:43

Boot some live distro (eg. grml or an older arch install iso) and test the gpg ./. DNS behavior there.
But your NAS DNS refusing to answer (instead of replying an NXDOMAIN) sounds like some kind of misconfiguration of that DNS and so my money remains on the breaking change being there

nooby · 2023-09-13 13:51:56

Did you try:

sudo pacman -Syy archlinux-keyring

and update after it:

sudo pacman -Syu

seth · 2023-09-13 17:23:19

The OP has a very specific issue w/ the local DNS and the resolver (cascade) implementation in dirmngr, this has nothing to do with any keyring and cannot be tackled with RTFW.

mdcclxv · 2023-09-14 09:38:43

Hi all, I'll get back to this during the weekend, I'm having a really heavy week.

Arch Linux

#26 2023-09-08 11:15:54

Re: Keyring issues

#27 2023-09-08 11:26:32

Re: Keyring issues

#28 2023-09-08 12:34:32

Re: Keyring issues

#29 2023-09-08 13:22:39

Re: Keyring issues

#30 2023-09-08 13:34:20

Re: Keyring issues

#31 2023-09-10 16:38:19

Re: Keyring issues

#32 2023-09-10 18:26:37

Re: Keyring issues

#33 2023-09-10 18:46:15

Re: Keyring issues

#34 2023-09-10 19:11:02

Re: Keyring issues

#35 2023-09-10 23:44:09

Re: Keyring issues

#36 2023-09-11 05:29:59

Re: Keyring issues

#37 2023-09-11 10:47:06

Re: Keyring issues

#38 2023-09-11 12:05:43

Re: Keyring issues

#39 2023-09-13 13:51:56

Re: Keyring issues

#40 2023-09-13 17:23:19

Re: Keyring issues

#41 2023-09-14 09:38:43

Re: Keyring issues

Board footer