I've tried so so so much I promise I just have no idea where to go now.
So I've been trying to install some packages with yay as usual, and some require a pgp key which it tries to import with gpg. It then fails to receive the key with an error that basically just says it fails. So I dug deeper and found I can reproduce it just with gpg, and that I can't get gpg to resolve any keys. I went even deeper and I can't even ping keyserver.ubuntu.com (but I can ping keys.openpgp.org???). Anyways I went into /etc/resolv.conf and the nameserver is set to 172.16.0.1 instead of 1.1.1.1 and 8.8.8.8 and earlier it was set to 127.0.0.1. I'm reasonably sure this is part of my issue, and I've tried really hard to resolve it, I installed dhcpd and tried to configure it but I couldn't get anywhere with that by myself. Basically dns is failing and I have no idea how to fix it or where to look. I feel like I could fix it but only in really unstable manual ways and I'd rather make my system reasonably robust for wireless because it's a laptop. It's still entirely possible that this isn't the root of my issues with gpg and if anyone knows what I could try in order to solve that more directly please let me know.
It is hard to know how to fix this because we don't know how your local network is set up.
Either your DNS is set by hand in /etc/resolv.conf or it is generated by a dhcpd server to your dhcpcd client - or some vairation (BTW - I like Vixies DHCPCD and don't trust the new ones like dhclient et al... from experience)...
Since it failed out of the box, you need to know how your network is set up specifically, including the DNS and the routing gateway.
8.8.8.8 et al... not good, FWIW. Those are public DNS and they track you.
Ping them and see if you can hit it.
ping 8.8.8.8
One final note... I have no idea why you are trying to access umbuntu keys. Unless I misunderstand, we have nothing to do with Umbuntu and its keys.
BTW, you can run DHCPCD by hand and see what it is doing.
I honestly know so little about networking so that's prolly why my attempts have been so busted (like using 8.8.8.8 or whatever)
resolv.conf was generated by dhcpcd and I've tried my best to not handwrite that because that seems..... silly. I can ping 1.1.1.1 and 8.8.8.8 just fine btw. Also idk why I'm using the ubuntu thing either, I just figured public key server.... uh... prolly has keys I need or whatever? I'm super inexperienced in that kinda stuff.
Is there any specific info I can give about my network that could help? I'm pretty lost here and I feel like I keep going in circles or doing things that just end up cluttering my install.
It seems keyserver.ubuntu.com just doesn't
pong.
$ ping keyserver.ubuntu.com
PING keyserver.ubuntu.com (2620:2d:4000:1007::70c) 56 data bytes
^C
--- keyserver.ubuntu.com ping statistics ---
45 packets transmitted, 0 received, 100% packet loss, time 44583ms
But https://keyserver.ubuntu.com/ is accessible, so it's up.
I doubt your issue is even network-related. Maybe post the commands you're using and the error messages you're getting?
This.
The more you detail you post the more chance someone will be able to help.
May not help but add --verbose to your manual gpg command.
It's not just you and lotuskip. Can't ping it either (see below). I do not think your dns is failing. I have very basic knowledge of networking, but I think it's sufficient enough.
I agree with his statement that:
Just to elaborate and try to clear the confusion (on the networking side) to the best of my abilities:
I think ubuntu (some companies do this too, not an uncommon practice) maybe blocking pings (icmp echo requests) or does not send out ping replies (icmp echo replies). Since like lotuskip and I cannot ping keyserver.ubuntu.com but I can also access it via the website.
Since you've mentioned that you can ping the other website: "keys.openpgp.org" try pinging this forum and other websites just to confirm. If you can ping other websites just fine then your dns is working. If you cannot ping all websites but can ping ip addresses directly, then it might be a dns config/server issue.
172.16.0.1 is a private ip address (for your local network only, cannot be seen outside (or more accurately cannot be routed outside)). This is probably the gateway's (the wifi router if you're using a home router) address. It could be that your router is set to act as a dns server. No idea how your isp or you have setup the router. Cannot confirm this one, but is a common setup. Check the ip address of the wifi router to confirm. Usually it is at the back or at the bottom of the router on a sticker printed to it.
Anything that starts with 10.xxx.xxx.xxx, 172.16.xxx.xxx ~ 172.31.xxx.xxx, and 192.168.xxx.xxx are private ip addresses.
127.0.0.1 is a loopback address. Basically it goes back to your device. Anything that starts with 127.xxx.xxx.xxx is a loopback address. For fun you can even use these for self hosting.
1.1.1.1 and 8.8.8.8 are cloudflare and google's dns servers. I recommend using these instead or my prefered quad9.net (9.9.9.9 and 149.112.112.112) for privacy reasons.
Normally you shouldn't use 127.0.0.1 as a nameserver/dns server unless you're using dnscrypt with dnsmasq/unbound. If you haven't heard or use those programs then just use the ones I stated above.
This please.
For key problems with repo packages probably try this first :
https://wiki.artixlinux.org/Main/Troubleshooting#Invalid_or_corrupted_packages_.28PGP_signature.29
- although I'd suggest skipping the pacman -Scc and just remove any potentially corrupted packages and their signatures individually, wiping the entire cache leaves you without an on disk backup for any unexpected downgrade requirements later.
The Arch wiki has more info too :
https://wiki.archlinux.org/title/Pacman/Package_signing
For AUR packages where you get an error relating to a specific key being missing sometimes this works, putting the key number in the error message you get at the end in place of 123ABC:
gpg --search-keys 123ABC
gpg --recv-keys 123ABC
I'm pretty sure gpg and pacman have different key databases hence the two approaches. There are different keyservers too, and there have been problems in the past with some not being updated and having keys missing. Another thing you could try is defining keyservers in /etc/pacman.d/gnupg/gpg.conf after making a .bak copy of the original, e.g. adding these lines to the existing content should work and remove the need to rely on ubuntu keyservers :
keyserver keys.openpgp.org
keyserver keys.gnupg.net
Unfortunately this doesn't do anything for the error I'm getting, but I'll post all the things I've been trying:
gpg --verbose --search-keys 034F7776EF5E0C613D2F7934D29FBD5F93C0CFC3
gpg: enabled compatibility flags:
gpg: error searching keyserver: Try again later
gpg: keyserver search failed: Try again later
gpg --verbose --recv-keys 034F7776EF5E0C613D2F7934D29FBD5F93C0CFC3
gpg: enabled compatibility flags:
gpg: keyserver receive failed: Try again later
yay -S librewolf
...
:: (1/1) Parsing SRCINFO: librewolf
gpg: ~/.gnupg/trustdb.gpg: trustdb created
gpg: error reading key: No public key
:: PGP keys need importing:
-> 034F7776EF5E0C613D2F7934D29FBD5F93C0CFC3, required by: librewolf
:: Import? [Y/n]
:: Importing keys with gpg...
gpg: keyserver receive failed: Try again later
-> problem importing keys
^ the only thing that seems at all suspect here is the local trustdb when I feel that the generated one would be in like /etc or something, which would mean it doesn't have the keys where it's looking... but idk.
Alright I did that, here's my current /etc/pacmand.d/gnupg/gpg.conf (I changed that before running the above commands). It still is broken in the same way unfortunately.
no-greeting
no-permission-warning
keyserver-options timeout=10
keyserver-options import-clean
keyserver-options no-self-sigs-only
keyserver keys.openpgp.org
keyserver keys.gnupg.net
(I also tried the above conf with hks:// in front just in case, didn't change anything)
Basically everything points to there being some invalid config for which keyserver I'm using, idrk where else I would be setting this than the places I've already set it.
One last command:
sudo pacman-key --verbose --recv-keys 034F7776EF5E0C613D2F7934D29FBD5F93C0CFC3
gpg: keyserver receive failed: No keyserver available
==> ERROR: Remote key not fetched correctly from keyserver.
Please let me know if there's anything more specific I can provide to help, I really don't know what'd be useful here.
Searching the webs for your error message suggested that somehow gpg is unable to access the internet or perhaps that its traffic is getting firewalled. I don't know enough about gpg internals to say much more, but here are some workarounds to try:
1. Use the actual IP of the server to work around DNS issues, something like
pacman-key --keyserver 195.201.47.43 --recv-keys 034F7776EF5E0C613D2F7934D29FBD5F93C0CFC3
(that's the IP for keys.openpgp.org; note that pacman-key is just a wrapper for gpg)
or
2. If you can, download the key file from https://keys.openpgp.org/ (https://keys.openpgp.org/) and then add that:
pacman-key --add /path/to/downloaded/keyfile
Somebody even said that disconnecting and reconnecting their wifi fixed the issue...
The pacman-key stuff is a bit of a red herring as yay/makepkg need the keys in the user keyring.
It is informative though as it suggests a configuration issue is unlikely (unless both are misconfigured and if you changed nothing prior to the issue that does not seem possible) and a network issue is more so as lotuskip said.
If you do get the keys manually, or try a direct ip address, use gpg as your user not pacman-key when building AUR packages.
How do you connect to the internet?
If you haven't installed any firewall, messed with iptables, or changed the connman configuration then your system blocking the traffic to the keyserver, in at least one direction, seems improbable but one way to help rule it out would be to test the gpg commands after booting from the installation iso. If they don't work it's your network. If they do it's your system.
I'd also try temporarily disabling connman and making a network connection manually.
Also connecting to the internet in a different way. For instance making sure my phone was not connected to my local wifi and using it to connect to the internet either by wifi hotspot or usb or bluetooth etc.
All a bit of a stretch but I think those are the things I would try.
Oh, of course! Sorry for getting mixed up there. So you should be calling gpg directly to add keys. And according to gpg man page, "--keyserver" is deprecated and you should use a config file instead. I'm not sure if that means the command line argument doesn't work anymore or just that it'll be dropped in a future release.
Perhaps I missed some detail which reveals this, but yay will install packages from both repos (wrapping pacman) and the AUR so it isn't clear to me at least yet which approach is required - in the above example librewolf is in Omniverse but if that repo isn't enabled yay would get it from the AUR.
(Deprecated means will be removed in future, but should still be working now - it is a warning not to use it in scripts and so forth.)
Another unlikely but possible cause to consider, could this be a yay bug, or the result of using an outdated or experimental git version of yay? Perhaps trying another AUR helper might be a worthwhile test in the absence of success by other means.
That's what the word generally means. I just figured words might be wrongly used or man pages might not be up to date.
The keys pacman-key deals with are for signed packages.
Yay will use those when its acting as a wrapper around pacman.
When installing from AUR yay is acting as a wrapper around makepkg (until the installation part) and needs the user gpg keys to verify signed source if the PKGBUILD has been set up that way (.sig files referenced after source code links in the PKGBUILD source stanza).
It's slightly more complicated than that if you sign packages you build with your own key.
There have been some issues recorded with national firewalls apparently blocking keyservers and causing this error, if you live in a country which might find itself set apart:
https://unix.stackexchange.com/questions/399027/gpg-keyserver-receive-failed-server-indicated-a-failure
I am not 100% sure without knowing your setup, but resolv.conf is probably getting regenerated every time you boot or connect if you are using dhcp and not a manually configured static connection. The file creation time should confirm this, so if you make a backup too you can certainly experiment with the content quite safely, but check any mods are not overwritten.
Usually if you don't configure your own nameserver, this defaults to whatever your router is using for it's DNS nameserver I think.
this works! But so does
pacman-key --keyserver keys.openpgp.org --recv-keys 034F7776EF5E0C613D2F7934D29FBD5F93C0CFC3
Interestingly though:
gpg --keyserver keys.openpgp.org --recv-keys 034F7776EF5E0C613D2F7934D29FBD5F93C0CFC3
does NOT work. So maybe --keyserver is entirely removed in gpg now and it's falling back on the faulty config. In which case the config for gpg which has the correct nameservers is possibly not being used by base gpg or by yay, because the one I've been editing is /etc/pacman.d/gnupg/gpg.conf as per the recommendation in this thread. I don't know if there even are any other gpg configs on my system though, I looked through /etc and couldn't find any. But also pacman-key must not be correctly using (or I haven't written it right) the config in /etc/pacman.d/gnupg/gpg.conf because it doesn't work without a specific --keyserver supplied.
Yeah I don't think I've messed with anything in iptables and I haven't installed any firewalls. I might've edited some connman thing at some point but quite honestly I think I changed it back and I don't think it changed anything when I did it.
I booted from the installation iso and tried the commands that have worked and the ones that haven't worked. The behavior was basically the same. Keep in mind I was on ethernet but it was the same network. The pacman-key commands above worked, but when I replaced the ip with keys.openpgp.org it no longer worked. gpg was just as faulty as it is on my current install, same errors and everything.
Hotspot has the same behavior as my normal wifi connction, Same errors and same successes.
yes it's definitely getting regenerated every time, it does seem to be some default DNS nameserver (127.0.0.1) that probably is inaccurate. But that's all resolv.conf has in it... just that incorrect nameserver (aswell as ::1). However DNS works for like normal things, I can ping servers and everything normal, it's just this gpg thing that kicks something into not working.
Please let me know if there's any more information that could be useful which I could provide.
No the one you (may)need to edit for the gpg keys which you need to build packages with yay is:
~/.gnupg/gpg.conf
which probably doesn't exist yet but you can create it.
Your dns sounds flaky.
127.0.0.1 is probably connman
You can find, I think , the dns server connman is using with
grep -r Nameservers /var/lib/connman/
which is probaby your router.
So maybe log into your router and see if you can edit the dns server.
Because especially if the router is automatically using the ISP provided dns server then that could be your issue as they sometimes block stuff or sometimes they are just shit.
As a workaround setup ~/gnupg/gpg.conf to use a keyserver that works for you either by domain or ip whichever works.
How about setting up the network correctly first before going onto the next step, which is not with conman but with dhcpcd
and visually check the /etc/resolve file
until that is stable, you are shooting live fish in the bathtub. The fish escape but the tub is destroyed. There are too many moving parts here to debug it, and gentleman posing the inquiry doesn't really have enough background to explain his situation clearly..
they need bind for dig, dhcpcd, the network settings in /etc/conf.d/net set correctly, the output for dmesg, ip ro, and ip -4 add
Until he can ping a computer outside his network, he is just blind.
Ok I edited that gpg.conf and it works but only if I use the ip of the keyserver, which is not ideal obviously.
Ran grep, returned nothing. Pretty sure you're right about that command though, so I think I have no nameservers set up?
Logged into the router, it says it's using the ISP provided dns, and it could be that but I'd really like to verify that that's actually the issue. I've been using arch based linux on this network for 3 years now and have had no similar issues. I feel like it's probably my system and I'd rather my system be resilient to any network rather than tailoring the network to my system because it's a laptop.
contents below:
# Generated by Connection Manager
nameserver ::1
nameserver 127.0.0.1
cat /etc/conf.d/net | grep -v '^[[:space:]]*#'
returns nothing, so that file isn't doing anything
what specifically do you want from dmesg? I'm not just going to send that entire dump here.
ip ro:
default via 172.16.0.1 dev wlan0
127.0.0.0/8 via 127.0.0.1 dev lo
172.16.0.0/24 dev wlan0 proto kernel scope link src 172.16.0.81
172.16.0.1 dev wlan0 scope link
ip -4 add
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet 172.16.0.81/24 brd 172.16.0.255 scope global wlan0
valid_lft forever preferred_lft forever
Please let me know what else to provide.
Your DNS is just broken
Run dhcpcd
if it doesn't work, your dhcpd server on the router is broken
Also
ping 172.16.0.1
and then ping
ping 8.8.8.8
flatbush:[ruben]:~$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 home2.mrbrklyn.com (10.0.0.37) 0.518 ms 0.480 ms 0.417 ms
2 ool-60391751.static.optonline.net (96.57.23.81) 2.459 ms 3.092 ms 3.917 ms
3 10.240.176.237 (10.240.176.237) 15.089 ms 16.294 ms 16.654 ms
4 433be036.cst.lightpath.net (67.59.241.54) 16.850 ms 17.391 ms 17.426 ms
5 ool-4353dd1e.dyn.optonline.net (67.83.221.30) 24.554 ms 24.685 ms ool-4353dd1c.dyn.optonline.net (67.83.221.28) 23.487 ms
6 63.142.20.0 (63.142.20.0) 26.115 ms 64.15.4.108 (64.15.4.108) 23.158 ms 451be070.cst.lightpath.net (65.19.99.112) 22.924 ms
7 64.15.1.153 (64.15.1.153) 25.746 ms 15.168 ms 20.065 ms
8 * * *
9 * * *
10 dns.google (8.8.8.8) 23.761 ms 24.530 ms 23.820 ms
If those don't work, your routers is completely either broken, or it is intentionally blocking you.
You want to look at your dmesg results to see that your wireless is working
maybe not... put it back on the wire.
If it was the same from the iso it's not your system it's the network. imho.
Try another name server on the router. Clouldflare's 1.1.1.1 and Google's 4.4.4.4 are not ideal in the long run but are fine while you get it working. Then find a more privacy respecting name server.
Your ISP's dns server is the worst option. Well it is in my country. They block stuff and they have to record everything by law.
dhcpcd is running, same behavior.
I run servers off of this network which use dhcpd and I've never had issues, idk if that's much information but I don't even know how I would go about fixing something as contained as that.
both of these ping fine, no issues.
I get a similar output, ending in dns.google.
I don't see any errors or warnings related to wireless.
what?
I'm in the U.S. so the isp dns is evil and traced obviously, but they normally won't block this kind of stuff on my isp. Anyways I changed the DNS servers to 1.1.1.1 and 8.8.8.8 and it didn't change the gpg behavior. Is there something more revealing I could use rather than just running gpg commands to test my DNS? In all scenarios I can ping just about every server I can think of, so using my DNS for normal things seems to work fine. It's like gpg itself is failing to
use the DNS.
If you can do that with both domain names and ip addresses, and the same is true of an iso, then either it's a problem with the wider network or the iso is broken and creating broken systems.
As no other reports of this issue have been seen yet it's probably the former.
It might not be dns ? Try traceroute to the domain as well.
A while ago some people were unable to access the Artix archives (i think it was that) because their traffic was getting blocked along the route.
Other than that idk.
I did a bit more digging on my own and I'm pretty sure it's not DNS. I think it's instead that TLS is failing. I can make any keyserver work if I specify for it to use hkp:// instead of hkps://. My CA certs seem to be ok and my config files are as follows:
~/.gnupg/dirmngr.conf
verbose
log-file /tmp/dirmngr.log
disable-ipv6
debug ipc,network,gnutls
hkp-cacert /etc/ssl/certs/ca-certificates.crt
~/.gnupg/gpg.conf
keyserver-options auto-key-retrieve
keyserver hkp://keyserver.ubuntu.com:80
With this config it works, but as soon as I try to use hkps (default) it fails. Is there anything I might be able to do about this? dirmngr errors are extremely unhelpful:
DBG: chan_6 -> OK Dirmngr 2.4.7 at your service, process 7128
connection from process 7126 (1000:1000)
DBG: chan_6 <- GETINFO version
DBG: chan_6 -> D 2.4.7
DBG: chan_6 -> OK
DBG: chan_6 <- KEYSERVER --clear hkps://keys.openpgp.org // btw this fails with any server using hkps://. not just openpgp
DBG: chan_6 -> OK
DBG: chan_6 <- KS_GET -- 0x034F7776EF5E0C613D2F7934D29FBD5F93C0CFC3
command 'KS_GET' failed: Server indicated a failure <Unspecified source>
DBG: chan_6 -> ERR 219 Server indicated a failure <Unspecified source>
DBG: chan_6 <- BYE
DBG: chan_6 -> OK closing connection
Your DNS is almost guaranteed to be messed up. And /etc/resolv of 127.0.0.1 means you are your own DNS server. Unless you are running a caching DNS server like unbound, that is almost guaranteed to be not right. Since you can ping outside the gateway, that means the routing information is correct.
EXACTLY what is your /etc/resolv after using DHCPCD on the WIRE.
It doesn't help to jump around like a rabbit. Fix the DNS first. And the wifi and the wire can be different. In fact, it is often different networks.
I want to see the routing while on the WIRE and the routing while on the wireless and the /etc/resolve in both cases so we can get to the bottom of this.
You can fix this quickly if you really have zero patience by hand writing the DNS to point to 1.1.1.1 . But it is not ideal.
BTW - if that doesn't work you have some kind of packet filtering going on within the gateway (or locally).
FWIW, I don't know what that means. DNS entries are dot quads (or maybe IP6) not secret messages.
Please help us to help you. Simplify the networking problem first. Fix one thing at a time.
this is what it looks like when the ethernet or network is inhently broken on the hardware level in dmesg
or like this
On ethernet ("Wire")
# Generated by dhcpcd from eth0.dhcp
# /etc/resolv.conf.head can replace this line
nameserver 172.16.0.1
# /etc/resolv.conf.tail can replace this line
On wifi
# Generated by dhcpcd from wlan0.dhcp
# /etc/resolv.conf.head can replace this line
nameserver 172.16.0.1
# /etc/resolv.conf.tail can replace this line
they're the same.
I ran the same tests as I did above in this thread. I got identical results for both. Check above posts for outputs.
Did this above. Got the exact same errors as I have been reporting.
This is a fairly simple thing that even I understand. The DNS server my system uses is provided by the router. My DNS requests get sent to the router to be sent to the DNS server. My router allows the user to enter DNS servers, but can also request DNS servers from my ISP which are subject to change. By default it is set to receive the DNS server from the ISP. I manually set it above to 1.1.1.1 and 8.8.8.8 for testing and received the same errors as I continue to report. The router's interface does not make the DNS server provided by the ISP readily visible.
Neither of these fail states are present in my dmesg output.
The fact that all of these tests seem to pass really makes me think my DNS is fine. I haven't seen anything that directly points to a DNS failure and I've instead seen a lot of things that point to an inability of dirmngr under gpg to establish a secure hkps connection with my selected keyserver.
DNS is dot quads which is you case is
# /etc/resolv.conf.head can replace this line
nameserver 172.16.0.1
Now you need dig tools
dig +trace keyserver.ubuntu.com
or whatever server you are trying to resolve.
PUTTING 1.1.1.1 in /etc/resolve will bypass your routers DNS settings.
man resolv.conf
As I said, which I do not recommend unless your router is screwing you up... which is NOT impossible.
https://public-dns.info/nameserver/us.html
It is POSSIBLE for the router to allow pings and filter port 53 to block DNS. Airports are famous for this. It is also possible that routers just blow up and stop working correctly in seemingly illogical ways.
succeeds completely without modifying any nameservers. It returns all of the expected information. I've already bypassed my router's defaults above as I stated. It changed nothing.
It is not supposed to modify anything. It is a trace of the DNS chain that the resolver does. Please post it for the DNS you are having trouble with.
If dig can find ir successfully and report all the chain levels, you are not likely having DNS problems.
Do it for for the wire, and then the wireless. You can, and know through testing, that the routing works and the DNS works...
You stated above that you changed your routers DNS entries, not that you bypassed it. It is not a subtle difference. One is you think you changed the settings in your router. The other you BYPASSED the router through a manual entry in the /etc/resolv.conf file which bypasses the router for DNS inquiries all together.
Leave the router alone right now, as it just adds another level of complexity.
I mean that I didn't have to modify anything in order for it to succeed.
ethernet:
; <<>> DiG 9.20.9 <<>> +trace keyserver.ubuntu.com
;; global options: +cmd
. 304794 IN NS m.root-servers.net.
. 304794 IN NS c.root-servers.net.
. 304794 IN NS d.root-servers.net.
. 304794 IN NS e.root-servers.net.
. 304794 IN NS i.root-servers.net.
. 304794 IN NS k.root-servers.net.
. 304794 IN NS a.root-servers.net.
. 304794 IN NS b.root-servers.net.
. 304794 IN NS j.root-servers.net.
. 304794 IN NS f.root-servers.net.
. 304794 IN NS l.root-servers.net.
. 304794 IN NS g.root-servers.net.
. 304794 IN NS h.root-servers.net.
. 446832 IN RRSIG NS 8 0 518400 20250626050000 20250613040000 53148 . D/tc+xSXzxrZ42Zp6rVys1ixNZnheAk4UWT3e+V3FpwFKfY/uJYg2C0t YPV0UZWq0znTiKnYd8jjgb6pe7gxiJ3S/xU8oEk/vplSoslj1iBlafkg xGtFTGAPWW5+4KigTeUsSg+5ulVSuk7P4CccV8ckn+hdYDi+HnyVoDjd 99+r//rmRDyh4pgTP4pmUasnmlS5d94fiu/qAZD22COXVRi5hT7JouFG BsL1UrmHoW56xrcPem8JT/j+2g7GtSdSFMUw797y40CUTn9fuzFt6D24 lFr2RT4z9zpXJUOKOk0bR0rxpZycR4wfj+wEmKLAUVJGbs7OPL6qI9o9 lh5rmg==
;; Received 1109 bytes from 172.16.0.1#53(172.16.0.1) in 11 ms
;; UDP setup with 2001:500:9f::42#53(2001:500:9f::42) for keyserver.ubuntu.com failed: network unreachable.
;; no servers could be reached
;; UDP setup with 2001:500:9f::42#53(2001:500:9f::42) for keyserver.ubuntu.com failed: network unreachable.
;; no servers could be reached
;; UDP setup with 2001:500:9f::42#53(2001:500:9f::42) for keyserver.ubuntu.com failed: network unreachable.
;; UDP setup with 2001:500:a8::e#53(2001:500:a8::e) for keyserver.ubuntu.com failed: network unreachable.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 86400 IN DS 19718 13 2 8ACBB0CD28F41250A80A491389424D341522D946B0DA0C0291F2D3D7 71D7805A
com. 86400 IN RRSIG DS 8 1 86400 20250626170000 20250613160000 53148 . Jsyt2SlJuFhEfw5FvvMUyAmoq+oeYfiq9C4lzztOSt4lM0F/n/jaHB1w NbH95GSwvTlTkDw1hM8U0Mr7I2wZtkl7Qsgc62mz1eHyEEVDZG7DU3DO DcePbRCfEZlColFlOz7AErm2JZyUVaf1TXQVA04luQVK1Bxcmfi5AYgy 0hXi36tN1H8EOXdMy4iZAkvKoVJSxTshuCOt/n1Ah05MnF+q5xDjGGqn 1fNEGfYpbXWvgS5+dMz+QYM+HhKOmYWcfLCthqsLblIOhAibOcN1ZwiP Zd7lx1dKhFslXs8h9zFLbbtTGVLIh1ieK4lB4C1PavZfaFnu4mVeus57 ck7nkg==
;; Received 1211 bytes from 192.36.148.17#53(i.root-servers.net) in 13 ms
ubuntu.com. 172800 IN NS ns1.canonical.com.
ubuntu.com. 172800 IN NS ns2.canonical.com.
ubuntu.com. 172800 IN NS ns3.canonical.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN NSEC3 1 1 0 - CK0Q3UDG8CEKKAE7RUKPGCT1DVSSH8LL NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN RRSIG NSEC3 13 2 900 20250620002602 20250612231602 40097 com. 4Jdbo8fzOK2TDem7S2s83cetG51x9u/8msmXzEkcsASQ0a0Z7w4W47Ft HWrJPG22UMX3lR8Cg151T6wK6C2RLA==
894IO8AM9NDQ8VM84GPASGU0QDHFLFS1.com. 900 IN NSEC3 1 1 0 - 894IV2SV1RTOAHAPRJ3DNEI88AIOLRK9 NS DS RRSIG
894IO8AM9NDQ8VM84GPASGU0QDHFLFS1.com. 900 IN RRSIG NSEC3 13 2 900 20250620013442 20250613002442 40097 com. 9NzC04yYCfVrRG1xDyRJujW5GytxruQVFmG/LXqkBP5M+D158eqALlKQ PvTmRkCfhpowHwpy1zA4W+3T2N0e3g==
;; Received 574 bytes from 192.33.14.30#53(b.gtld-servers.net) in 24 ms
keyserver.ubuntu.com. 600 IN A 185.125.188.27
keyserver.ubuntu.com. 600 IN A 185.125.188.26
ubuntu.com. 172800 IN NS ns2.canonical.com.
ubuntu.com. 172800 IN NS ns1.canonical.com.
ubuntu.com. 172800 IN NS ns3.canonical.com.
;; Received 176 bytes from 185.125.190.65#53(ns1.canonical.com) in 147 ms
wlan:
; <<>> DiG 9.20.9 <<>> +trace keyserver.ubuntu.com
;; global options: +cmd
. 300880 IN NS j.root-servers.net.
. 300880 IN NS c.root-servers.net.
. 300880 IN NS h.root-servers.net.
. 300880 IN NS i.root-servers.net.
. 300880 IN NS d.root-servers.net.
. 300880 IN NS k.root-servers.net.
. 300880 IN NS l.root-servers.net.
. 300880 IN NS e.root-servers.net.
. 300880 IN NS b.root-servers.net.
. 300880 IN NS f.root-servers.net.
. 300880 IN NS g.root-servers.net.
. 300880 IN NS m.root-servers.net.
. 300880 IN NS a.root-servers.net.
. 447600 IN RRSIG NS 8 0 518400 20250626050000 20250613040000 53148 . D/tc+xSXzxrZ42Zp6rVys1ixNZnheAk4UWT3e+V3FpwFKfY/uJYg2C0t YPV0UZWq0znTiKnYd8jjgb6pe7gxiJ3S/xU8oEk/vplSoslj1iBlafkg xGtFTGAPWW5+4KigTeUsSg+5ulVSuk7P4CccV8ckn+hdYDi+HnyVoDjd 99+r//rmRDyh4pgTP4pmUasnmlS5d94fiu/qAZD22COXVRi5hT7JouFG BsL1UrmHoW56xrcPem8JT/j+2g7GtSdSFMUw797y40CUTn9fuzFt6D24 lFr2RT4z9zpXJUOKOk0bR0rxpZycR4wfj+wEmKLAUVJGbs7OPL6qI9o9 lh5rmg==
;; Received 1109 bytes from 172.16.0.1#53(172.16.0.1) in 18 ms
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 86400 IN DS 19718 13 2 8ACBB0CD28F41250A80A491389424D341522D946B0DA0C0291F2D3D7 71D7805A
com. 86400 IN RRSIG DS 8 1 86400 20250626170000 20250613160000 53148 . Jsyt2SlJuFhEfw5FvvMUyAmoq+oeYfiq9C4lzztOSt4lM0F/n/jaHB1w NbH95GSwvTlTkDw1hM8U0Mr7I2wZtkl7Qsgc62mz1eHyEEVDZG7DU3DO DcePbRCfEZlColFlOz7AErm2JZyUVaf1TXQVA04luQVK1Bxcmfi5AYgy 0hXi36tN1H8EOXdMy4iZAkvKoVJSxTshuCOt/n1Ah05MnF+q5xDjGGqn 1fNEGfYpbXWvgS5+dMz+QYM+HhKOmYWcfLCthqsLblIOhAibOcN1ZwiP Zd7lx1dKhFslXs8h9zFLbbtTGVLIh1ieK4lB4C1PavZfaFnu4mVeus57 ck7nkg==
;; Received 1180 bytes from 198.97.190.53#53(h.root-servers.net) in 28 ms
;; UDP setup with 2001:503:83eb::30#53(2001:503:83eb::30) for keyserver.ubuntu.com failed: network unreachable.
;; no servers could be reached
;; UDP setup with 2001:503:83eb::30#53(2001:503:83eb::30) for keyserver.ubuntu.com failed: network unreachable.
;; no servers could be reached
;; UDP setup with 2001:503:83eb::30#53(2001:503:83eb::30) for keyserver.ubuntu.com failed: network unreachable.
ubuntu.com. 172800 IN NS ns1.canonical.com.
ubuntu.com. 172800 IN NS ns2.canonical.com.
ubuntu.com. 172800 IN NS ns3.canonical.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN NSEC3 1 1 0 - CK0Q3UDG8CEKKAE7RUKPGCT1DVSSH8LL NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN RRSIG NSEC3 13 2 900 20250620002602 20250612231602 40097 com. 4Jdbo8fzOK2TDem7S2s83cetG51x9u/8msmXzEkcsASQ0a0Z7w4W47Ft HWrJPG22UMX3lR8Cg151T6wK6C2RLA==
894IO8AM9NDQ8VM84GPASGU0QDHFLFS1.com. 900 IN NSEC3 1 1 0 - 894IV2SV1RTOAHAPRJ3DNEI88AIOLRK9 NS DS RRSIG
894IO8AM9NDQ8VM84GPASGU0QDHFLFS1.com. 900 IN RRSIG NSEC3 13 2 900 20250620013442 20250613002442 40097 com. 9NzC04yYCfVrRG1xDyRJujW5GytxruQVFmG/LXqkBP5M+D158eqALlKQ PvTmRkCfhpowHwpy1zA4W+3T2N0e3g==
;; Received 574 bytes from 192.48.79.30#53(j.gtld-servers.net) in 34 ms
;; UDP setup with 2620:2d:4000:1::43#53(2620:2d:4000:1::43) for keyserver.ubuntu.com failed: network unreachable.
;; UDP setup with 2620:2d:4000:1::44#53(2620:2d:4000:1::44) for keyserver.ubuntu.com failed: network unreachable.
keyserver.ubuntu.com. 600 IN A 185.125.188.26
keyserver.ubuntu.com. 600 IN A 185.125.188.27
ubuntu.com. 172800 IN NS ns3.canonical.com.
ubuntu.com. 172800 IN NS ns2.canonical.com.
ubuntu.com. 172800 IN NS ns1.canonical.com.
;; Received 176 bytes from 185.125.190.65#53(ns1.canonical.com) in 151 ms
Ipv6 failing is pretty expected as I haven't configured it and in the gpg config I force it to use Ipv4.
Sorry, before I posted this thread I manually edited /etc/resolv.conf and added 1.1.1.1 and 8.8.8.8. That is "bypassing" the router's DNS forwarding. It did nothing different from what I'm experiencing with the default DNS setup with my router.
that is umbuntu. Didn't you say that keys.openpgp.org is the name that you can not resolve?
BTW - they look like they are having troubles and you've all but tested your network and your DNS and both are working, according to your results
flatbush:[ruben]:~$ dig keys.openpgp.org
; <<>> DiG 9.20.9 <<>> keys.openpgp.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38322
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: f54a0c722c65ba4d01000000684cfe97319f4d5d860448d9 (good)
;; QUESTION SECTION:
;keys.openpgp.org. IN A
;; Query time: 0 msec
;; SERVER: 10.0.0.37#53(10.0.0.37) (UDP)
;; WHEN: Sat Jun 14 00:46:04 EDT 2025
;; MSG SIZE rcvd: 73
You can trace that to see where the trouble is
It looks like their autheticated SOA is having trouble
D39489CD78A86BEB0D8A0AEAFF14745C0D 16E1DE32
org. 86400 IN RRSIG DS 8 1 86400 20250626170000 20250613160000 53148 . Fr5EHyEP8o9OTashZoWqUypfgJalSYfCy0SoSOe7gHsombv8hjXenuYe kO9N8O9VrPfcFXO7bl70gnIVi/9LqbHS+gRV86qscZpAqraoHc5rkjuH krV0t69MVipUbclQT5wDKbAh4c1Cmti+aXGvaUtbEB7scRE+ARe8zji5 yc8RfpjKhZw3ZXoSF4vDN1EqsBqZCbAlZ/vAS4H3GLld0NRO6DBniTpW 2hQcPfU9V8oxyO6SR5Yz0cCcV60b2D+epCoQnPpBo5oyRi4EElNnYA8T JOtNLkxoeOAW2PqE1gfNAK1l214atioXV9HQaPcEN3qJY3kWghosVS3q HMgtqQ==
;; Received 788 bytes from 202.12.27.33#53(m.root-servers.net) in 76 ms
openpgp.org. 3600 IN NS ns2.swcp.com.
openpgp.org. 3600 IN NS ns2.nmia.com.
openpgp.org. 3600 IN DS 26041 8 2 E68586C464FD449D62B879BC5913214C93FF841D0490A4E7D405324C 81DAC25C
openpgp.org. 3600 IN RRSIG DS 8 2 3600 20250630152615 20250609142615 321 org. uidUTdbFQA9yclJr572q40KDqf0EguI8WPRzL/DUWkpdCIetwzfnYgpG npFH8YOkYDYsy0HOrrGHTIGOV2gxEv1FthrbGHWYvNNH2cOQ1DsyY++V KVbjWIRbhApjcwrwIl7t6idQ4F2a7fJsWa4HZctkU/l4JebnNtDxwHir 93g=
couldn't get address for 'ns2.swcp.com': failure
couldn't get address for 'ns2.nmia.com': failure
dig: couldn't get address for 'ns2.swcp.com': no more
You can try different DNS servers to see if this is a regional problem
dig +trace @1.1.1.1 keys.openpgp.org
THERE IS a current record that has not timed out from 1.1.1.1
flatbush:[ruben]:~$ dig @1.1.1.1 keys.openpgp.org
; <<>> DiG 9.20.9 <<>> @1.1.1.1 keys.openpgp.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45668
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;keys.openpgp.org. IN A
;; ANSWER SECTION:
keys.openpgp.org. 2911 IN A 195.201.47.43
;; Query time: 20 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Sat Jun 14 00:53:00 EDT 2025
;; MSG SIZE rcvd: 61
That is a cached record and will not exist forever.
My guess is that there is nothing wrong with your set up, such as we can see, and we tried by examining all the moving parts, one by one.
It looks like it is out of your hands and openpgp.org is having troubles on an administrative level.
It is a twocows domain
flatbush:[ruben]:~$ whois openpgp.org
Domain Name: openpgp.org
Registry Domain ID: a5369e21b7e547b6a8aadbdaac5e1628-LROR
Registrar WHOIS Server: whois.tucows.com
Registrar URL: http://www.tucows.com
Updated Date: 2024-12-26T20:05:12Z
Creation Date: 2000-01-24T12:38:32Z
Registry Expiry Date: 2026-01-24T12:38:31Z
Registrar: Tucows Domains Inc.
Registrar IANA ID: 69
Registrar Abuse Contact Email:
[email protected]Registrar Abuse Contact Phone: +1.4165350123
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited
Seems to be a problem with the SOA record
flatbush:[ruben]:~$ dig -t SOA keys.openpgp.org
; <<>> DiG 9.20.9 <<>> -t SOA keys.openpgp.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 43860
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: fe75e943cbdb281c01000000684d01cbd73e1b8fe57a9274 (good)
;; QUESTION SECTION:
;keys.openpgp.org. IN SOA
;; Query time: 3 msec
;; SERVER: 10.0.0.37#53(10.0.0.37) (UDP)
;; WHEN: Sat Jun 14 00:59:45 EDT 2025
;; MSG SIZE rcvd: 73
actually, they have been blocked at the 216.0.0.0/8 level because of abuse of the network...
so there is that...
That is on my DNS. I see it on other dns servers as well on both North American coastlines.
OTOH - on Panix, it is open and the DNS for opengpg.org works.
I don't know if the ip addresses are being blocked or if that is the exact cause of your issue. That may or may not be contributing to the problem.