Vom Vertrauen.

Vertrauen ist kein Kuscheltier, das man sich bei Bedarf aus dem Regal zieht, sondern ein Kredit, den man vergibt. Ein Nutzer eines auf Sicherheit in der IT spezialisierten Forums beschreibt, er stehe zwischen dnsforge1 und CenturionDNS2, finde meine Angaben zwar ansprechend, könne aber das zentrale Versprechen, keine Logs zu führen, naturgemäss nicht verifizieren, und fragt nach Kriterien für Vertrauenswürdigkeit.

Das ist ein fairer Punkt. Kein PR-Text, keine wohlklingende Datenschutzerklärung, keine heroische Selbstverortung ersetzt die banale, kalte Erkenntnis: Der rekursive Resolver3 sieht alles, was man ihn fragt. Er ist Beichtstuhl und Verkehrsknoten zugleich. Wer dort Vertrauen fordert, hat gefälligst auch zu erklären, wie er es verdient, wie er es technisch einpreist, und wo die Grenzen4 liegen, die man nicht wegargumentieren kann.

Der Thread liefert nebenbei auch die typische Mischung aus naheliegenden, halbrichtigen und richtig guten Hinweisen. Es wird etwa darauf hingewiesen, dass ein Server in der EU nicht automatisch vertrauenswürdiger sei, weil auch dort Datenabgriff möglich ist, und dass DSGVO5 zwar Pflichten setzt, aber kein magischer Schutzschild ist. Ein anderer Aspekt: Tor6 als Transport für DNS klingt in der Fantasie mancher Leute nach „dann bin ich anonym“, kollidiert aber mit dem Protokollrealismus, weil Tor im Kern TCP7-Streams transportiert und kein rohes UDP8 routed.9 Die Diskussion streift auch die Schweiz als vermeintlich „bessere Jurisdiktion“ und entzaubert diese Romantik zumindest ansatzweise.

Genau an diesem Punkt setze ich an, nicht als Marketingnummer, sondern als methodische Selbstverpflichtung. CenturionDNS ist kein „Produkt“, das man im Prospekt anschaut wie einen Toaster. Es ist ein Versprechen. Und Versprechen sind nur so viel wert, wie die Kohärenz zwischen Worten, Technik, Governance, gelebter Praxis und Reaktion auf Widerstand.

Der DNS-Resolver als Wahrheitsmaschine

DNS ist in seiner schlichten Eleganz unerquicklich ehrlich. Ein Client fragt, ein Resolver antwortet. Wer rekursiv auflöst, sieht nicht bloss Zieladressen, sondern Interessen, Rhythmen, Gewohnheiten. Ein sauber konfigurierter Browser, der alles über HTTPS10 abwickelt, kann trotzdem über DNS sein Innenleben verraten: Updates, Telemetrie, Tracker, Bank, Arzt, Medien, die ganze private Topologie. Transportverschlüsselung11 wie DoT12 oder DoH13 verschiebt die Beobachtbarkeit vom lokalen Netz zum Resolver. Sie eliminiert nicht die Vertrauensfrage, sie konzentriert sie.

Diese Konzentration ist der Grund, weshalb die „Vertrauenswürdigkeit von DNS-Anbietern“ keine Lifestylefrage ist, sondern eine Frage nach Macht. Wer DNS kontrolliert, kontrolliert nicht zwingend Inhalte, aber er kontrolliert die Indizienkette. Und Indizien sind in einer Welt, in der fast alles verschlüsselt ist, Goldstaub.

Mein Baukasten: Kohärenzfilter

Mein erster Zugang ist zuvorderst kein juristischer, kein politischer, nicht einmal primär ein technischer. Er ist epistemisch14. Ich nenne ihn Kohärenzfilter15.

Ein Kohärenzfilter ist nichts Mystisches. Es ist ein streng angewandter Plausibilitätsabgleich zwischen Behauptung und Wirklichkeit, zwischen Selbstbild und Messwert, zwischen Story und Nebenwirkung. Er fragt nicht: „Mag ich diese Leute?“ Er fragt: „Passt das zusammen?“ Und er ist gnadenlos, weil Inkohärenz selten ein Unfall ist. Meist ist sie ein Hinweis auf Incentives, auf Inkompetenz oder auf kalkulierte Vernebelung.

