Der betroffene Artikel war ausgerechnet der über Besucherstatistik ohne Cookie-Banner. Also genau der Artikel, in dem ich erkläre, warum hier kein Tracking-Skript läuft.

Mein erster Gedanke: Das darf doch nicht wahr sein. Ausgerechnet ein Artikel über die Erfassung von Besucherdaten, bei dem ich extrem darauf achte, datensparsam zu sein, wird geblockt.

Mein erster Verdacht

Der Artikel war der einzige mit „matomo“ in der Adresse. Viele Blocklisten haben Regeln gegen Matomo, weil Matomo meistens als Tracking-Skript im Browser läuft. Bei mir läuft es zwar nur auf dem Server und wertet Logdateien aus, aber das weiß eine Filterliste nicht. Das klang plausibel, und so habe ich es auch geantwortet.

Es war falsch. Aber dazu brauchte ich erst die Liste der aktiven Filter. Der Leser hatte diese sieben aktiv:

• AdGuard Base Filter
• AdGuard Tracking Protection Filter
• AdGuard URL Tracking Protection Filter
• Actually Legitimate URL Shortener Tool
• Peter Lowe’s Blocklist
• AdGuard Cookie Notices
• AdGuard German Filter

Suchen in 300.000 Zeilen

Die AdGuard-Listen liegen offen auf GitHub im Repo AdguardTeam/FiltersRegistry, auch in der Fassung für Safari. Zusammen sind das gut 300.000 Zeilen. Ich habe sie heruntergeladen und nach den Wörtern aus der Adresse durchsucht: matomo, log-import, besucherstatistik, cookie-banner.

Bei matomo kam nichts, was eine Seite sperrt. Die Treffer waren nur Regeln, die auf bestimmten fremden Seiten Cookie-Dialoge wegklicken. Bei cookie-banner dagegen stand in der Liste AdGuard Cookie Notices diese Zeile:

-cookie-banner-$domain=~killthecookiebanner.eu

Kurz übersetzt:

• -cookie-banner- ist das Muster. Es hat keinen Anker am Anfang oder Ende, passt also auf jede Adresse, in der diese Zeichenfolge irgendwo vorkommt.
• $domain=~killthecookiebanner.eu heißt: überall, außer auf dieser einen Domain. Die Tilde ist ein „nicht“.

Gedacht ist die Regel für Dateien wie /js/site-cookie-banner-v2.js. Mein Slug, also der Teil der Adresse, der den Artikel benennt, sah aber so aus:

/posts/besucherstatistik-ohne-cookie-banner-matomo-log-import/

Da steht es: -ohne-cookie-banner-matomo. Bindestrich, cookie, Bindestrich, banner, Bindestrich. Die Regel hat keine Einschränkung auf Skripte oder Bilder, und wBlock hat damit in Safari gleich die ganze Seite gesperrt. Kein anderer Artikel hat diese Zeichenfolge in der Adresse, deshalb ging alles andere.

In Safari nachgestellt habe ich das nicht. Ob andere Werbeblocker mit derselben Liste auch das ganze Dokument sperren oder nur Dateien, habe ich ebenfalls nicht geprüft.

Die Ironie gefällt mir trotzdem: Ein Filter gegen Cookie-Banner sperrt einen Artikel darüber, wie man ohne Cookie-Banner auskommt.

Die Lösung: neue Adresse

Der Inhalt war nie das Problem, nur die Adresse. Filterlisten wie diese sehen den Text eines Artikels gar nicht, sie prüfen URLs. Also bekam der Artikel einen neuen Slug ohne die verdächtige Zeichenfolge. Im Front Matter sieht das so aus:

slug: "besucherstatistik-matomo-log-import"
aliases: ["/posts/besucherstatistik-ohne-cookie-banner-matomo-log-import/"]

