Der Verein Freie Netze München e.V. betreibt unter dem Namen Freifunk München eines der größten ehrenamtlich getragenen, gemeinnützigen WLAN-Netze in Deutschland. Das Netz steht der Allgemeinheit offen – ohne Registrierung, ohne Anmeldung, ohne personenbezogene Datenerhebung. Als gemeinnütziger Verein setzen wir uns über den reinen Netzbetrieb hinaus für digitale Teilhabe und für die Freiheits- und Grundrechte im Internet ein.
Am 9. Juli 2026 hat das Europäische Parlament in einem umstrittenen Eilverfahren die Wiedereinführung der sogenannten „Chatkontrolle 1.0” beschlossen – jener Ausnahmeregelung (Verordnung (EU) 2021/1232), die es Anbietern von Kommunikations- und Hostingdiensten erlaubt, die Inhalte ihrer Nutzerinnen und Nutzer anlasslos und automatisiert zu durchsuchen. Wir nehmen hierzu Stellung.
Bereits in unseren Stellungnahmen zur Mindestspeicherung von IP-Adressen (November 2025) und zum Referentenentwurf zur IP-Adressspeicherung (Februar 2026) haben wir vor anlassloser Massenüberwachung gewarnt. Die Chatkontrolle folgt derselben verfehlten Logik – und geht noch einen Schritt weiter: Sie greift nicht nur auf Verkehrsdaten, sondern auf die Inhalte vertraulicher Kommunikation zu.
Das EU-Parlament hat die im April 2026 ausgelaufene Ausnahme vom Fernmeldegeheimnis reaktiviert. Sie erlaubt Anbietern wie Google, Meta oder Microsoft, unverschlüsselte Nachrichten, E-Mails und Cloud-Inhalte freiwillig und anlasslos nach bekanntem und unbekanntem Missbrauchsmaterial zu durchsuchen. Ende-zu-Ende-verschlüsselte Kommunikation wurde durch einen Änderungsantrag ausdrücklich ausgenommen.
Wir lehnen diesen Beschluss ab – sowohl in der Sache als auch wegen des Verfahrens, mit dem er zustande kam. Er normalisiert die anlasslose Durchleuchtung privater Kommunikation, missachtet einen mehrfach geäußerten gegenteiligen Willen des Parlaments und schwächt die Verhandlungsposition gegen die weit gefährlichere verpflichtende „Chatkontrolle 2.0”. Wir fordern eine grundrechtskonforme, zielgerichtete Alternative statt anlassloser Massenüberwachung.
Man könnte einwenden, die Chatkontrolle richte sich an Messenger- und Plattformanbieter, nicht an einen WLAN-Betreiber. Das ist formal richtig – und dennoch betrifft sie uns unmittelbar:
Die Chatkontrolle setzt kein Fehlverhalten und keinen Verdacht voraus. Sie durchsucht die Kommunikation aller – auch derjenigen, gegen die nichts vorliegt. Ein solches anlassloses Scannen vertraulicher Inhalte greift in die Artikel 7 (Achtung des Privatlebens und der Kommunikation) und 8 (Schutz personenbezogener Daten) der EU-Grundrechtecharta sowie in die Meinungs- und Informationsfreiheit (Art. 11) ein. Der Europäische Gerichtshof hat wiederholt klargestellt, dass anlasslose und unterschiedslose Überwachungsmaßnahmen das „absolut Notwendige” nicht überschreiten dürfen.
Wer alle Nachrichten durchleuchtet, behandelt alle Nutzenden vorsorglich als potenziell Verdächtige. Das widerspricht der rechtsstaatlichen Grundannahme der Unschuld. Der „Chilling Effect” – die vorauseilende Selbstzensur aus dem Bewusstsein, beobachtet zu werden – trifft freie Meinungsäußerung, Pressefreiheit und den Schutz von Quellen und Berufsgeheimnisträger:innen.
Automatisierte Erkennung – insbesondere die Suche nach unbekanntem Material – produziert in großer Zahl falsche Treffer. Familienfotos, einvernehmliche Kommunikation Erwachsener oder ärztliche und beraterische Inhalte geraten so in Verdacht und in die Hände privater Unternehmen und Behörden. Für die Betroffenen entsteht ein erheblicher Schaden, ohne dass ein Kind dadurch besser geschützt wäre.
Die jetzt beschlossene Regelung nimmt Ende-zu-Ende-verschlüsselte Kommunikation ausdrücklich aus. Das ist zu begrüßen – aber es darf nicht über die Richtung täuschen, in die das Vorhaben insgesamt weist:
Der jetzige Beschluss ist deshalb auch strategisch problematisch: Die auslaufende Ausnahme war eines der wenigen Druckmittel des Parlaments, um im Trilog eine grundrechtskonforme Lösung durchzusetzen. Mit ihrer Reaktivierung schwächt das Parlament die eigene Verhandlungsposition gegen die verpflichtende Variante.
Besonders kritisch bewerten wir das Zustandekommen des Beschlusses:
Kern des demokratischen Problems ist die Kombination aus Verfahren und Mehrheitslogik: Eine bereits mehrfach abgelehnte Regelung wurde über ein Eilverfahren zurück ins Plenum geholt, wo dann nicht mehr die Zustimmung, sondern erst die Ablehnung eine absolute Mehrheit gebraucht hätte. So konnte sich eine Regelung durchsetzen, gegen die sich in der ersten Abstimmung eine Mehrheit der Abstimmenden aussprach.
Auch aus dem Parlament selbst kam scharfe Kritik am Verfahren: Abgeordnete mehrerer Fraktionen bezeichneten das Vorgehen als Missbrauch eines Eilverfahrens, um eine bereits abgelehnte Überwachungsregelung durch die Hintertür wieder auf die Tagesordnung zu bringen.
Unsere Kritik teilt ein breites Bündnis aus Zivilgesellschaft, Wissenschaft, Wirtschaft, Strafverfolgung und Kinderschutz:
Gesellschaft für Informatik (GI). Der Fachbereich Sicherheit der GI warnte Ende Juni 2026 ausdrücklich vor der drohenden Kehrtwende – sowohl bei der befristeten Regelung als auch bei der CSA-Verordnung – und kritisierte auch die Umgehung bereits gefasster Parlamentsentscheidungen durch Verfahrenskniffe. Eine Politik, die Millionen Unverdächtige unter Generalverdacht stelle, sei kein wirksamer Kinderschutz, sondern erzeuge Scheinsicherheit und binde Ermittlungsressourcen durch Fehlalarme. Statt der faktischen Abschaffung sicherer Ende-zu-Ende-Kommunikation brauche es spezialisierte Ermittlungsstellen, bessere internationale Zusammenarbeit, schnellere Auswertung konkreter Hinweise, Opferunterstützung und konsequente Strafverfolgung. (GI, 26.06.2026)
Chaos Computer Club (CCC). Der CCC lehnt die Chatkontrolle als schwersten Grundrechtseingriff ab und verweist darauf, dass ein Client-Side-Scanning sicherer Kommunikationsinfrastruktur Tür und Tor für Angriffe öffne. Ein solches allgemeines Scannen sei zudem mit der Rechtsprechung des EuGH unvereinbar; auch der Juristische Dienst des Rates und der UN-Hochkommissar für Menschenrechte hielten es für rechtswidrig. (CCC, 03.10.2025)
European Digital Rights (EDRi). Das europäische Bürgerrechtsnetzwerk EDRi koordiniert die Kampagne „Stop Scanning Me“ und hat gemeinsam mit 39 weiteren Organisationen die Abgeordneten aufgefordert, eine Verlängerung der „Chatkontrolle 1.0“ ohne wirksamen Ausschluss anlassloser Massenüberwachung abzulehnen. EDRi pflegt zudem eine öffentliche Dokumentensammlung zur CSA-Verordnung. (EDRi, 23.02.2026 · EDRi-Dokumentenpool)
Deutscher Kinderschutzbund. Der mitgliederstärkste deutsche Kinderschutzverband lehnt das anlasslose Scannen privater Kommunikation als „weder zielführend noch verhältnismäßig“ ab und fordert „zielgerichtete Maßnahmen statt anlassloser Massenüberwachung“. Er weist darauf hin, dass auch Kinder ein Recht auf vertrauliche Kommunikation haben und dass Missbrauchsdarstellungen in der Regel nicht über private Messenger, sondern über File-Hosting-Dienste verbreitet werden. (Kinderschutzbund, 28.02.2023 · netzpolitik.org, 06.10.2025)
Gesellschaft für Freiheitsrechte (GFF) und weitere Sachverständige. In Anhörungen haben Fachleute wie Felix Reda (GFF) und Ella Jakubowska (EDRi) den Verordnungsentwurf detailliert als grundrechtswidrig zerlegt. (Digitale Gesellschaft, 06.03.2023)
Strafverfolgungsbehörden. Auch aus den Reihen der Ermittler kommt Ablehnung: Der Leitende Oberstaatsanwalt Markus Hartmann (Zentral- und Ansprechstelle Cybercrime NRW) hält die geplanten Maßnahmen für kontraproduktiv und warnt vor Sicherheitsrisiken und der Signalwirkung für autoritäre Staaten. (Deutscher Bundestag, 01.03.2023)
Bemerkenswert ist die Einigkeit zwischen Datenschützer:innen, Bürgerrechtler:innen, Wissenschaft, Strafverfolgung und Kinderschützer:innen. Sie entkräftet die immer wieder aufgestellte Behauptung, Grundrechtsschutz und Kinderschutz stünden im Widerspruch. Das Gegenteil ist der Fall: Ein Instrument, das technisch unzuverlässig ist, Vertrauen zerstört und die Sicherheit aller schwächt, schützt keine Kinder. Kinderrechte verlangen beides – Schutz vor Gewalt und das Recht auf geschützte Kommunikation.
Wirksamer Kinderschutz ist möglich – ohne anlassige Massenüberwachung. Zielführend sind insbesondere:
Wir fordern:
Der Beschluss vom 9. Juli 2026 normalisiert die anlasslose Durchleuchtung privater Kommunikation und weist den Weg zu einer Überwachungsinfrastruktur, wie es sie so bisher nicht gab. Er wurde gegen den mehrfach erklärten Willen des Parlaments und mithilfe fragwürdiger Verfahrenskniffe herbeigeführt. Vertrauliche Kommunikation und funktionierende Verschlüsselung sind kein Hindernis für den Schutz von Kindern, sondern eine Voraussetzung für die Sicherheit und Freiheit aller – gerade der Verletzlichsten.
Wir appellieren an die Bundesregierung und die deutschen Abgeordneten im Rat und im Europäischen Parlament, sich für den Schutz vertraulicher Kommunikation einzusetzen und der anlasslosen Chatkontrolle in jeder Form eine klare Absage zu erteilen.
Freifunk München / Freie Netze München e.V.
Parkstraße 28, 82131 Gauting
Eingetragen im Vereinsregister beim Amtsgericht München – VR 206402
Web: https://ffmuc.net
E-Mail: info@ffmuc.net
Liebe Freifunkerinnen und Freifunker,
am 1. August 2026 verteilen wir per automatischem Update die Firmware v2025.12.3 an alle Knoten. Es handelt sich um ein kleines Wartungsupdate mit einer wichtigen Fehlerbehebung: Es behebt einen Fehler, der den Update-Vorgang selbst betreffen kann.
Das Wichtigste in Kürze:
Die Firmware-Version eures Knotens findet ihr auf dessen Statusseite oder auf der Knotenkarte.
| Eure Firmware | Risiko |
|---|---|
| v2025.12.3 oder neuer | ✅ Nicht betroffen, nichts zu tun |
| v2025.6.1 bis v2025.12.2 | ⚠️ Update kann hängen bleiben - Anleitung unten |
| älter als v2025.6.1 | ✅ Nicht betroffen, das manuelle Update ist dennoch empfohlen |
Betroffen sind Knoten, die per WLAN meshen (802.11s) und dabei Mesh-Nachbarn in Reichweite haben. Knoten, die ausschließlich per VPN oder Kabel (Mesh-on-LAN/WAN) angebunden sind, sind nicht betroffen; die Anleitung kann aber auch dort gefahrlos angewendet werden.
Beim Stable-Rollout im Januar blieben rund 10 % der Knoten beim Update hängen. Anhand von Rückmeldungen und Logs aus der Community konnten wir die Ursache ermitteln: ein Fehler in batman-adv, unserem Mesh-Routing-Protokoll. Beim Herunterfahren der WLAN-Mesh-Schnittstellen während des Updates können sich zwei Teile des Kernels gegenseitig blockieren (ein sogenannter Deadlock). Der Update-Vorgang erreicht dadurch nie das eigentliche Flashen, und der Knoten bleibt in diesem Zustand hängen.
Der Fehler ist inzwischen im offiziellen Linux-Kernel behoben, und v2025.12.3 enthält genau diesen Fix. Die Schwierigkeit dabei: Während des Updates läuft noch die alte Firmware, die den Fehler noch enthält. Deshalb kann bereits das Update auf die fehlerbereinigte Version selbst hängen bleiben.
Bitte nur ausführen, wenn euer Knoten v2025.12.2 oder älter hat (siehe Tabelle oben). Voraussetzung ist SSH-Zugriff auf euren Knoten (SSH-Schlüssel oder Passwort, wie im Config-Mode hinterlegt).
Schritt 1: Per SSH mit dem Knoten verbinden (die Adresse findet ihr z. B. auf der Knotenkarte):
ssh root@<adresse-eures-knotens>
Schritt 2: Diese Zeilen als Ganzes kopieren, einfügen und mit Enter bestätigen:
for i in $(batctl if | cut -d: -f1); do
[ -d "/sys/class/net/$i/phy80211" ] && batctl hardif "$i" throughput_override 10mbit
done
sleep 5
autoupdater -f -b experimental
Die ersten Zeilen umgehen die fehlerhafte Stelle in batman-adv (das WLAN-Mesh erhält bis zum nächsten Neustart einen festen statt eines laufend gemessenen Metrik-Werts, was unbedenklich ist). Die letzte Zeile installiert v2025.12.3 sofort. Der Zusatz »experimental« bedeutet hier nicht, dass eine experimentelle Firmware installiert wird: Es handelt sich um exakt dieselbe Version v2025.12.3, die am 1. August ohnehin verteilt wird; sie wird an dieser Stelle lediglich vorab bereitgestellt. Der Knoten bleibt dauerhaft auf dem stable-Zweig, die Option gilt nur für diesen einen Aufruf.
Schritt 3: Abwarten. Der Knoten lädt die neue Firmware, die SSH-Verbindung bricht ab, und der Knoten startet neu. Nach etwa 10 Minuten ist er mit v2025.12.3 wieder online. Der Vorgang ist damit abgeschlossen; das automatische Update am 1. August betrifft den Knoten dann nicht mehr.
Zwei Hinweise:
Dann versucht der Knoten das Update ab dem 1. August automatisch - ohne den beschriebenen Schutz. In den meisten Fällen verläuft das Update ohne Probleme. Andernfalls bleibt der Knoten hängen: Er ist offline und aus der Ferne nicht erreichbar. In diesem Fall hilft nur, den Stromstecker zu ziehen, 10 Sekunden zu warten und ihn wieder einzustecken.
Dabei entsteht kein dauerhafter Schaden: Der Knoten startet anschließend mit der alten Firmware und versucht das Update später erneut. Dabei kann er wieder hängen bleiben, bis das Update einmal erfolgreich durchläuft. Wir empfehlen daher, nach dem 1. August kurz auf der Karte zu prüfen, ob der Knoten noch online ist.
Wer Knoten an schwer zugänglichen Standorten betreibt (Dach, Keller, Ferienhaus …), dem empfehlen wir das manuelle Update besonders.
Ab v2025.12.3 ist der Fehler behoben, und alle weiteren Updates laufen wieder normal.
Für alle, die es genau wissen wollen: Der Deadlock steckt im ELP-Metrik-Worker von B.A.T.M.A.N. V. Beim Abbau einer WLAN-Mesh-Schnittstelle wird der Worker unter gehaltenem RTNL-Lock per cancel_delayed_work_sync() beendet - während der Worker selbst gerade auf rtnl_lock() wartet. Beide warten aufeinander, für immer. Das throughput_override aus der Anleitung sorgt dafür, dass der Worker die betroffene Code-Stelle gar nicht erst erreicht. Details stehen in unserem Issue #776 und im Kernel-Commit.
Vielen Dank an alle, die im Januar Logs und Hinweise beigesteuert haben, an Sören Skaarup für das Testen sowie an Sven Eckelmann vom batman-adv-Projekt für den schnellen Fix. Aus einer Fehlermeldung der Community ist so ein Patch im offiziellen Linux-Kernel entstanden.
Bei Fragen oder Problemen meldet euch gerne im Firmware-Channel.
Viele Grüße Euer Freifunk München Team
On August 1, 2026 we will roll out firmware v2025.12.3 to all nodes via automatic update. This is a small maintenance release with one important fix: it addresses a bug that can affect the update process itself.
The short version:
You can find your node’s firmware version on its status page or on the node map.
| Your firmware | Risk |
|---|---|
| v2025.12.3 or newer | ✅ Not affected, nothing to do |
| v2025.6.1 to v2025.12.2 | ⚠️ Update may hang, see instructions below |
| older than v2025.6.1 | ✅ Not affected, but manual update is recommended |
Affected are nodes that mesh via Wi-Fi (802.11s) and have mesh neighbors in range. Nodes connected exclusively via VPN or cable (mesh-on-LAN/WAN) are not affected; the instructions can, however, be applied there safely as well.
During the stable rollout in January, around 10 % of nodes hung during the update. Based on reports and logs from the community, we were able to determine the cause: a bug in batman-adv, our mesh routing protocol. When the Wi-Fi mesh interfaces are shut down during the update, two parts of the kernel can block each other (a so-called deadlock). As a result, the update never reaches the actual flashing stage, and the node remains stuck in this state.
The bug has since been fixed in the official Linux kernel, and v2025.12.3 contains exactly this fix. The difficulty is that during the update, the old firmware — which still contains the bug — is running. As a result, the update to the fixed version can itself still hang.
Please only do this if your node runs v2025.12.2 or older (see the table above). You need SSH access to your node (SSH key or password, as configured in config mode).
Step 1: Connect to your node via SSH (you can find its address on the node map):
ssh root@<address-of-your-node>
Step 2: Copy the following lines as a whole, paste them, and confirm with Enter:
for i in $(batctl if | cut -d: -f1); do
[ -d "/sys/class/net/$i/phy80211" ] && batctl hardif "$i" throughput_override 10mbit
done
sleep 5
autoupdater -f -b experimental
The first lines route around the buggy code path in batman-adv (until the next reboot, the Wi-Fi mesh uses a fixed link metric instead of a continuously measured one, which is harmless). The last line installs v2025.12.3 right away. The “experimental” flag here does not mean an experimental firmware is being installed: it is exactly the same v2025.12.3 that will be rolled out on August 1 anyway; it is simply made available ahead of time through this channel. The node permanently remains on the stable branch; the flag only applies to this single invocation.
Step 3: Wait. The node downloads the new firmware, the SSH connection drops, and the node reboots. After about 10 minutes it will be back online running v2025.12.3. The process is then complete, and the automatic update on August 1 will no longer apply to this node.
Two notes:
In that case, the node will attempt the update automatically starting August 1 - without the protection described above. In most cases, the update completes without issues. Otherwise, the node hangs: it is offline and unreachable remotely. In that case, the only remedy is to pull the power plug, wait 10 seconds, and plug it back in.
This causes no permanent damage: the node then boots the old firmware and will retry the update later. It may hang again in the process until the update eventually succeeds. We therefore recommend checking the map after August 1 to confirm the node is still online.
For nodes in hard-to-reach places (rooftop, basement, holiday home …), we especially recommend the manual update.
From v2025.12.3 on, the bug is fixed and all further updates will work normally again.
For those who want the details: the deadlock lives in the ELP metric worker of B.A.T.M.A.N. V. When a Wi-Fi mesh interface is torn down, the worker is stopped via cancel_delayed_work_sync() while the RTNL lock is held - while the worker itself is waiting on rtnl_lock(). Both wait for each other, forever. The throughput_override from the instructions ensures the worker never reaches the affected code path in the first place. Details can be found in our issue #776 and in the kernel commit.
Thank you to everyone who contributed logs and hints in January, to Sören Skaarup for testing, and to Sven Eckelmann from the batman-adv project for the quick fix. A bug report from our community turned into a patch in the official Linux kernel.
If you have questions or run into problems, please reach out in the firmware channel.
Best regards Your Freifunk München Team
Auch dieses Wochenende ist Freifunk Muenchen wieder auf dem Corso Leopold mit einem Stand vertreten.
Die Termine sind Samstag, 20.06.2026 und Sonntag, 21.06.2026. Das offizielle Programm findet ihr hier:
https://corso-leopold.de/cl/programm/2026-Juni.php
Kommt vorbei, lernt uns kennen und sprecht mit uns ueber unsere Mission: freier Netzzugang fuer alle, digitale Selbstbestimmung, Privatsphaere und Datenschutz, gemeinschaftlicher Wissensaustausch sowie offene, gemeinwohlorientierte Internet-Dienste.
Wir beantworten eure Fragen rund um Freifunk, zeigen euch, wie ihr mitmachen koennt, und geben euch praktische Tipps, wie ihr euer Internet-Setup zuhause sicherer machen koennt (zum Beispiel mit sinnvollen DNS-Einstellungen, Updates, verschluesseltem DNS und einer sauberen Trennung von Heimnetz und Gaestenetz).
Ihr findet uns hier:
https://map.ffmuc.net/#/de/map/ae2b4d1cb6ba
Weitere Infos:
Wir freuen uns auf euch!
This weekend, Freifunk Munich is back at Corso Leopold with an info booth.
The dates are Saturday, 20 June 2026 and Sunday, 21 June 2026. You can find the official event program here:
https://corso-leopold.de/cl/programm/2026-Juni.php
Come by, meet us, and talk to us about our mission: free network access for everyone, digital self-determination, privacy and data protection, community knowledge sharing, and open public-interest internet services.
We are happy to answer your questions about Freifunk, show you how to get involved, and share practical tips to make your home internet setup safer (for example with solid DNS settings, updates, encrypted DNS, and clear separation between home and guest networks).
You can find us here:
https://map.ffmuc.net/#/de/map/ae2b4d1cb6ba
More information:
We are looking forward to seeing you!
Ce week-end, Freifunk Munich sera de nouveau present au Corso Leopold avec un stand d’information.
Les dates sont samedi 20/06/2026 et dimanche 21/06/2026. Le programme officiel est disponible ici :
https://corso-leopold.de/cl/programm/2026-Juni.php
Passez nous voir, faites notre connaissance et parlez avec nous de notre mission : un acces libre au reseau pour toutes et tous, l’autodetermination numerique, la protection de la vie privee, le partage de connaissances dans la communaute et des services Internet ouverts d’interet general.
Nous repondrons a vos questions sur Freifunk, nous vous montrerons comment participer, et nous partagerons des conseils pratiques pour rendre votre installation Internet a la maison plus sure (par exemple avec de bons parametres DNS, des mises a jour regulieres, DNS chiffre et une separation claire entre reseau prive et reseau invite).
Vous nous trouverez ici :
https://map.ffmuc.net/#/de/map/ae2b4d1cb6ba
Plus d’informations :
Au plaisir de vous rencontrer !
Este fin de semana, Freifunk Munich vuelve a estar en Corso Leopold con un puesto informativo.
Las fechas son sabado 20/06/2026 y domingo 21/06/2026. El programa oficial del evento esta aqui:
https://corso-leopold.de/cl/programm/2026-Juni.php
Ven a conocernos y habla con nosotros sobre nuestra mision: acceso libre a la red para todas las personas, autodeterminacion digital, privacidad y proteccion de datos, intercambio de conocimiento en comunidad y servicios abiertos de Internet orientados al bien comun.
Respondemos a tus preguntas sobre Freifunk, te mostramos como participar, y compartimos consejos practicos para hacer mas segura tu conexion de Internet en casa (por ejemplo con una buena configuracion de DNS, actualizaciones, DNS cifrado y una separacion clara entre red domestica y red de invitados).
Nos encuentras aqui:
https://map.ffmuc.net/#/de/map/ae2b4d1cb6ba
Mas informacion:
Te esperamos!
Tsikh vykhidnykh Freifunk Munich znovu bude na Corso Leopold iz informatsiinym stendom.
Daty podii: subota, 20.06.2026 ta nedilia, 21.06.2026. Ofitsiina prohrama zakhodu tut:
https://corso-leopold.de/cl/programm/2026-Juni.php
Zavitaite do nas, poznaiomtesia z namy ta pohovorimo pro nashu misiiu: vilnyi dostup do merezhi dlia vsikh, tsyfrova samovyznachenist, pryvatnist i zakhyst danykh, obmin znanniamy v hromadi ta vidkryti suspilno-korysni internet-servisy.
My vidpovimo na vashi pytannia pro Freifunk, pokazhemo yak doluchytysia, ta podilymosia praktychnymy poradamy, yak zrobyty domashnie internet-nalashtuvannia bezpechnishym (napryklad, nadiine DNS-nalashtuvannia, onovlennia, shyfrovane DNS ta chitke rozdilennia domashnoi ta hostovoi merezh).
Nas mozhna znaity tut:
https://map.ffmuc.net/#/de/map/ae2b4d1cb6ba
Bilsh informatsii:
Chekaiemo na vas!
Update zur gestrigen Meldung: Die DNSSEC-Störung bei der DENIC ist behoben. Alle .de-Domains sind wieder normal erreichbar.
Wir haben die DNSSEC-Validierung für die .de-Zone auf unseren Nameservern wieder aktiviert:
rec_control clear-nta de.Damit ist der reguläre Betrieb mit voller DNSSEC-Validierung auf unseren DNS-Servern wiederhergestellt.
Das Setzen eines sogenannten Negative Trust Anchor (NTA) ist ein standardisiertes Verfahren, das in RFC 7646 beschrieben wird. Ein NTA deaktiviert die DNSSEC-Validierung gezielt für eine bestimmte Zone – in diesem Fall .de – ohne die Validierung für alle anderen Domains zu beeinträchtigen.
Laut RFC 7646 sind NTAs genau für solche Situationen vorgesehen: Wenn eine DNSSEC-Störung nicht durch einen Angriff, sondern durch eine Fehlkonfiguration oder einen Ausfall auf Seiten des Zonenbetreibers verursacht wird. Die Alternative – dass Nutzer auf nicht-validierende DNS-Resolver ausweichen – wäre deutlich schädlicher für die Sicherheit, da dann sämtliche DNSSEC-Validierung verloren ginge.
Nach Behebung der Störung haben wir den NTA umgehend entfernt und die volle DNSSEC-Validierung wiederhergestellt – wie es RFC 7646 empfiehlt.
06. Mai 2026 – Frankfurt am Main – Die DENIC eG verzeichnete eine Störung ihres DNS-Dienstes für .de-Domains. Hiervon waren insbesondere DNSSEC-signierte .de-Domains in ihrer Erreichbarkeit vorübergehend eingeschränkt.
Das Problem ist behoben und alle Systeme arbeiten wieder im Normalbetrieb.
Die genaue Ursache des Vorfalls wird noch analysiert. Die technischen Teams der DENIC setzen die Untersuchung fort und werden weitere Details veröffentlichen, sobald belastbare Erkenntnisse vorliegen.
Die DENIC dankt allen Betroffenen für ihre Geduld und ihr Verständnis.
Quelle: DENIC Blog
Update to yesterday’s post: The DNSSEC disruption at DENIC has been resolved. All .de domains are reachable again.
We have re-enabled DNSSEC validation for the .de zone on our nameservers:
rec_control clear-nta de.Regular operation with full DNSSEC validation on our DNS servers has been restored.
Setting a so-called Negative Trust Anchor (NTA) is a standardised procedure described in RFC 7646. An NTA disables DNSSEC validation specifically for a single zone – in this case .de – without affecting validation for any other domains.
According to RFC 7646, NTAs are designed for exactly this kind of situation: when a DNSSEC failure is caused not by an attack, but by a misconfiguration or outage on the zone operator’s side. The alternative – users switching to non-validating DNS resolvers – would be far more harmful to security, as it would disable all DNSSEC validation entirely.
Once the disruption was resolved, we promptly removed the NTA and restored full DNSSEC validation – as recommended by RFC 7646.
6 May 2026 – Frankfurt am Main – DENIC eG experienced a disruption in its DNS service for .de domains. As a result, there were temporary limitations in the reachability of .de domains, in particular those signed with DNSSEC.
The issue has been resolved and all systems are now operating normally again.
The root cause of the incident is still under analysis. DENIC’s technical teams are continuing to investigate and will share further details as soon as reliable findings are available.
DENIC thanks all affected parties for their patience and understanding.
Source: DENIC Blog
Mise à jour du post d’hier : La perturbation DNSSEC chez DENIC est résolue. Tous les domaines .de sont de nouveau accessibles.
Nous avons réactivé la validation DNSSEC pour la zone .de sur nos serveurs DNS :
rec_control clear-nta de.Le fonctionnement normal avec validation DNSSEC complète sur nos serveurs DNS est rétabli.
La mise en place d’un Negative Trust Anchor (NTA) est une procédure standardisée décrite dans la RFC 7646. Un NTA désactive la validation DNSSEC de manière ciblée pour une zone spécifique – dans ce cas .de – sans affecter la validation pour les autres domaines.
Selon la RFC 7646, les NTA sont conçus exactement pour ce type de situation : lorsqu’une défaillance DNSSEC n’est pas causée par une attaque, mais par une erreur de configuration ou une panne du côté de l’opérateur de la zone. L’alternative – que les utilisateurs basculent vers des résolveurs DNS non validants – serait bien plus dangereuse pour la sécurité, car elle désactiverait toute la validation DNSSEC.
Une fois la perturbation résolue, nous avons rapidement supprimé le NTA et rétabli la validation DNSSEC complète – conformément aux recommandations de la RFC 7646.
6 mai 2026 – Francfort-sur-le-Main – DENIC eG a subi une perturbation de son service DNS pour les domaines .de. En conséquence, la joignabilité des domaines .de, en particulier ceux signés avec DNSSEC, a été temporairement limitée.
Le problème est résolu et tous les systèmes fonctionnent de nouveau normalement.
La cause exacte de l’incident est encore en cours d’analyse. Les équipes techniques de DENIC poursuivent l’enquête et communiqueront des détails supplémentaires dès que des résultats fiables seront disponibles.
DENIC remercie toutes les parties concernées pour leur patience et leur compréhension.
Source : Blog DENIC
Actualización del artículo de ayer: La interrupción DNSSEC en DENIC ha sido resuelta. Todos los dominios .de vuelven a estar accesibles.
Hemos reactivado la validación DNSSEC para la zona .de en nuestros servidores de nombres:
rec_control clear-nta de.El funcionamiento normal con validación DNSSEC completa en nuestros servidores DNS ha sido restablecido.
Establecer un Negative Trust Anchor (NTA) es un procedimiento estandarizado descrito en RFC 7646. Un NTA desactiva la validación DNSSEC específicamente para una zona concreta – en este caso .de – sin afectar a la validación de otros dominios.
Según RFC 7646, los NTA están diseñados exactamente para este tipo de situación: cuando un fallo DNSSEC no es causado por un ataque, sino por un error de configuración o una caída del lado del operador de la zona. La alternativa – que los usuarios cambien a resolvedores DNS sin validación – sería mucho más perjudicial para la seguridad, ya que desactivaría toda la validación DNSSEC por completo.
Una vez resuelta la interrupción, eliminamos rápidamente el NTA y restauramos la validación DNSSEC completa, tal como recomienda RFC 7646.
6 de mayo de 2026 – Fráncfort del Meno – DENIC eG experimentó una interrupción en su servicio DNS para dominios .de. Como resultado, hubo limitaciones temporales en la accesibilidad de los dominios .de, en particular los firmados con DNSSEC.
El problema ha sido resuelto y todos los sistemas funcionan con normalidad de nuevo.
La causa raíz del incidente aún está siendo analizada. Los equipos técnicos de DENIC continúan investigando y compartirán más detalles tan pronto como se disponga de hallazgos fiables.
DENIC agradece a todas las partes afectadas su paciencia y comprensión.
Fuente: Blog DENIC
Оновлення до вчорашнього повідомлення: Збій DNSSEC у DENIC усунено. Усі домени .de знову доступні.
Ми знову увімкнули валідацію DNSSEC для зони .de на наших серверах імен:
rec_control clear-nta de.Нормальну роботу з повною валідацією DNSSEC на наших DNS-серверах відновлено.
Встановлення так званого Negative Trust Anchor (NTA) – це стандартизована процедура, описана в RFC 7646. NTA вимикає валідацію DNSSEC цілеспрямовано для конкретної зони – у цьому випадку .de – не впливаючи на валідацію інших доменів.
Згідно з RFC 7646, NTA призначені саме для таких ситуацій: коли збій DNSSEC спричинений не атакою, а помилкою конфігурації або збоєм на стороні оператора зони. Альтернатива – перехід користувачів на DNS-резолвери без валідації – була б значно небезпечнішою, оскільки це вимкнуло б всю валідацію DNSSEC повністю.
Після усунення збою ми негайно видалили NTA та відновили повну валідацію DNSSEC – відповідно до рекомендацій RFC 7646.
6 травня 2026 – Франкфурт-на-Майні – DENIC eG зазнала збою у своєму DNS-сервісі для доменів .de. Внаслідок цього доступність доменів .de, зокрема підписаних DNSSEC, була тимчасово обмежена.
Проблему вирішено, і всі системи знову працюють у нормальному режимі.
Основна причина інциденту ще аналізується. Технічні команди DENIC продовжують розслідування та повідомлять додаткові деталі, щойно будуть отримані надійні результати.
DENIC дякує всім постраждалим за терпіння та розуміння.
Джерело: Блог DENIC
Seit ca. 22:00 Uhr (MESZ) am 05.05.2026 besteht eine massive Störung bei der DENIC, dem deutschen Domain-Registrar. Dadurch sind alle DNSSEC-signierten .de-Domains derzeit in ihrer Erreichbarkeit betroffen.
Betroffen sind alle DNSSEC-signierten Websites und Dienste unter der .de-Top-Level-Domain. Der Zugriff ist aktuell nur noch möglich, wenn die Domain-Auflösung noch im DNS-Cache eures Routers oder Providers gespeichert ist. Sobald dieser Cache abläuft, kommt es zu Verbindungsfehlern im Browser.
.de-Websites können für Besucher teilweise oder vollständig nicht erreichbar sein.de-Domains können betroffen sein, wenn deren Nameserver selbst unter .de laufen. Beispiel: Die Domain example.com nutzt als Nameserver ns1.hoster.de und ns2.hoster.de – wenn hoster.de DNSSEC-signiert ist und nicht aufgelöst werden kann, ist auch example.com nicht erreichbarUm euch trotz der Störung ungestörtes Surfen zu ermöglichen, haben wir auf unseren Nameservern die DNSSEC-Validierung für die .de-Zone vorübergehend deaktiviert:
rec_control add-nta de.Das bedeutet: Wenn ihr unsere DNS-Server nutzt, könnt ihr .de-Domains weiterhin erreichen.
Das Setzen eines sogenannten Negative Trust Anchor (NTA) ist ein standardisiertes Verfahren, das in RFC 7646 beschrieben wird. Ein NTA deaktiviert die DNSSEC-Validierung gezielt für eine bestimmte Zone – in diesem Fall .de – ohne die Validierung für alle anderen Domains zu beeinträchtigen.
Laut RFC 7646 sind NTAs genau für solche Situationen vorgesehen: Wenn eine DNSSEC-Störung nicht durch einen Angriff, sondern durch eine Fehlkonfiguration oder einen Ausfall auf Seiten des Zonenbetreibers verursacht wird. Die Alternative – dass Nutzer auf nicht-validierende DNS-Resolver ausweichen – wäre deutlich schädlicher für die Sicherheit, da dann sämtliche DNSSEC-Validierung verloren ginge.
Der NTA wird entfernt, sobald die Störung behoben ist und die .de-Zone wieder korrekt validiert.
Eine Anleitung zur Einrichtung unserer DNS-Server findet ihr hier:
Weitere Informationen zu unserem DNS-Angebot gibt es auf unserer DNS-Privacy-Seite.
05. Mai 2026, 23:28 MESZ – Frankfurt am Main – Die DENIC eG verzeichnet derzeit eine Störung ihres DNS-Dienstes für .de-Domains. Hiervon sind aktuell alle DNSSEC-signierten .de-Domains in ihrer Erreichbarkeit betroffen.
Die genaue Ursache der Störung ist noch nicht abschließend identifiziert. Die technischen Teams der DENIC arbeiten intensiv an der Analyse und an der schnellstmöglichen Wiederherstellung des stabilen Betriebs.
Nach aktuellem Kenntnisstand kann es für Nutzerinnen und Nutzer sowie Betreiber von .de-Domains zu Beeinträchtigungen bei der Domain-Auflösung kommen. Weitere Updates werden bereitgestellt, sobald belastbare Erkenntnisse zur Ursache und zur Wiederherstellung vorliegen.
Die DENIC bittet alle Betroffenen um Verständnis.
Den aktuellen Status der Störung könnt ihr bei der DENIC selbst einsehen und euch für automatische Benachrichtigungen anmelden:
Sobald die Störung auf DENIC-Seite behoben ist, werden wir die DNSSEC-Validierung wieder aktivieren.
Since approximately 10:00 PM (CEST) on 05 May 2026, there has been a major outage at DENIC, the German domain registrar. As a result, all DNSSEC-signed .de domains are currently affected in their reachability.
All DNSSEC-signed websites and services under the .de top-level domain are affected. Access is currently only possible if the domain resolution is still cached in your router’s or provider’s DNS cache. Once this cache expires, you will experience connection errors in your browser.
.de websites may be partially or completely unreachable for visitors.de domains can also be affected if their nameservers run under .de. Example: The domain example.com uses ns1.hoster.de and ns2.hoster.de as nameservers – if hoster.de is DNSSEC-signed and cannot be resolved, example.com will also be unreachableTo allow you to continue browsing despite the outage, we have temporarily disabled DNSSEC validation for the .de zone on our nameservers:
rec_control add-nta de.This means: If you use our DNS servers, you can still reach .de domains.
Setting a so-called Negative Trust Anchor (NTA) is a standardised procedure described in RFC 7646. An NTA disables DNSSEC validation specifically for a single zone – in this case .de – without affecting validation for any other domains.
According to RFC 7646, NTAs are designed for exactly this kind of situation: when a DNSSEC failure is caused not by an attack, but by a misconfiguration or outage on the zone operator’s side. The alternative – users switching to non-validating DNS resolvers – would be far more harmful to security, as it would disable all DNSSEC validation entirely.
The NTA will be removed as soon as the disruption is resolved and the .de zone validates correctly again.
You can find setup instructions for our DNS servers here:
More information about our DNS service is available on our DNS Privacy page.
5 May 2026, 23:28 CEST – Frankfurt am Main – DENIC eG is currently experiencing a disruption in its DNS service for .de domains. As a result, all DNSSEC-signed .de domains are currently affected in their reachability.
The root cause of the disruption has not yet been fully identified. DENIC’s technical teams are working intensively on analysis and on restoring stable operations as quickly as possible.
Based on current information, users and operators of .de domains may experience impairments in domain resolution. Further updates will be provided as soon as reliable findings on the cause and recovery are available.
DENIC asks all affected parties for their understanding.
You can check the current status of the outage at DENIC and sign up for automatic notifications:
Once the issue on DENIC’s side is resolved, we will re-enable DNSSEC validation.
Depuis environ 22h00 (CEST) le 05 mai 2026, une panne majeure affecte DENIC, le registraire de domaines allemand. En conséquence, tous les domaines .de signés DNSSEC sont actuellement affectés dans leur accessibilité.
Tous les sites web et services signés DNSSEC sous le domaine de premier niveau .de sont affectés. L’accès n’est actuellement possible que si la résolution du domaine est encore en cache dans votre routeur ou chez votre fournisseur d’accès. Dès que ce cache expire, des erreurs de connexion apparaîtront dans votre navigateur.
.de signés DNSSEC peuvent être partiellement ou totalement inaccessibles pour les visiteurs.de peuvent également être affectés si leurs serveurs de noms fonctionnent sous .de. Exemple : le domaine example.com utilise ns1.hoster.de et ns2.hoster.de comme serveurs de noms – si hoster.de est signé DNSSEC et ne peut pas être résolu, example.com sera également inaccessiblePour vous permettre de continuer à naviguer malgré la panne, nous avons temporairement désactivé la validation DNSSEC pour la zone .de sur nos serveurs DNS :
rec_control add-nta de.Cela signifie que si vous utilisez nos serveurs DNS, vous pouvez toujours accéder aux domaines .de.
La mise en place d’un Negative Trust Anchor (NTA) est une procédure standardisée décrite dans la RFC 7646. Un NTA désactive la validation DNSSEC de manière ciblée pour une zone spécifique – dans ce cas .de – sans affecter la validation pour les autres domaines.
Selon la RFC 7646, les NTA sont conçus exactement pour ce type de situation : lorsqu’une défaillance DNSSEC n’est pas causée par une attaque, mais par une erreur de configuration ou une panne du côté de l’opérateur de la zone. L’alternative – que les utilisateurs basculent vers des résolveurs DNS non validants – serait bien plus dangereuse pour la sécurité, car elle désactiverait toute la validation DNSSEC.
Le NTA sera supprimé dès que la perturbation sera résolue et que la zone .de sera de nouveau validée correctement.
Vous trouverez les instructions de configuration de nos serveurs DNS ici :
Plus d’informations sur notre service DNS sont disponibles sur notre page DNS Privacy.
5 mai 2026, 23h28 CEST – Francfort-sur-le-Main – DENIC eG subit actuellement une perturbation de son service DNS pour les domaines .de. En conséquence, tous les domaines .de signés DNSSEC sont actuellement affectés dans leur accessibilité.
La cause exacte de la perturbation n’a pas encore été entièrement identifiée. Les équipes techniques de DENIC travaillent intensivement à l’analyse et au rétablissement du fonctionnement stable dans les plus brefs délais.
Selon les informations actuelles, les utilisateurs et opérateurs de domaines .de peuvent rencontrer des problèmes de résolution de domaine. De nouvelles mises à jour seront fournies dès que des résultats fiables sur la cause et le rétablissement seront disponibles.
DENIC demande la compréhension de toutes les parties concernées.
Vous pouvez consulter le statut actuel de la panne chez DENIC et vous inscrire aux notifications automatiques :
Dès que le problème sera résolu du côté de DENIC, nous réactiverons la validation DNSSEC.
Desde aproximadamente las 22:00 (CEST) del 05 de mayo de 2026, se produce una interrupción importante en DENIC, el registrador de dominios alemán. Como resultado, todos los dominios .de firmados con DNSSEC están actualmente afectados en su accesibilidad.
Todos los sitios web y servicios firmados con DNSSEC bajo el dominio de nivel superior .de están afectados. El acceso solo es posible actualmente si la resolución del dominio aún está almacenada en la caché DNS de tu router o proveedor. Una vez que esta caché expire, aparecerán errores de conexión en tu navegador.
.de firmados con DNSSEC pueden ser parcial o totalmente inaccesibles para los visitantes.de también pueden verse afectados si sus servidores de nombres funcionan bajo .de. Ejemplo: el dominio example.com usa ns1.hoster.de y ns2.hoster.de como servidores de nombres – si hoster.de está firmado con DNSSEC y no se puede resolver, example.com tampoco será accesiblePara permitiros seguir navegando a pesar de la interrupción, hemos desactivado temporalmente la validación DNSSEC para la zona .de en nuestros servidores de nombres:
rec_control add-nta de.Esto significa que si utilizáis nuestros servidores DNS, podéis seguir accediendo a los dominios .de.
Establecer un Negative Trust Anchor (NTA) es un procedimiento estandarizado descrito en RFC 7646. Un NTA desactiva la validación DNSSEC específicamente para una zona concreta – en este caso .de – sin afectar a la validación de otros dominios.
Según RFC 7646, los NTA están diseñados exactamente para este tipo de situación: cuando un fallo DNSSEC no es causado por un ataque, sino por un error de configuración o una caída del lado del operador de la zona. La alternativa – que los usuarios cambien a resolvedores DNS sin validación – sería mucho más perjudicial para la seguridad, ya que desactivaría toda la validación DNSSEC por completo.
El NTA será eliminado en cuanto la interrupción se resuelva y la zona .de se valide correctamente de nuevo.
Podéis encontrar las instrucciones de configuración de nuestros servidores DNS aquí:
Más información sobre nuestro servicio DNS está disponible en nuestra página de DNS Privacy.
5 de mayo de 2026, 23:28 CEST – Fráncfort del Meno – DENIC eG está experimentando actualmente una interrupción en su servicio DNS para dominios .de. Como resultado, todos los dominios .de firmados con DNSSEC están actualmente afectados en su accesibilidad.
La causa raíz de la interrupción aún no ha sido completamente identificada. Los equipos técnicos de DENIC están trabajando intensamente en el análisis y en restaurar las operaciones estables lo antes posible.
Según la información actual, los usuarios y operadores de dominios .de pueden experimentar problemas en la resolución de dominios. Se proporcionarán más actualizaciones tan pronto como se disponga de hallazgos fiables sobre la causa y la recuperación.
DENIC pide comprensión a todas las partes afectadas.
Podéis consultar el estado actual de la interrupción en DENIC e inscribiros para recibir notificaciones automáticas:
En cuanto el problema se resuelva por parte de DENIC, reactivaremos la validación DNSSEC.
Приблизно з 22:00 (CEST) 05 травня 2026 року відбувається масштабний збій у DENIC, німецькому реєстраторі доменів. Внаслідок цього всі домени .de з підписом DNSSEC наразі мають проблеми з доступністю.
Постраждали всі підписані DNSSEC веб-сайти та сервіси під доменом верхнього рівня .de. Доступ наразі можливий лише якщо розв’язання домену ще збережено в DNS-кеші вашого роутера або провайдера. Щойно цей кеш закінчиться, у браузері з’являться помилки з’єднання.
.de з підписом DNSSEC можуть бути частково або повністю недоступні для відвідувачів.de, також можуть бути зачеплені, якщо їхні сервери імен працюють під .de. Приклад: домен example.com використовує ns1.hoster.de та ns2.hoster.de як сервери імен – якщо hoster.de підписаний DNSSEC і не може бути розв’язаний, example.com також буде недоступнийЩоб забезпечити вам безперебійний доступ до інтернету попри збій, ми тимчасово вимкнули валідацію DNSSEC для зони .de на наших серверах імен:
rec_control add-nta de.Це означає: якщо ви використовуєте наші DNS-сервери, ви й надалі можете отримувати доступ до доменів .de.
Встановлення так званого Negative Trust Anchor (NTA) – це стандартизована процедура, описана в RFC 7646. NTA вимикає валідацію DNSSEC цілеспрямовано для конкретної зони – у цьому випадку .de – не впливаючи на валідацію інших доменів.
Згідно з RFC 7646, NTA призначені саме для таких ситуацій: коли збій DNSSEC спричинений не атакою, а помилкою конфігурації або збоєм на стороні оператора зони. Альтернатива – перехід користувачів на DNS-резолвери без валідації – була б значно небезпечнішою, оскільки це вимкнуло б всю валідацію DNSSEC повністю.
NTA буде видалено, щойно збій буде усунуто та зона .de знову буде коректно валідуватися.
Інструкції з налаштування наших DNS-серверів можна знайти тут:
Більше інформації про наш DNS-сервіс доступно на нашій сторінці DNS Privacy.
5 травня 2026, 23:28 CEST – Франкфурт-на-Майні – DENIC eG наразі зазнає збою у своєму DNS-сервісі для доменів .de. Внаслідок цього всі домени .de з підписом DNSSEC наразі мають проблеми з доступністю.
Основну причину збою ще не вдалося повністю встановити. Технічні команди DENIC інтенсивно працюють над аналізом та якнайшвидшим відновленням стабільної роботи.
За наявною інформацією, користувачі та оператори доменів .de можуть стикатися з порушеннями в розв’язанні доменів. Подальші оновлення будуть надані, щойно з’являться надійні дані про причину та відновлення.
DENIC просить усіх постраждалих про розуміння.
Ви можете перевірити поточний стан збою на сайті DENIC та підписатися на автоматичні сповіщення:
Щойно проблему з боку DENIC буде вирішено, ми знову увімкнемо валідацію DNSSEC.
Am Samstag 02. Mai 2026 von 9:30 bis 17:00 Uhr öffnet die Technische Hochschule Augsburg ihre Türen für eine Veranstaltung voller Vorträge und Informationsstände rund um Linux, Open-Source und kreative Anwendungen von Technik, Wissenschaft und Bildung.
Der Eintritt ist frei, also komm einfach vorbei!
Wir vom “Freifunk” sind ebenfalls mit am Start!
Interessierst Du Dich für die Aktivitäten des Vereins Freie Netze München e.V. und ihre Verbindung zu “Freifunk Augsburg” oder suchst Inspiration wie Du Dich selbst mehr in Projekten einbringen kannst?
Eine wunderbare Gelegenheit unseren Stand zu besuchen und sich persönlich kennen zu lernen.
Natürlich haben wir auch ein paar “Freifunkrouter” zum Anschauen und Anfassen dabei.
Keine Anmeldung erforderlich.
Technische Hochschule Augsburg,
Fakultät für Informatik, Friedbergerstr. 2
Mehr Infos hier.
Wir freuen uns auf euch!
Wir mussten leider Maßnahmen ergreifen, um das Einbetten von meet.ffmuc.net per Iframe einzuschränken. Der Grund: Immer wieder betten Dritte unseren Videokonferenz-Dienst in ihre eigenen Webseiten ein und entfernen dabei sämtliche Logos und Spendenlinks.
In den letzten Wochen ist uns aufgefallen, dass diverse Webseiten meet.ffmuc.net per <iframe> in ihre eigenen Seiten eingebunden haben. Dabei wurden systematisch:
Unser Jitsi-Dienst wird ehrenamtlich betrieben und durch Spenden finanziert. Wenn jemand unseren Service einbettet und dabei alle Hinweise auf uns entfernt, belastet das nicht nur unsere Server, sondern entzieht uns auch die Möglichkeit, auf Spenden aufmerksam zu machen, die den Betrieb erst ermöglichen.
Wir setzen jetzt HTTP-Header, die das Einbetten unserer Seiten in fremde Iframes unterbinden:
X-Frame-Options: Verhindert das Laden in Iframes auf fremden DomainsContent-Security-Policy mit frame-ancestors-Direktive: Erlaubt Embedding nur von unseren eigenen DomainsDas bedeutet: Unsere Dienste können weiterhin direkt aufgerufen und genutzt werden. Sie lassen sich nur nicht mehr ohne Weiteres in fremde Webseiten einbetten.
Wir sind ein offenes Community-Projekt und freuen uns über Verbreitung! Wenn ihr unsere Karte oder andere Dienste auf eurer Seite einbinden wollt, meldet euch einfach bei uns:
Wir bitten lediglich darum, dass unsere Logos und Spendenlinks sichtbar bleiben und ein Link auf unser Projekt vorhanden ist. Für befreundete Freifunk-Communities und gemeinnützige Projekte schalten wir das Embedding gerne frei.
Diese Maßnahme ist nicht nur eine Frage der Fairness, sondern auch der Sicherheit. Das Einbetten fremder Inhalte per Iframe kann für sogenanntes Clickjacking missbraucht werden. Die von uns gesetzten Header sind eine empfohlene Sicherheitsmaßnahme gemäß OWASP-Richtlinien.
We had to introduce measures to restrict the embedding of meet.ffmuc.net via iframes. The reason: third parties keep embedding our video conferencing service into their own websites, stripping all logos and donation links in the process.
Over the past weeks, we noticed that various websites were embedding meet.ffmuc.net via <iframe> tags on their own pages. In doing so, they systematically:
Our Jitsi service is run by volunteers and funded by donations. When someone embeds our service and removes all references to us, it not only puts load on our servers but also takes away our ability to raise awareness for the donations that make this service possible.
We now set HTTP headers that prevent our pages from being embedded in third-party iframes:
X-Frame-Options: Prevents loading in iframes on foreign domainsContent-Security-Policy with frame-ancestors directive: Only allows embedding from our own domainsThis means: Our services can still be accessed and used directly. They just can’t be embedded into third-party websites without permission.
We are an open community project and we welcome people sharing our work! If you want to embed our map or other services on your site, just get in touch:
We simply ask that our logos and donation links remain visible and that a link to our project is included. We’re happy to enable embedding for fellow Freifunk communities and non-profit projects.
This measure is not just a matter of fairness but also of security. Embedding third-party content via iframes can be exploited for so-called clickjacking attacks. The headers we set are a recommended security measure according to OWASP guidelines.
Nous avons dû introduire des mesures pour restreindre l’intégration de meet.ffmuc.net via des iframes. La raison : des tiers intègrent régulièrement notre service de visioconférence dans leurs propres sites web, en supprimant tous les logos et liens de don.
Au cours des dernières semaines, nous avons constaté que divers sites web intégraient meet.ffmuc.net via des balises <iframe> sur leurs propres pages. Ce faisant, ils ont systématiquement :
Notre service Jitsi est géré par des bénévoles et financé par des dons. Lorsque quelqu’un intègre notre service en supprimant toute référence à nous, cela sollicite non seulement nos serveurs, mais nous empêche aussi de sensibiliser aux dons qui rendent ce service possible.
Nous utilisons désormais des en-têtes HTTP qui empêchent l’intégration de nos pages dans des iframes tiers :
X-Frame-Options : empêche le chargement dans des iframes sur des domaines tiersContent-Security-Policy avec la directive frame-ancestors : n’autorise l’intégration que depuis nos propres domainesCela signifie : nos services restent accessibles et utilisables directement. Ils ne peuvent simplement plus être intégrés dans des sites tiers sans autorisation.
Nous sommes un projet communautaire ouvert et nous encourageons le partage ! Si vous souhaitez intégrer notre carte ou d’autres services sur votre site, contactez-nous :
Nous demandons simplement que nos logos et liens de don restent visibles et qu’un lien vers notre projet soit inclus. Nous activons volontiers l’intégration pour les communautés Freifunk amies et les projets à but non lucratif.
Hemos tenido que introducir medidas para restringir la integración de meet.ffmuc.net mediante iframes. El motivo: terceros integran repetidamente nuestro servicio de videoconferencia en sus propios sitios web, eliminando todos los logos y enlaces de donación.
En las últimas semanas, detectamos que diversos sitios web estaban integrando meet.ffmuc.net mediante etiquetas <iframe> en sus propias páginas. Al hacerlo, sistemáticamente:
Nuestro servicio Jitsi es operado por voluntarios y financiado mediante donaciones. Cuando alguien integra nuestro servicio y elimina todas las referencias a nosotros, esto no solo genera carga en nuestros servidores, sino que también nos quita la posibilidad de dar a conocer las donaciones que hacen posible este servicio.
Ahora establecemos cabeceras HTTP que impiden que nuestras páginas se integren en iframes de terceros:
X-Frame-Options: impide la carga en iframes de dominios externosContent-Security-Policy con la directiva frame-ancestors: solo permite la integración desde nuestros propios dominiosEsto significa: nuestros servicios siguen siendo accesibles y utilizables directamente. Simplemente ya no pueden integrarse en sitios web de terceros sin permiso.
Somos un proyecto comunitario abierto y nos alegra que la gente comparta nuestro trabajo. Si quieres integrar nuestro mapa u otros servicios en tu sitio, simplemente contáctanos:
Solo pedimos que nuestros logos y enlaces de donación permanezcan visibles y que se incluya un enlace a nuestro proyecto. Activamos la integración con gusto para comunidades Freifunk amigas y proyectos sin ánimo de lucro.
Нам довелося запровадити заходи для обмеження вбудовування meet.ffmuc.net через iframe. Причина: треті сторони постійно вбудовують наш сервіс відеоконференцій у свої веб-сайти, при цьому видаляючи всі логотипи та посилання на пожертви.
Протягом останніх тижнів ми помітили, що різні веб-сайти вбудовували meet.ffmuc.net через теги <iframe> на своїх сторінках. При цьому систематично:
Тепер ми встановлюємо HTTP-заголовки, які запобігають вбудовуванню наших сторінок у сторонні iframe:
X-Frame-Options: запобігає завантаженню в iframe на сторонніх доменахContent-Security-Policy з директивою frame-ancestors: дозволяє вбудовування лише з наших власних доменівЦе означає: наші сервіси можна й надалі відкривати та використовувати безпосередньо. Їх просто не можна вбудовувати на сторонні веб-сайти без дозволу.
Ми - відкритий громадський проєкт і вітаємо поширення нашої роботи! Якщо ви хочете вбудувати нашу карту чи інші сервіси на вашому сайті, просто зв’яжіться з нами:
Ми лише просимо, щоб наші логотипи та посилання на пожертви залишалися видимими і було включено посилання на наш проєкт. Для дружніх спільнот Freifunk та некомерційних проєктів ми з радістю відкриємо вбудовування.
Wir freuen uns, dass unser DNS-Resolver ab sofort nativ in CachyOS als DNS-Option verfügbar ist! CachyOS ist eine auf Performance optimierte Arch-Linux-Distribution, die besonders bei Linux-Enthusiasten beliebt ist.
Im CachyOS Hello-Tool kann Freifunk München DNS jetzt direkt als DNS-Provider ausgewählt werden — ohne manuelle Konfiguration. Die Integration wurde mit dem CachyOS March 2026 Release ausgeliefert.
Alle CachyOS-Nutzer können unseren datenschutzfreundlichen DNS-Resolver mit wenigen Klicks über das Welcome-Tool aktivieren — als Plain DNS (Port 53) mit unseren Anycast-IPs:
5.1.66.255, 185.150.99.2552001:678:e68:f000::, 2001:678:ed0:f000::Unser DNS-Resolver loggt keine personenbezogenen Daten und blockiert keine Inhalte. Mehr dazu in unserer DNS-Privacy-Erklärung.
Nicht CachyOS? Kein Problem. Unter dns-setup.ffmuc.net findet ihr Anleitungen für alle gängigen Plattformen:
Neben Plain DNS unterstützen wir auch DNS over HTTPS (DoH), DNS over TLS (DoT) und DNS over QUIC (DoQ).
Der Freifunk München DNS-Resolver steht allen offen — nicht nur Freifunk-Nutzern. Er bietet:
We’re happy to announce that our DNS resolver is now natively available as a DNS option in CachyOS! CachyOS is a performance-optimized Arch Linux distribution that’s especially popular among Linux enthusiasts.
In the CachyOS Hello app, Freifunk München DNS can now be selected directly as a DNS provider — no manual configuration needed. The integration shipped with the CachyOS March 2026 Release.
All CachyOS users can now activate our privacy-friendly DNS resolver with just a few clicks via the Welcome tool — as plain DNS (port 53) using our anycast IPs:
5.1.66.255, 185.150.99.2552001:678:e68:f000::, 2001:678:ed0:f000::Our DNS resolver does not log any personal data and does not block any content. More details in our DNS Privacy Policy.
Not on CachyOS? No problem. Visit dns-setup.ffmuc.net for setup guides covering all major platforms:
Besides plain DNS we also support DNS over HTTPS (DoH), DNS over TLS (DoT), and DNS over QUIC (DoQ).
The Freifunk München DNS resolver is open to everyone — not just Freifunk users. It offers:
Nous sommes heureux d’annoncer que notre résolveur DNS est désormais disponible nativement comme option DNS dans CachyOS ! CachyOS est une distribution Arch Linux optimisée pour les performances, particulièrement populaire parmi les passionnés de Linux.
Dans l’application CachyOS Hello, Freifunk München DNS peut désormais être sélectionné directement comme fournisseur DNS — sans aucune configuration manuelle. L’intégration a été livrée avec la version de mars 2026 de CachyOS.
Tous les utilisateurs de CachyOS peuvent désormais activer notre résolveur DNS respectueux de la vie privée en quelques clics via l’outil Welcome — en DNS classique (port 53) avec nos IPs anycast :
5.1.66.255, 185.150.99.2552001:678:e68:f000::, 2001:678:ed0:f000::Notre résolveur DNS n’enregistre aucune donnée personnelle et ne bloque aucun contenu. Plus de détails dans notre politique de confidentialité DNS.
Pas sous CachyOS ? Pas de problème. Rendez-vous sur dns-setup.ffmuc.net pour des guides couvrant toutes les plateformes :
En plus du DNS classique, nous supportons également DNS over HTTPS (DoH), DNS over TLS (DoT) et DNS over QUIC (DoQ).
Le résolveur DNS Freifunk München est ouvert à tous — pas seulement aux utilisateurs Freifunk. Il offre :
Nos alegra anunciar que nuestro resolver DNS está ahora disponible nativamente como opción DNS en CachyOS. CachyOS es una distribución Arch Linux optimizada para rendimiento, especialmente popular entre entusiastas de Linux.
En la aplicación CachyOS Hello, Freifunk München DNS ahora se puede seleccionar directamente como proveedor DNS — sin configuración manual. La integración se incluyó en el lanzamiento de marzo 2026 de CachyOS.
Todos los usuarios de CachyOS pueden activar nuestro resolver DNS respetuoso con la privacidad con solo unos clics a través de la herramienta Welcome — como DNS plano (puerto 53) con nuestras IPs anycast:
5.1.66.255, 185.150.99.2552001:678:e68:f000::, 2001:678:ed0:f000::Nuestro resolver DNS no registra datos personales y no bloquea ningún contenido. Más detalles en nuestra política de privacidad DNS.
¿No estás en CachyOS? No hay problema. Visita dns-setup.ffmuc.net para guías que cubren todas las plataformas:
Además de DNS plano, también soportamos DNS over HTTPS (DoH), DNS over TLS (DoT) y DNS over QUIC (DoQ).
El resolver DNS de Freifunk München está abierto a todos — no solo a usuarios de Freifunk. Ofrece:
Ми раді повідомити, що наш DNS-резолвер тепер нативно доступний як опція DNS у CachyOS! CachyOS — це оптимізований для продуктивності дистрибутив Arch Linux, особливо популярний серед ентузіастів Linux.
У додатку CachyOS Hello Freifunk München DNS тепер можна вибрати безпосередньо як DNS-провайдер — без ручної конфігурації. Інтеграція була включена у березневий реліз CachyOS 2026.
Усі користувачі CachyOS тепер можуть активувати наш приватний DNS-резолвер лише кількома кліками через Welcome-інструмент — як звичайний DNS (порт 53) з нашими anycast-IP:
5.1.66.255, 185.150.99.2552001:678:e68:f000::, 2001:678:ed0:f000::Наш DNS-резолвер не зберігає персональні дані і не блокує жодний контент. Більше деталей у нашій політиці конфіденційності DNS.
Не на CachyOS? Не проблема. Відвідайте dns-setup.ffmuc.net для інструкцій для всіх основних платформ:
Окрім звичайного DNS ми також підтримуємо DNS over HTTPS (DoH), DNS over TLS (DoT) та DNS over QUIC (DoQ).
DNS-резолвер Freifunk München відкритий для всіх — не тільки для користувачів Freifunk. Він пропонує:
Wir haben einen kleinen Service gebaut, der versucht alle Freifunk-Communities über die Freifunk API zu finden und auf einer gemeinsamen Karte darzustellen, inklusive Grafana Live-Daten, wo möglich.
Viel Spaß beim Spielen: federated-map.ffmuc.net
Technisch ist das Ganze ein einzelnes Go-Binary ohne externe Abhängigkeiten, das alle Web-Assets einbettet und alles aus einem Prozess heraus ausliefert.
Im Moment gibt es noch ein paar Bugs, aber wir basteln dran. Wenn ihr Fehler findet oder Ideen habt: GitHub Issues oder kommt zu unserem nächsten Treffen.
Die bisherige Knotenkarte bleibt unter map.ffmuc.net erreichbar.
Die Federated Map bezieht alle Daten über die Freifunk API. Damit eure Community korrekt auf der Karte erscheint, prüft bitte eure API-Datei:
meshviewer.json oder nodelist.json URL noch korrekt und erreichbar?Eine gepflegte API-Datei hilft nicht nur dieser Karte, sondern dem gesamten Freifunk-Ökosystem. Schaut mal rein und räumt auf!
Der gesamte Quellcode ist Open Source (AGPL-3.0): github.com/freifunkMUC/freifunk-map-modern
We built a small service that tries to discover all Freifunk communities via the Freifunk API and display them on a single shared map, including live Grafana data where available.
Have fun exploring: federated-map.ffmuc.net
Technically it’s a single Go binary with zero external dependencies that embeds all web assets and serves everything from one process.
There are still a few bugs, but we’re working on it. If you find issues or have ideas: GitHub Issues or join our next meetup.
The existing node map remains available at map.ffmuc.net.
The Federated Map pulls all its data from the Freifunk API. To make sure your community shows up correctly on the map, please check your API file:
meshviewer.json or nodelist.json URL still correct and reachable?A well-maintained API file doesn’t just help this map. It benefits the entire Freifunk ecosystem. Take a moment to check and clean up!
The full source code is open source (AGPL-3.0): github.com/freifunkMUC/freifunk-map-modern
Nous avons créé un petit service qui tente de découvrir toutes les communautés Freifunk via l’API Freifunk et de les afficher sur une carte commune, y compris les données Grafana en temps réel lorsque c’est possible.
Amusez-vous bien : federated-map.ffmuc.net
Techniquement, c’est un seul binaire Go sans dépendances externes qui embarque tous les assets web et sert tout depuis un seul processus.
Il y a encore quelques bugs, mais nous y travaillons. Si vous trouvez des problèmes ou avez des idées : GitHub Issues ou rejoignez-nous lors de notre prochaine réunion.
La carte des nœuds existante reste accessible sur map.ffmuc.net.
La Federated Map récupère toutes ses données via l’API Freifunk. Pour que votre communauté apparaisse correctement sur la carte, vérifiez votre fichier API :
meshviewer.json ou nodelist.json est-elle encore correcte et accessible ?Un fichier API bien maintenu ne profite pas qu’à cette carte. Il bénéficie à tout l’écosystème Freifunk. Vérifiez et nettoyez !
Le code source complet est open source (AGPL-3.0) : github.com/freifunkMUC/freifunk-map-modern
Hemos creado un pequeño servicio que intenta descubrir todas las comunidades Freifunk a través de la API Freifunk y mostrarlas en un mapa compartido, incluyendo datos en vivo de Grafana cuando estén disponibles.
Diviértete explorando: federated-map.ffmuc.net
Técnicamente es un único binario Go sin dependencias externas que integra todos los assets web y sirve todo desde un solo proceso.
Aún hay algunos bugs, pero estamos trabajando en ello. Si encuentras problemas o tienes ideas: GitHub Issues o únete a nuestro próximo encuentro.
El mapa de nodos existente sigue disponible en map.ffmuc.net.
El Federated Map obtiene todos sus datos de la API Freifunk. Para que vuestra comunidad aparezca correctamente en el mapa, revisad vuestro archivo API:
meshviewer.json o nodelist.json sigue siendo correcta y accesible?Un archivo API bien mantenido no solo ayuda a este mapa. Beneficia a todo el ecosistema Freifunk. ¡Revisadlo y actualizadlo!
El código fuente completo es open source (AGPL-3.0): github.com/freifunkMUC/freifunk-map-modern
Ми створили невеликий сервіс, який намагається знайти всі спільноти Freifunk через Freifunk API і показати їх на одній спільній карті, включаючи живі дані Grafana, де це можливо.
Розважайтеся: federated-map.ffmuc.net
Технічно це один Go-бінарник без зовнішніх залежностей, який вбудовує всі веб-ресурси і обслуговує все з одного процесу.
На даний момент є ще кілька багів, але ми працюємо над цим. Якщо знайшли проблеми або маєте ідеї: GitHub Issues або приходьте на нашу наступну зустріч.
Існуюча карта вузлів залишається доступною за адресою map.ffmuc.net.
Federated Map отримує всі дані через Freifunk API. Щоб ваша спільнота коректно відображалася на карті, перевірте ваш API-файл:
meshviewer.json або nodelist.json ще коректний і доступний?Добре підтримуваний API-файл допомагає не лише цій карті. Він корисний для всієї екосистеми Freifunk. Перевірте та оновіть!
Весь вихідний код є відкритим (AGPL-3.0): github.com/freifunkMUC/freifunk-map-modern
Jedes Mal, wenn ihr eine Webseite aufruft, fragt euer Gerät einen DNS-Server, welche IP-Adresse sich hinter dem Namen verbirgt. Standardmäßig läuft das über den DNS-Server eines kommerziellen Providers, oft unverschlüsselt und nicht unbedingt in Europa.
Mit unserer neuen Anleitung könnt ihr in wenigen Minuten auf unsere DNS-Server umstellen, die komplett in der EU stehen und DSGVO-konform betrieben werden. Egal ob Smartphone, Laptop oder Router, und egal ob ihr euch mit Technik auskennt oder nicht.
Wir unterstützen verschlüsselte Protokolle wie DoH, DoT und DoQ, aber auch klassisches unverschlüsseltes DNS für alle, die das brauchen. Was wir mit euren DNS-Daten machen (und was nicht), steht in unserer DNS Privacy Policy.
Unser DNS-Service ist übrigens auch bei European Alternatives gelistet. Mehr dazu in unserem Blogpost.
Ihr wollt schnell wissen, mit welcher IP-Adresse ihr gerade unterwegs seid? Geht einfach auf:
Im Browser: ip.ffmuc.net
Im Terminal:
| Was | Befehl |
|---|---|
| IPv4 | curl -4 ip.ffmuc.net |
| IPv6 | curl -6 ip.ffmuc.net |
| JSON | curl ip.ffmuc.net/json |
Einfach, schnell und ohne Tracking.
Bei Fragen oder Anmerkungen könnt ihr euch jederzeit bei uns im Chat melden: https://chat.ffmuc.net
Every time you open a website, your device asks a DNS server which IP address belongs to that domain name. By default, this goes through a commercial provider’s DNS server, often unencrypted and not necessarily located in Europe.
With our new guide, you can switch to our DNS servers in just a few minutes. They are fully hosted and operated in the EU, GDPR-compliant, and the guide works whether you’re on a smartphone, laptop, or router. No technical knowledge needed.
We support encrypted protocols like DoH, DoT, and DoQ, but also classic unencrypted DNS for anyone who needs it. What we do (and don’t do) with your DNS data is described in our DNS Privacy Policy.
Our DNS service is also listed on European Alternatives. More details in our blog post.
Want to quickly check which IP address you’re using? Just open:
In the browser: ip.ffmuc.net
In the terminal:
| What | Command |
|---|---|
| IPv4 | curl -4 ip.ffmuc.net |
| IPv6 | curl -6 ip.ffmuc.net |
| JSON | curl ip.ffmuc.net/json |
Simple, fast, and tracking-free.
If you have questions or comments, feel free to reach out to us in our chat: https://chat.ffmuc.net
Chaque fois que vous ouvrez un site web, votre appareil demande à un serveur DNS quelle adresse IP se cache derrière ce nom de domaine. Par défaut, cette requête passe par le serveur DNS d’un fournisseur commercial, souvent non chiffré et pas forcément situé en Europe.
Avec notre nouveau guide, vous pouvez passer à nos serveurs DNS en quelques minutes. Ils sont entièrement hébergés et exploités dans l’UE, conformes au RGPD, et le guide fonctionne que vous soyez sur smartphone, ordinateur portable ou routeur. Aucune connaissance technique requise.
Nous supportons les protocoles chiffrés comme DoH, DoT et DoQ, mais aussi le DNS classique non chiffré pour ceux qui en ont besoin. Ce que nous faisons (et ne faisons pas) avec vos données DNS est décrit dans notre DNS Privacy Policy.
Notre service DNS est aussi référencé sur European Alternatives. Plus de détails dans notre article de blog.
Vous voulez savoir quelle adresse IP vous utilisez en ce moment ? Ouvrez simplement :
Dans le navigateur : ip.ffmuc.net
Dans le terminal :
| Quoi | Commande |
|---|---|
| IPv4 | curl -4 ip.ffmuc.net |
| IPv6 | curl -6 ip.ffmuc.net |
| JSON | curl ip.ffmuc.net/json |
Simple, rapide et sans tracking.
Pour toute question ou remarque, n’hésitez pas à nous contacter dans notre chat : https://chat.ffmuc.net
Cada vez que abres una página web, tu dispositivo le pregunta a un servidor DNS qué dirección IP corresponde a ese nombre de dominio. Por defecto, esto pasa por el servidor DNS de un proveedor comercial, a menudo sin cifrar y no necesariamente ubicado en Europa.
Con nuestra nueva guía, puedes cambiar a nuestros servidores DNS en pocos minutos. Están completamente alojados y operados en la UE, cumplen con el RGPD, y la guía funciona tanto en smartphone como en portátil o router. No necesitas conocimientos técnicos.
Soportamos protocolos cifrados como DoH, DoT y DoQ, pero también DNS clásico sin cifrar para quien lo necesite. Lo que hacemos (y no hacemos) con tus datos DNS está descrito en nuestra DNS Privacy Policy.
Nuestro servicio DNS también aparece en European Alternatives. Más detalles en nuestra publicación de blog.
¿Quieres saber qué dirección IP estás usando? Abre simplemente:
En el navegador: ip.ffmuc.net
En la terminal:
| Qué | Comando |
|---|---|
| IPv4 | curl -4 ip.ffmuc.net |
| IPv6 | curl -6 ip.ffmuc.net |
| JSON | curl ip.ffmuc.net/json |
Sencillo, rápido y sin rastreo.
Si tienes preguntas o comentarios, puedes contactarnos en nuestro chat en cualquier momento: https://chat.ffmuc.net
Кожного разу, коли ви відкриваєте вебсайт, ваш пристрій запитує DNS-сервер, яка IP-адреса стоїть за цим доменним ім’ям. За замовчуванням цей запит йде через DNS-сервер комерційного провайдера, часто без шифрування і не обов’язково в Європі.
З нашою новою інструкцією ви можете за кілька хвилин перейти на наші DNS-сервери. Вони повністю розміщені та працюють в ЄС, відповідають вимогам GDPR, а інструкція підходить і для смартфона, і для ноутбука, і для роутера. Технічні знання не потрібні.
Ми підтримуємо шифровані протоколи: DoH, DoT та DoQ, а також класичний нешифрований DNS для тих, кому це потрібно. Що ми робимо (і не робимо) з вашими DNS-даними, описано в нашій DNS Privacy Policy.
Наш DNS-сервіс також є на European Alternatives. Детальніше в нашому блозі.
Хочете дізнатися, яку IP-адресу ви зараз використовуєте? Просто відкрийте:
У браузері: ip.ffmuc.net
У терміналі:
| Що | Команда |
|---|---|
| IPv4 | curl -4 ip.ffmuc.net |
| IPv6 | curl -6 ip.ffmuc.net |
| JSON | curl ip.ffmuc.net/json |
Просто, швидко і без відстеження.
Якщо у вас виникнуть запитання або коментарі, ви можете в будь-який час зв’язатися з нами в нашому чаті: https://chat.ffmuc.net