Das lässt sich in der Politik beobachten, in Konzernen, in Softwareprojekten, im Kleinen sogar in Bewerbungsgesprächen. Der Mechanismus ist stets ähnlich: Es gibt eine offizielle Erzählung, die moralisch gefällig oder ökonomisch opportun ist. Daneben existiert eine technische, rechtliche oder physikalische Realität. Wer beides nicht zusammenbringt, braucht irgendwann Zwang, Theater oder Diffamierung, um die Dissonanz zu überschminken.

Wer gelernt hat, Inkohärenz zu erkennen, kann Vertrauenswürdigkeit in anderen Bereichen wesentlich realistischer einschätzen. Und zwar ohne ad hominem16 zu operieren. Fakten werden nicht wahr, weil die „Guten“ sie sagen. Fakten werden wahr, wenn sie tragen.

Integrität als Lasttest

Kohärenz ist notwendig, aber nicht hinreichend. Es gibt Akteure, die können kohärent lügen. Die Politiker, Gewerkschaftler, Verbandspräsidenten, Kirchenfürsten, NGO-Lobbyisten, usw. usf. in unserer Zeit zeugen ein eindrucksvolles Beispiel davon. Die zweite Achse nenne ich Integritätsfilter.

Integrität zeigt sich nicht in Sonntagsreden. Integrität zeigt sich, wenn es ungemütlich wird: bei Gegenwind, bei politischem Druck, bei Shitstorms, bei Anwaltsbriefen, bei regulatorischen Drohkulissen, bei hysterischen Medienzyklen. Knickt jemand sofort ein, verschiebt Standards, verwässert Zusagen, löscht Aussagen, opfert Prinzipien für Ruhe im Karton, dann ist das kein „Pragmatismus“, sondern ein Signal über die innere Statik.

Diese Achse ist für DNS-Anbieter besonders relevant, weil sie an der Schnittstelle von Infrastruktur und Meinungsklima operieren. Blocklisten, „Sicherheitsfeatures“, Kooperationen mit Dritten, freiwillige „Abwehr“ gegen angebliche Desinformation: Es gibt hier eine breite Skala zwischen legitimer Malware-Abwehr und politischem Content-Governance-Theater. Wer behauptet, neutral zu sein, aber bei jedem Trend sofort die Linien nachzieht, zeigt keine Integrität, sondern Opportunismus, maximale Feigheit und die Abwesenheit von Freiheit.

Und Integrität ist keine moralische Zierde. Integrität ist Risikomanagement. Ein Anbieter ohne Rückgrat ist ein Anbieter, der morgen ein Feature ausrollt, das er heute noch als inakzeptabel bezeichnet, schlicht weil es gerade „erwartet“ wird. Ist der Sieg gwiss, dann kämpft jeder Feigling. Genau deshalb interessiert mich nicht, wie jemand handelt, wenn alles bequem ist. Mich interessiert, wie jemand handelt, wenn es kostet.

Messbares vor Erzähltem

An dieser Stelle wird es technisch, weil Technik der Teil der Wirklichkeit ist, der sich am schlechtesten wegreden lässt.

Bei Softwareanbietern und Infrastrukturbetreibern beginnt mein Vertrauensabgleich mit einer simplen Frage: Ist die PR kohärent mit dem, was ich beim ersten Blick hinter die Kulissen sehe? „Security first“ ist billig. Saubere Kryptographie, strikte Protokollpolitik, konsistente Header, korrekte Mailauthentisierung, saubere Zertifikatsketten, nachvollziehbare Betriebsprozesse sind teuer.

Ich schaue deshalb auf Indikatoren, die schwer zu fälschen sind, zumindest schwerer als ein Hochglanz-„Trust Center“. Nutzt jemand eigene Mailserver oder outsourced er alles an einen Hyperscaler und predigt gleichzeitig Souveränität? Wie sieht die TLS-Policy aus, nicht im PDF, sondern auf dem Wire? Welche Cipher Suites17 18 sind wirklich aktiv? Ist HSTS19 20 sauber gesetzt und preloaded? Stimmen CAA21-Records mit der gelebten Zertifikatsausstellung überein? Gibt es SPF22, DKIM23 und DMARC24, und zwar nicht als Alibi, sondern stringent? Werden DANE25 und DNSSEC26 ernst genommen oder bloss als Schmuck? Sind OPENPGPKEY27 28, SMIMEA29 oder TLSA30 konsistent gepflegt oder verlottern sie, sobald es mühsam wird? Hier fängt der Test erst an. OSINT und Recon lassen grüssen.