Mit aliases legt Hugo unter der alten Adresse eine kleine Seite an, die per Meta-Refresh auf die neue weiterleitet. Die Seite enthält kein JavaScript, an der Content-Security-Policy ändert sich also nichts. Links, die schon im Umlauf sind, funktionieren damit weiter.

Mit einer Einschränkung: Wer die Filterliste aktiv hat, bleibt auf der alten Adresse hängen. Die Weiterleitungsseite liegt ja genau dort, wo die Regel greift. Diesen Lesern hilft nur der neue Link.

Drei andere Artikel haben auf den Matomo-Artikel verlinkt. Die zeigen jetzt direkt auf die neue Adresse statt über die Weiterleitung.

Eine Sorge hatte ich noch: Meine Pipeline kündigt neue Artikel selbst auf Mastodon an, und sie merkt sich das über die Adresse. Für sie war der Matomo-Artikel unter der neuen Adresse also ein „neuer“ Artikel. Getootet hat sie trotzdem nicht, weil sie nur Artikel ankündigt, die höchstens drei Tage alt sind. Da hat mich eine Schutzregel vor einem doppelten Toot bewahrt, an die ich bei diesem Problem gar nicht gedacht hatte.

Kurz nach der Umstellung kam die Rückmeldung vom Leser: Die Seite lässt sich jetzt „ohne Murren“ öffnen.

Ein grober Check für neue Slugs

Damit mir das nicht noch einmal passiert, habe ich ein kleines Skript, das eine Adresse gegen die Listen prüft. Es ist kein Nachbau eines Werbeblockers. Es kennt nur einfache URL-Regeln, ignoriert Ausnahmen und die meisten Optionen. Für die Frage „Steht in meinem Slug etwas, worauf eine Liste anspringt?“ reicht es.

#!/usr/bin/env python3
"""Grober Check: Welche einfache Filterregel passt auf eine URL?

Kein vollständiger Adblocker-Nachbau. Er kennt nur einfache URL-Regeln,
ignoriert Ausnahmen (@@) und die meisten Optionen.
"""
import re
import sys
import urllib.request

BASE = "https://raw.githubusercontent.com/AdguardTeam/FiltersRegistry/master/platforms/extension/safari/filters/"
LISTS = {
    "AdGuard Base": "2.txt",
    "AdGuard Tracking Protection": "3.txt",
    "AdGuard Cookie Notices": "18.txt",
    "AdGuard German": "6.txt",
    "Peter Lowe's Blocklist": "204.txt",
}
SKIP_OPTIONS = ("third-party", "script", "image", "stylesheet", "xmlhttprequest",
                "font", "media", "subdocument", "permissions", "removeparam")


def to_regex(pattern):
    if pattern.startswith("||"):
        rx, pattern = r"^[a-z]+://([^/]*\.)?", pattern[2:]
    elif pattern.startswith("|"):
        rx, pattern = "^", pattern[1:]
    else:
        rx = ""
    for c in pattern:
        if c == "*":
            rx += ".*"
        elif c == "^":
            rx += r"([^\w.%-]|$)"
        else:
            rx += re.escape(c)
    return rx


def check(url, name, text):
    for line in text.splitlines():
        line = line.strip()
        # Kommentare, Ausnahmen, Regex-Regeln und kosmetische Regeln überspringen
        if not line or line[0] in "![@/" or "#" in line:
            continue
        pattern, _, options = line.partition("$")
        if any(o.lstrip("~").startswith(SKIP_OPTIONS) for o in options.split(",") if o):
            continue
        if "domain=" in options and not re.search(r"domain=~", options):
            continue  # Regel gilt nur für bestimmte fremde Domains
        if len(pattern) >= 4 and re.search(to_regex(pattern), url, re.I):
            print(f"{name}: {line}")


for url in sys.argv[1:]:
    print(f"== {url}")
    for name, file in LISTS.items():
        with urllib.request.urlopen(BASE + file) as r:
            check(url, name, r.read().decode("utf-8", "ignore"))

