Ich kann sagen
gpg --keyserver certserver.pgp.com --recv-key 0xBB7576AC
um den Schlüssel “0xBB7576AC” vom Schlüsselserver “certserver.pgp.com” zu holen.
Wie kann ich gpg mitteilen, welchen DNS (domain name server) es dafür benutzen soll?
Hintergrund:
“The problem seems to be that dirmngr expects some feature from the DNS server that not all ISP DNS servers seem to provide (?). The solution for me was to force my system to use 8.8.8.8 as DNS (the Google provided one).” (https://bbs.archlinux.org/viewtopic.php?id=220996 #8)
DNS im Betriebssystem auf Google umstellen, Reboot, Schlüssel holen, DNS im Betriebssystem wieder zurückstellen, Reboot - das funktioniert auch, aber wenn ich gpg “beibringen” könnte, welchen DNS es benutzen soll, wäre das deutlich praktischer.
Mir ist keine Option bekannt, mit der man das direkt mit GnuPG bewerkstelligen könnte. Ich habe auch nochmal auf https://www.gnupg.org/documentation/manuals/gnupg/index.html#SEC_Contents nachgesehen und die man page durchforstet.
Hallo Martin,
welche Version von GnuPG und auf welcher Plattform ist das denn?
(Wenn ich den Link von Dir weiter verfolge, dann komme ich auf https://dev.gnupg.org/T2889 und da ist das von Dir angegebene Problem schon 2017 im Quelltext anders gelöst worden.)
Gruß
Bernhard
Hallo Bernhard,
das ist gpg4win-4.0.4 und Plattform ist ein PC mit Microsoft Windows 11 Pro N 22H2 Build 22621.674 de.
Grüße
Martin
Hallo Martin,
funktionieren andere Keyserver denn?
Da wirklich einen Defekt in der DNS Auflösung zu haben scheint mir unwahrscheinlich, aber wenn wir ihn reproduzieren können, sicherlich einen Fehlerbericht wert.
Wenn es wirklich Dein DNS Server wäre, dann müssten andere Keyserver ja auch nicht gehen (weil sie nicht auflösen). Ich bin leider kein DNS Experte, und damit sich andere GnuPG Developer damit beschäftigen braucht es - meiner Einschätzung nach - erstmal einen reproduzierbaren Fall.
Gruß
Bernhard
Hallo Bernhard,
mit
keyserver.ubuntu.com
hkp://keys.gnupg.net
hkp://fks.pgpkeys.eu
hkp://pgp.uni-mainz.de
als Schlüsselserver funktioniert es mit dem DNS meines ISP alles nicht:
“Empfang vom Schlüsselserver fehlgeschlagen: Server zeigt einen unbestimmten Fehler an”. Vielleicht blockiert der ISP alle Schlüsselserver? Mit Google-DNS lässt sich problemlos
gpg.exe --keyserver keyserver.ubuntu.com --recv-keys 0x087523E6
gpg.exe --keyserver hkp://keys.gnupg.net --recv-keys 0x087523E6
ausführen, und für die beiden anderen Schlüsselserver gibt es zumindest sinnvolle Fehlermeldungen.
Grüße
Martin
Lösen die Adressen überhaupt auf?
Oder ist es eine Application Level Firewall, die TLS aufbricht und deshalb das Zertifikat?
Hier mal zwei bei mir aus dem Vergleich:
ping keyserver.ubuntu.com
PING keyserver.ubuntu.com (162.213.33.8)
ping keyserver2.gnupg.org
PING keyserver2.gnupg.org(2a01:4f8:c010:b69c::1 (2a01:4f8:c010:b69c::1))
Gruß
Bernhard
Hallo Bernhard!
Habe von zwei verschiedenen Rechnern, aber über den selben DNS meines ISP, ausprobiert:
Sowohl für keyserver.ubuntu.com als auch für 162.213.33.8
Zeitüberschreitung der Anforderung, 100% Verlust.
Hingegen für ping keyserver2.gnupg.org und 2a01:4f8:c010:b69c::1
0% Verlust, Min=Max=Mittel=20ms
Allerdings ergibt auch
gpg --keyserver keyserver2.gnupg.org --recv-key 0xBB7576AC
“gpg: Empfang vom Schlüsselserver fehlgeschlagen: Server zeigt einen unbestimmten Fehler an”.
Grüße
Martin
Hi Martin,
wenn die Nummern zurückgekommen sind, dann hat die Auflösung (also der DNS Teil)
erstmal funktioniert.
keyserver.ubuntu.com beantwortet die Pings allerdings nicht.
Schau mal, ob Du zu https://keyserver2.gnupg.org/ eine Verbindung per Webbrowser
bekommst und das Zertifikat passt und von R3 Let’s encrypt ist. (So sollte es sein.)
Gruß
Bernhard
Hallo Bernhard,
“ob Du zu https://keyserver2.gnupg.org/ eine Verbindung per Webbrowser bekommst”
Ja.
“das Zertifikat passt”
Ja.
“und von R3 Let’s encrypt ist.”
Ja.
Viele Grüße
Martin
Hallo Martin,
danke für den Test.
Der schließt aus, dass Du beim Webbrowser einen TLS Proxy dawischen hast.
Ja, ist weiterhin seltsam.
Sollte da wirklich ein Defekt in der DNS Auflösung drin sein, dann müssten wir das irgendwie nachstellen zu versuchen. Damit wir dann einen Problembericht schreiben
können, der den Entwickler:innen hilft das auch bearbeiten zu können.
Ist der DNS, mit dem Du diese Probleme hat, öffentlich erreichbar?
(Damit auch andere das ausprobieren können.)
Gruß
Bernhard
Hallo Bernhard,
Unter Einstellungen habe ich:
DNS-Serverzuweisung: Automatisch (DHCP)
ipconfig /all verrät mir:
DNS-Server . . . . . . . . . . . : fe80::1%3
192.168.1.1
Das sieht für mich so aus, als würde mein ISP, O2/Telefonica, einen privaten DNS betreiben. Richtig? Resonse time war auch > 250ms…
Vielleicht sollte ich also doch die automatische DNS-Zuweisung durch eine manuelle Zuweisung ersetzen? Google ist wohl schnell, aber möchte ich Google noch mehr Daten geben? Dann wäre die Frage: Welchen DNS gebe ich meinem ganzen Computersystem und damit indirekt auch gpg vor?
Viele Grüße
Martin
Moin Martin,
Mike Kuketz, ein Sicherheitsforscher, hat in seinem Blog verschiedene DNS-Server aufgelistet, die DNS-Anfragen nicht speichern und damit auch datenschutzfreundlicher sind als Google:
https://www.kuketz-blog.de/empfehlungsecke/#dns
Viele Grüße
Christoph
So, für den ganzen Rechner dauerhaft einen DNS eingestellt anstelle des “get/use default”, jetzt funktioniert es. Natürlich wäre es gut, eine entsprechende Fehlermeldung zu erhalten, wenn der DNS nicht richtig funktioniert, aber ich habe auch keine Idee, wie ein DNS zu analysieren ist, den der ISP ausschließlich für eigene Kundschaft betreibt. Vielleicht kann das Problem und seine Lösung zumindest irgendwo in der Dokumentation aufgenommen werden?
Schön, dass es erstmal bei Dir funktioniert.
Der nächste Schritte in der Analyse wäre vermutlich eine Testanwendung zu schreiben, welche den gleichen Code wie GnuPG verwendet (ein bekannter DNS client in C) und diesen mit mehr Ausgabe zu versehen. Damit ließe sich dann ein Problembericht an den Provider absetzen. (Da es vermutlich der DNS Server des Betreibers ist, der sich irgendwie anders als andere verhält.)
Bezüglich einer guten Meldung oder Aufnahme in die Dokumentation: Das würde sich nur lohnen, wenn es häufiger vorkäme oder sicher zu erkennen ist. Mir ist zumindest nicht ganz klar, wie sich die Situation “DNS funktioniert nicht richtig” von anderen Netzwerkproblemen gut unterscheiden lässt.
Gruß
Bernhard