Das ist kein Fetisch. Das ist ein Belastungstest für Kultur. Wer in diesen Details schludert, schludert selten nur dort. Wer sie hingegen konsistent im Griff hat, erarbeitet sich einen Vertrauensvorschuss, nicht weil er „lieb“ ist, sondern weil er zeigt, dass er in der Lage ist, anspruchsvolle, unsichtbare Arbeit dauerhaft sauber zu leisten.

Die folgenden Werkzeuge sind für solche Realitätschecks praktisch, weil sie aus unterschiedlichen Blickwinkeln messen und man Inkohärenz zwischen den Resultaten oft schneller sieht als im Quelltext einer Marketingabteilung:

http://dnsviz.net/
http://test-ipv6.com/
http://www.gestioip.net/cgi-bin/subnet_calculator.cgi
https://amiunique.org/
https://asecuritysite.com/encryption/nprimes
https://badssl.com/
https://browserleaks.com/ip
https://caatest.co.uk/
https://censys.io/
https://centralops.net/co/
https://certlogik.com/decoder/
https://cidr-rechner.de/
https://ciphersuite.info/
https://cmdns.dev.dns-oarc.net/
https://coveryourtracks.eff.org/
https://crt.sh/
https://de.ssl-tools.net/
https://decoder.link/
https://developer.mozilla.org/en-US/observatory
https://distrochooser.de/de
https://dnschecker.org/
https://dnschecker.org/all-dns-records-of-domain.php
https://dnsleaktest.com/
https://dnslookup.online/
https://dnssec-debugger.verisignlabs.com/
https://easydmarc.com/tools/bimi-lookup
https://ednscomp.isc.org/
https://emkei.cz/
https://en.internet.nl/
https://gpsjam.org/
https://hackertarget.com/wordpress-security-scan/
https://headers.4tools.net/
https://hstspreload.org/
https://http3check.net/
https://httpstatus.io/
https://intodns.com/
https://ipleak.net/
https://ipv6-test.com/
https://keys.openpgp.org/
https://keyserver.ubuntu.com/
https://kuix.de/smime-keyserver/
https://lapo.it/asn1js/
https://leakix.net/
https://letsdebug.net/
https://m.emsc.eu/
https://messerinzidenz.de/
https://nettools.club/mac2ipv6
https://network-tools.webwiz.net/reverse-dns.htm
https://nuclearsecrecy.com/nukemap/
https://observatory.mozilla.org/
https://privacytests.org/
https://register.dpma.de/DPMAregister/Uebersicht
https://scan.nextcloud.com/
https://scanigma.com/
https://schema.org/
https://securityheaders.com/
https://shademap.app/
https://shadowban.yuzurisa.com/
https://siwecos.de/
https://ssd.jpl.nasa.gov/
https://stats.labs.apnic.net/quic
https://sucuri.net/
https://syslink.pl/cipherlist/
https://technicalseo.com/tools/robots-txt/
https://testssl.sh/
https://tineye.com/
https://tldr.sh/
https://tls.imirhil.fr/
https://tools.keycdn.com/curl
https://viewdns.info/
https://viz.greynoise.io/
https://webbkoll.dataskydd.net/de/
https://websniffer.com/
https://whatcms.org/
https://whatismyipaddress.com/blacklist-check
https://wigle.net/
https://wondernetwork.com/pings
https://www.abuseipdb.com/
https://www.acunetix.com/vulnerability-scanner/website-vulnerability-scanner-online/
https://www.bigdatacloud.com/asn-lookup/
https://www.browserling.com/
https://www.calcmaps.com/de/
https://www.canarytokens.org/generate
https://www.cvedetails.com/
https://www.cyberscan.io/
https://www.cybersicherheitsarchitektur.de/
https://www.debouncer.com/reverse-dns-check
https://www.dein-ip-check.de/tools/macfinder
https://www.experte.de/security-check
https://www.extro.hosting/blog/karte-der-weltweiten-unterseekabel.html
https://www.flightradar24.com/
https://www.flightradar24.com/data/gps-jamming
https://www.geo-tag.de/validator/en.php
https://www.hardenize.com/
https://www.immuniweb.com/ssl/
https://www.ipvoid.com/ip-blacklist-check/
https://www.keylength.com/en/4/
https://www.learndmarc.com/
https://www.misp-project.org/
https://www.perfect-privacy.com/en/tests/dns-leaktest
https://www.raid-calculator.com/default.aspx
https://www.redirect-checker.org/
https://www.rexswain.com/httpview.html
https://www.routeviews.org/routeviews/
https://www.schaffer-se.at/sseneu/tools/cidr-rechner-range-tool/
https://www.shadowserver.org/
https://www.shodan.io/
https://www.ssllabs.com/ssltest/
https://www.submarinecablemap.com/
https://www.superyachtfan.com/de/
https://www.tausquared.net/pages/ctf/rsa.html
https://www.themedetect.com/
https://www.tls-check.de/de
https://www.urlvoid.com/
https://www.whatsmydns.net/
https://www.who-hosts-this.com/
https://www.wireguardconfig.com/qrcode
https://zonemaster.iis.se/en/