Aufgerufen mit der alten und der neuen Adresse:

$ python3 slug-check.py \
    https://example.com/posts/besucherstatistik-ohne-cookie-banner-matomo-log-import/ \
    https://example.com/posts/besucherstatistik-matomo-log-import/
== https://example.com/posts/besucherstatistik-ohne-cookie-banner-matomo-log-import/
AdGuard Cookie Notices: -cookie-banner-$domain=~killthecookiebanner.eu
== https://example.com/posts/besucherstatistik-matomo-log-import/

Die alte Adresse trifft genau eine Regel, die neue keine. Die Listen ändern sich ständig, das Ergebnis gilt also nur für den Tag, an dem man prüft. Bei mir war das der 4. November 2026.

Was ich daraus mitnehme

Der erste Verdacht war plausibel und trotzdem falsch. „matomo in der Adresse“ klang so logisch, dass ich es fast nicht geprüft hätte. Erst die Liste der aktiven Filter und ein stumpfes Durchsuchen haben die echte Ursache gezeigt.

Auch Adressen müssen durch Filter. Ich achte bei Adressen auf Lesbarkeit und Suchbegriffe. Dass sie auch durch Filterlisten müssen, die nur Zeichenketten vergleichen, hatte ich nicht auf dem Schirm. Wörter wie cookie-banner, tracking oder ads mit Bindestrichen drumherum sind in einer Adresse riskant.

Meldungen von Lesern sind Gold wert. Ohne die Nachricht hätte ich das nie bemerkt. In meinen Logs taucht ein gesperrter Abruf gar nicht auf, weil der Browser die Anfrage nie abschickt. Danke an den Leser, der sich die Mühe gemacht hat.

Wie es weitergeht

Bei AdGuard melde ich das nicht. Die Regel ist breit, aber ich habe meine Seite umgebaut und achte in Zukunft selbst darauf, was in meinen Adressen steht.

Dafür überlege ich, den Slug-Check als Schritt in die Pipeline zu hängen, so wie die Prüfung der CSP-Hashes. Dann würde mir ein neuer Artikel mit verdächtiger Adresse schon vor der Veröffentlichung auffallen und nicht erst, wenn jemand auf Mastodon nachfragt.

Worum geht’s?

DNS ist das Telefonbuch des Internets: Ein Gerät fragt „Welche IP hat example.com?“ und bekommt eine Adresse zurück. Wer diese Fragen beantwortet, sieht ziemlich genau, was im Haus los ist – und kann entscheiden, welche Antworten es überhaupt gibt.

Bisher hat das bei mir der alte Router erledigt. Ein Pi-hole-Container lief früher auch mal, ist aber seit September abgeschaltet. Mit dem Umstieg auf eine FortiGate als Firewall wollte ich DNS sauber neu aufziehen. Meine Wunschliste:

• Eigene Namen fürs Homelab, damit ich Dienste unter dienst.home.example.com erreiche statt unter einer IP.
• Werbung und Tracker filtern, für alle Geräte im Haus, ohne dass ich auf jedem etwas installieren muss.
• Verschlüsselt nach außen, damit mein Provider nicht mitlesen kann, welche Namen ich auflöse.
• Ausfallsicher: Wenn ein DNS-Server ausfällt, geht im Haus gefühlt das Internet aus. Also zwei.
• Keine Schlupflöcher: Geräte, die sich ihren eigenen DNS-Server aussuchen, sollen trotzdem bei mir landen.

Voraussetzungen

• Proxmox VE als Hypervisor
• Technitium DNS Server 15.6.1 (eingerichtet mit 15.6), in zwei LXC-Containern mit Debian 12, je 1 vCPU und 512 MB RAM
• FortiGate als Firewall mit mehreren VLANs (getrennten Netzen) für Server, Clients, IoT-Geräte, Gäste und so weiter
• Quad9 als Upstream-Resolver per DNS-over-TLS
• Nginx Proxy Manager als Reverse Proxy für die internen Dienste