Die Kunst liegt nicht darin, ein einzelnes Tool zu zitieren. Die Kunst liegt darin, Muster zu erkennen. Liefert SSL Labs ein A+, aber Internet.nl meckert über DNSSEC oder DANE? Zeigt Hardenize saubere Policy, aber Shodan listet einen vergessenen Dienstport? Stimmen Security-Header mit dem behaupteten Sicherheitsniveau überein, oder ist alles bloss „Klicki-Bunti“?

Wer diese Messwelt ernst nimmt, entwickelt ein Gespür für technische Wahrhaftigkeit. Und dieses Gespür ist übertragbar: Ein Arbeitgeber, der „Security Culture“ plakatiert, aber keinen Patchprozess hat, keine sauberen Secrets-Flows, keine klaren Verantwortlichkeiten, wird auch im Arbeitsrecht, in Krisenkommunikation und in Konflikten selten eine Figur machen, die man als integer bezeichnen würde.

Jurisdiktion: Recht als Rahmen, nicht als Garantie

Der Thread streift die DSGVO und die EU als vermeintlichen Vertrauensraum. Das ist typisch: Man klammert sich an Rechtsbegriffe, weil man technische Asymmetrien nicht auflösen kann. Der Reflex ist menschlich, aber er ist riskant.

Die DSGVO definiert Prinzipien wie Zweckbindung und Datenminimierung.31 Das ist wichtig. Es bedeutet aber nicht, dass ein Dienst „automatisch“ nichts loggt, nichts herausgibt oder nicht unter Druck gerät. Recht ist ein Rahmen für Streit, nicht die Abwesenheit von Streit. Ein Anbieter kann DSGVO-konform loggen, er kann DSGVO-konform an Strafverfolgung herausgeben, er kann sogar DSGVO-konform datenverarbeitende Dienstleister ketten. Und er kann trotzdem grob fahrlässig operieren, einfach weil Aufsicht nicht permanent auf dem Server sitzt.

Jurisdiktion ist dennoch nicht irrelevant. Sie ist ein Teil des Threat Models. Sie betrifft Geheimdienstzugriffe, Gag Orders, Transparency Reports, Haftung, Durchsuchungsrecht, Beschlagnahme. Nur: Sie ist nie alleinentscheidend. Wer aus „Sitz in der Schweiz“, die im Übrigen per se den gesamten ein- und ausgehenden Datenverkehr nachrichtendienstlich analysieren, oder „Server in der EU“ eine Vertrauenszusage ableitet, macht aus Geographie ein Glaubensbekenntnis.

Das gilt auch umgekehrt. Es gibt Anbieter in unpopulären Jurisdiktionen, die technisch hervorragend arbeiten und Transparenz liefern. Es gibt Anbieter im „richtigen“ Land, die im Ernstfall sofort einknicken oder schlicht inkompetent sind. Kohärenzfilter zuerst. Integritätsfilter danach. Rechtliche Rahmenbedingungen als Kontext, nicht als Ersatz für Realität.

Grenzen der Protokolle

Der Thread wirft Tor in die Runde. Das passiert immer dann, wenn Leute spüren, dass die Vertrauensfrage nicht sauber lösbar ist, und dann nach einer Architektur suchen, die Vertrauen durch Kryptographie ersetzt.

Tor ist beeindruckend. Tor ist auch begrenzt. Tor transportiert TCP-Streams; rohes UDP ist nicht das normale Transportgut, und genau deshalb sind klassische DNS-Anfragen über Port 53 als UDP im Tor-Netz nicht einfach „durchgereicht“. Wer DNS über Tor anonymisieren will, landet typischerweise bei DNS über HTTPS über Tor oder bei Proxys, die DNS in TCP verpacken. Das kann im Einzelfall sinnvoll sein, verschiebt aber wieder Vertrauen: nicht mehr zum lokalen ISP32, sondern zum Exit und zum DNS-Endpunkt, plus zu allen Teilen der Kette, die man nun zusätzlich betreibt.

Das ist kein Argument gegen Tor. Es ist ein Argument gegen Wunschdenken. Protokolle sind nicht ideologisch. Sie sind unerbittlich.

CenturionDNS

CenturionDNS ist aus einem simplen Motiv entstanden: Ich wollte einen Resolver betreiben, der technisch auf Spitzenniveau läuft, der Privacy nicht als Marketing benutzt, sondern als Default, und der Security nicht auf den ersten Meter ernst nimmt, sondern auch auf dem fünfzigsten. Und zwar nicht für andere, sondern für mich selbst. Weil ich es kann.

Jeder der mag, kann messen.

Messbar ist viel. Messbar sind Protokolle, Konfigurationen, erreichbare Endpunkte, Zertifikatsketten, DNSSEC-Verhalten, Response-Header, Fehlkonfigurationen, Exposure über Scanner, saubere Segmentierung zwischen öffentlicher Fläche und Verwaltung, zumindest dort, wo man nicht absichtlich Angriffsaufklärung betreibt. Messbar ist auch Konsistenz über Zeit: Hält jemand seine Security-Policy auch dann, wenn niemand hinschaut, oder fällt sie nach zwei Monaten Wartungsstress auseinander?

Nicht messbar ist der Teil, den jeder gern hätte: die absolute Gewissheit, dass wirklich nie geloggt wird, dass nie ein Mensch in ein System schaut, dass nie ein staatlicher Akteur Druck macht, dass nie ein Fehler passiert, dass nie ein Supply-Chain-Schaden zuschlägt. Wer das verspricht, ist entweder naiv oder verkauft Schlangenöl.

Was ich stattdessen tue, ist zweierlei.

Erstens gestalte ich die Systeme so, dass Logging weder für den Betrieb notwendig ist noch aus Bequemlichkeit „mitläuft“. Daten, die nicht anfallen, müssen nicht geschützt werden. Das ist die einzige wirklich robuste Privacy-Strategie.

Zweitens gilt gnadenlose Kohärenz zwischen Anspruch und Praxis. Wer bei DNSSEC, DANE, strikter TLS-Policy, sauberer Mailauthentisierung, konsistenter Hardening-Linie und minimaler Angriffsoberfläche sichtbar liefert, signalisiert, dass er die unbequemen Teile dieser Arbeit nicht scheut. Das ist kein Beweis für Tugend. Es ist ein Indiz für Kompetenz und Kultur. Und Kompetenz plus Kultur sind in der realen Welt oft der beste Proxy, den man bekommt.

Dazu kommt der Integritätsaspekt: Ich richte mich nicht nach dem leisesten Lüftchen. Ich baue Systeme, weil sie technisch und sicherheitlich richtig sind, weil ich selbst davon überzeugt bin, weil ich die Marterie verstehe, diese durchdringe, weil ich Fragen stelle, nicht weil ein Trend es gerade verlangt. Wer sich diesen Luxus nicht leisten will oder nicht leisten kann, sollte es offen sagen. Wer ihn behauptet, aber nicht lebt, wird früher oder später durch Inkohärenz entlarvt.

Vertrauen als Entscheidung unter Ungewissheit