Warum Technitium und nicht Pi-hole oder AdGuard Home? Technitium ist ein vollwertiger DNS-Server: Er kann echte Zonen verwalten, Zonentransfers, DNS-over-TLS nach außen, Filterlisten – alles in einem. Bei Pi-hole und AdGuard Home fehlten mir genau diese Einstellmöglichkeiten. Und der Abgleich zwischen zwei Servern war bei beiden nicht optimal, das läuft dort meist über zusätzliche Werkzeuge.

Der Aufbau

             Clients, IoT, Gäste, Server …
                        │  DNS (Port 53)
          ┌─────────────┴─────────────┐
          ▼                           ▼
   dns-01 (Primary)  ── Zonentransfer ──▶  dns-02 (Secondary)
          │                           │
          └──────── DNS-over-TLS ─────┘
                        ▼
                      Quad9

Beide Server laufen als LXC-Container auf Proxmox, mit fester IP im Server-Netz (im Beispiel 10.0.10.53 und 10.0.10.54), und starten beim Booten des Hosts als Erste. Der DHCP-Server der FortiGate verteilt in allen Netzen beide Adressen als DNS-Server. Fällt einer aus, fragen die Geräte einfach den anderen.

Die interne Zone

Auf dns-01 liegt die Zone home.example.com als Primary, also als Original. Der wichtigste Eintrag ist ein Wildcard:

*.home.example.com.   300   IN   A   10.0.10.80

Jeder Name unter home.example.com zeigt damit auf den Reverse Proxy, der die Anfrage an den richtigen Dienst weiterreicht. Für einen neuen Dienst muss ich nur im Proxy etwas eintragen, nicht im DNS. Ein paar Namen, die nicht über den Proxy laufen, stehen zusätzlich als eigene A-Einträge drin.

dns-02 hält dieselbe Zone als Secondary: Er holt sie sich per Zonentransfer von dns-01. Damit Änderungen nicht erst beim nächsten regulären Abgleich ankommen, schickt dns-01 bei jeder Änderung ein Notify – eine kurze Nachricht „Hey, es gibt was Neues“, worauf dns-02 sofort nachlädt.

Filterlisten

Auf beiden Servern sind dieselben Listen eingetragen:

• HaGeZi Multi PRO: blockt Werbung, Tracker und bekannte Schaddomains. Die Liste wird alle 24 Stunden aktualisiert.
• HaGeZi „Encrypted DNS Bypass“: blockt bekannte Anbieter von DNS-over-HTTPS (DoH). Dazu gleich mehr.
• use-application-dns.net: Das ist eine „Kanarienvogel-Domain“. Firefox fragt sie ab, bevor er von sich aus DoH einschaltet. Bekommt er keine Antwort, lässt er es bleiben und nutzt das DNS des Netzes.

Verschlüsselt nach außen

Was Technitium nicht selbst weiß, fragt er bei Quad9 nach – und zwar per DNS-over-TLS (DoT). DoT ist normales DNS, nur in einem verschlüsselten Tunnel über Port 853. Mein Provider sieht dann nur noch, dass ich mit Quad9 rede, aber nicht mehr, worüber.

Wie viel da zusammenkommt, zeigt das Dashboard von dns-01: In 24 Stunden kamen rund 92 000 Anfragen von 40 Geräten an. Knapp 16 Prozent davon hat Technitium geblockt, also ungefähr jede sechste. Einen Teil der Anfragen beantwortet außerdem dns-02, die echte Gesamtzahl im Haus liegt also noch etwas höher.

Die Firewall passt auf

Eigene DNS-Server bringen wenig, wenn Geräte einfach woanders fragen. Und das tun erstaunlich viele.

Regel 1: DNS nur an die eigenen Server

Auf der FortiGate gibt es zwei Regeln, sinngemäß:

Nur dns-01 und dns-02 dürfen also selbst nach draußen. Alle anderen Geräte kommen mit DNS nur noch bis zu ihnen.

Regel 2: Wer stur Google fragt, landet trotzdem bei mir

Ein paar Geräte halten sich nicht an den DNS-Server, den ihnen DHCP mitgibt. Bei mir waren das vor allem die Echo-Lautsprecher und der Fire TV: Die fragen fest eingestellt bei Google (8.8.8.8 und 8.8.4.4). Mit Regel 1 würden sie einfach kein DNS mehr bekommen und nicht mehr funktionieren.

Die Lösung auf der FortiGate ist eine Umleitung (dort „VIP“ genannt): Anfragen an Googles DNS-Adressen werden auf meine beiden Server umgeschrieben. Die Geräte glauben, Google habe geantwortet – tatsächlich war es Technitium, inklusive Filterlisten.

Regel 3: Und was ist mit DNS-over-HTTPS?

DoH ist der Endgegner dieser Konstruktion: DNS-Anfragen, verpackt in normales HTTPS über Port 443. Für die Firewall sieht das aus wie jeder andere Webseitenaufruf, eine Portsperre greift nicht.

Hier kommen die zweite Filterliste und die Firefox-Kanarienvogel-Domain ins Spiel: Technitium löst die Namen bekannter DoH-Anbieter einfach nicht auf. Ein Gerät, das per DoH an mir vorbei will, findet seinen DoH-Server gar nicht erst – solange es ihn über Namen sucht. Eine Lücke bleibt: Wer seinen DoH-Server fest per IP kennt, kommt durch. Das nehme ich bewusst in Kauf.

Bonus: Ein zweiter Filter auf der Firewall

Die Regel, mit der die Geräte die DNS-Server erreichen dürfen, hat zusätzlich das DNS-Filterprofil der FortiGate. Die FortiGate schaut sich also jede Anfrage auf dem Weg zu Technitium an und blockt Kategorien wie Schadsoftware, Phishing und frisch registrierte Domains anhand der Herstellerdaten. Zwei unabhängige Filter, die sich ergänzen.

Die bewusste Ausnahme: die Firewall selbst

Die FortiGate fragt nicht meine Technitium-Server, sondern den DNS-Dienst ihres Herstellers, ebenfalls verschlüsselt per DoT. Das ist Absicht.

Die Firewall braucht DNS für ihre eigenen Updates, für Filterdaten, für Regeln mit Domainnamen und für die Prüfung, ob die Internetleitung läuft. Würde sie Technitium fragen, hinge sie an Proxmox. Startet der Proxmox-Host neu oder hat er ein Problem, stünde auch die Firewall ohne DNS da – genau in dem Moment, in dem ich sie am dringendsten brauche. Also bleibt sie unabhängig.

Die PTR-Flut von Home Assistant

Kurz nach dem Umstieg füllte sich mein Firewall-Log mit Hunderten geblockten Anfragen, immer zur gleichen Minute jeder Stunde. Absender: Home Assistant.

Dessen Geräteerkennung fragt regelmäßig für das komplette Netz nach, welcher Name zu welcher IP gehört. Diese Rückwärtsabfragen heißen PTR-Abfragen. Gerichtet waren sie an das Gateway, also an die FortiGate – und die hatte keinen DNS-Dienst, also hat sie jede einzelne verworfen. Rund 700 pro Stunde, alle im Log.

Die Lösung: Auf der Schnittstelle zum Server-Netz, und nur dort, beantwortet die FortiGate DNS-Anfragen jetzt selbst, indem sie sie weiterreicht:

config system dns-server
    edit "<SERVER-INTERFACE>"
        set mode forward-only
    next
end

Die PTR-Anfragen für private Adressen bekommen damit ein schnelles „gibt es nicht“ (NXDOMAIN), und das Log ist wieder ruhig. Getestet habe ich das mit:

dig -x 10.0.10.20 @10.0.10.254

Stolperfallen & Learnings

Beim Update braucht Technitium ein paar Sekunden. Ich habe beide Server mit dem offiziellen Installationsskript aktualisiert und direkt danach getestet: connection refused. Kurzer Schreck – dabei braucht Technitium nach dem Neustart einfach ein paar Sekunden, bis er wieder auf Port 53 lauscht. Seitdem gilt: nach dem Update kurz warten, und erst den Secondary aktualisieren, testen, dann den Primary. So beantwortet immer mindestens ein Server die Anfragen.

„Server-Reset“ heißt nicht „blockiert“. Im Firewall-Log sah ich bei den DoT-Verbindungen zu Quad9 lauter Einträge mit server-rst und dachte zuerst, die Firewall würde DoT blocken. Tatsächlich ist das nur der Grund, warum eine Verbindung beendet wurde: Quad9 hat sie nach getaner Arbeit zugemacht. Ein echter Block steht dort als deny. In den Einträgen standen außerdem übertragene Bytes in beide Richtungen – es lief also alles.

Manche Geräte sind DNS-Querulanten. Ohne die Umleitung für Googles DNS wären meine Echos nach Regel 1 einfach verstummt. Wer DNS sperrt, sollte vorher ins Log schauen, wer bisher wohin gefragt hat.

Ich habe ein Feature übersehen. Gebaut habe ich die Redundanz klassisch: Primary, Secondary, Zonentransfer. So habe ich das in meiner Laufbahn irgendwie immer gemacht, und auf den Cluster bin ich schlicht nicht gekommen. Erst beim Schreiben dieses Artikels ist mir aufgefallen, dass Technitium seit Version 14 einen eigenen Cluster kann – also schon in der Version, die ich installiert habe.

Der Unterschied ist nicht klein:

• Zonentransfer gleicht nur die Zonen ab. Alles andere – Filterlisten, Einstellungen, Benutzer – pflege ich auf beiden Servern doppelt. Dafür ist es Standard-DNS und funktioniert mit jeder DNS-Software.
• Ein Cluster verwaltet die Konfiguration zentral: Filterlisten, Einstellungen, Apps und Benutzer kommen vom primären Knoten, Zonen lassen sich über eine Katalog-Zone mitnehmen. Voraussetzung ist unter anderem HTTPS für die Weboberfläche, und den Cluster-Domainnamen kann man später nicht mehr ändern.

Für mein Setup wäre der Cluster vermutlich die bequemere Wahl gewesen – ausgerechnet der Abgleich zwischen zwei Servern war ja einer meiner Gründe für Technitium. Kaputt ist nichts – aber ich pflege seit Wochen Dinge doppelt, die ich nicht doppelt pflegen müsste. Ist blöd, lässt sich aber korrigieren. 😉

Fazit

DNS im Heimnetz selbst zu betreiben, ist kein Hexenwerk, aber erst mit der Firewall wird es rund: Die Technitium-Server liefern Namen, Filter und Verschlüsselung, die FortiGate sorgt dafür, dass niemand an ihnen vorbeikommt. Dazu eine bewusste Ausnahme für die Firewall selbst, damit sie nicht von Proxmox abhängt. Und eine Lektion zum Schluss: Was man seit Jahren so macht, ist nicht automatisch der beste Weg. Nachlesen, was die Software inzwischen kann, lohnt sich.

Was als Nächstes kommt

• Umbau auf den Technitium-Cluster – mit eigenem Artikel, wenn es so weit ist.
• AirPrint über VLAN-Grenzen per DNS: Mein Drucker steht in einem eigenen Netz, und die iPhones finden ihn trotzdem. Wie das mit ein paar DNS-Einträgen klappt, kommt in einem eigenen Artikel.