Der Thread formuliert implizit die ehrliche Wahrheit: Selbst bei bester Recherche bleibt Ungewissheit. Man weiss nie alles. Es gibt unbekannte Unbekannte. Es gibt Dinge, die man erst erkennt, wenn sie schiefgehen. Wer so tut, als könne man Vertrauen in eine mathematische Gewissheit verwandeln, will sich vor Verantwortung drücken. Denn Vertrauen ist am Ende immer eine Entscheidung unter Risiko.

Genau deshalb besteht mein Methodenbaukasten aus Filtern, nicht aus Dogmen. Kohärenzfilter, damit ich mich nicht von Storytelling narkotisieren lasse. Integritätsfilter, damit ich nicht auf Opportunisten setze, die beim ersten Sturm ihr Wort vergessen. Technische Realitätschecks, damit ich mich nicht an „Zertifikate“ klammere, die bloss PDFs sind. Jurisdiktion als Kontext, damit ich Machtachsen sehe, aber nicht vergöttere. Und dann die letzte, unromantische Einsicht: Man wählt nicht das Gute gegen das Böse, die Welt ist ziemlich grau mit ein wenig Farbe, man wählt das geringere Risiko gegen das grössere.

Wer dieses Spiel nicht akzeptiert, endet zwangsläufig als Konsument von PR oder als Untertan von Moraltheater. Beides ist intellektuell bequem.33 Beides ist sicherheitlich fatal.

Der Titel dieses Textes ist deshalb nicht „Vom DNS“. Er ist „Vom Vertrauen“. DNS ist nur ein besonders scharfer Spiegel, weil er so wenig verzeiht. Und weil er so klar zeigt, wie schnell Menschen anfangen, Fakten ad hominem zu sortieren, statt ad factum.

  1. https://dnsforge.de/ ↩︎
  2. https://eddns.eu/ ↩︎
  3. https://en.wikipedia.org/wiki/Domain_Name_System#DNS_resolvers ↩︎
  4. https://coresecret.eu/2025/12/12/centuriondns-von-systemgrenzen/ ↩︎
  5. https://gdpr-text.com/pt/read/article-1/?col=2&lang1=pt&lang2=de ↩︎
  6. https://de.wikipedia.org/wiki/Tor_(Netzwerk) ↩︎
  7. https://de.wikipedia.org/wiki/Transmission_Control_Protocol ↩︎
  8. https://de.wikipedia.org/wiki/User_Datagram_Protocol ↩︎
  9. https://support.torproject.org/relays/legal-and-abuse/ddos/ ↩︎
  10. https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol_Secure ↩︎
  11. https://de.wikipedia.org/wiki/Leitungsverschl%C3%BCsselung ↩︎
  12. https://de.wikipedia.org/wiki/DNS_over_TLS ↩︎
  13. https://de.wikipedia.org/wiki/DNS_over_HTTPS ↩︎
  14. https://de.wikipedia.org/wiki/Epistemische_Logik ↩︎
  15. https://coresecret.eu/2025/12/04/von-kohaerenzfiltern-vom-sein/ ↩︎
  16. https://en.wikipedia.org/wiki/Ad_hominem ↩︎
  17. https://ciphersuite.info/ ↩︎
  18. https://en.wikipedia.org/wiki/Cipher_suite ↩︎
  19. https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security ↩︎
  20. https://hstspreload.org/ ↩︎
  21. https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization ↩︎
  22. https://en.wikipedia.org/wiki/Sender_Policy_Framework ↩︎
  23. https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail ↩︎
  24. https://en.wikipedia.org/wiki/DMARC ↩︎
  25. https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities ↩︎
  26. https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions ↩︎
  27. https://openpgpkey.info/ ↩︎
  28. https://datatracker.ietf.org/doc/html/rfc7929 ↩︎
  29. https://datatracker.ietf.org/doc/html/rfc8162 ↩︎
  30. https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities#TLSA_RR ↩︎
  31. https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng?utm_source=chatgpt.com ↩︎
  32. https://en.wikipedia.org/wiki/Internet_service_provider ↩︎
  33. https://coresecret.eu/2025/12/09/von-pauli-desmet-filtern-rausch-attraktoren-nullpunktsenergie-vom-totalitarismus/ ↩︎
Categories: Allgemein, Deutschland, Gesellschaft, IT
Tags: , , , ,

You may also like

Search: