Privacy Statement RPS

Recursive Resolver Privacy Statement gemaess RFC 8932 (BCP 232).

Dieses Dokument beschreibt, wie dns.kernel-error.de mit DNS-Anfragen und den damit verbundenen Daten umgeht. Die Gliederung folgt der von RFC 8932 empfohlenen Struktur.

1. Datenerhebung und Speicherung

IP-Adressen

IP-Adressen werden als personenbezogene Daten behandelt. Es erfolgt kein Logging von DNS-Anfragen — weder die angefragten Domainnamen noch die IP-Adressen der Clients werden gespeichert. Query-Logging ist in der BIND-Konfiguration deaktiviert und wird nur temporaer zu Diagnosezwecken aktiviert (maximal wenige Minuten).

DoH-Anfragen

Der nginx-Reverse-Proxy fuer DoH (/dns-query) hat Access-Logging vollstaendig deaktiviert. Weder HTTP-Header noch Client-IPs werden protokolliert.

Landingpage

Die Landingpage (/, /en, /privacy, /privacy-en) hat Access-Logging deaktiviert. Es werden keine Zugriffe, IP-Adressen oder HTTP-Header protokolliert.

Transiente Daten

BIND fuehrt interne Caches (DNS-Cache, Connection-Tracking), die ausschliesslich im Arbeitsspeicher liegen und bei Neustart verworfen werden. Diese Daten werden nicht exportiert oder persistiert.

Aufbewahrungsdauer

Datentyp	Speicherung	Dauer
DNS-Queries (DoT/DoH)	Nicht gespeichert	—
Client-IP-Adressen	Nicht gespeichert	—
Landingpage-Zugriffe	Nicht gespeichert	—
DNS-Cache	Nur RAM	Bis TTL-Ablauf oder Neustart

2. Datenweitergabe

Keine Weitergabe von identifizierbaren Daten an Dritte.
Kein Verkauf, keine Vermietung, kein Tausch von Nutzerdaten.
Kein EDNS Client Subnet (ECS) — deine IP-Adresse wird nicht an Upstream-Autoritativserver weitergegeben.
Keine Korrelation von DNS-Daten mit anderen personenbezogenen Informationen.

3. Ausnahmen

Bei aussergewoehnlichen Stoerungen oder Angriffen kann Query-Logging temporaer aktiviert werden (rndc querylog on). Dies geschieht manuell, dauert maximal wenige Minuten, und die Logs werden danach geloescht. Es gibt keine automatisierte dauerhafte Erfassung.

Rate-Limiting-Events (IP-Adressen die >300 Anfragen/Sekunde generieren) werden protokolliert. Dies dient ausschliesslich dem Schutz des Dienstes vor Missbrauch.

4. Betreiber und Finanzierung

Betreiber: Sebastian van de Meer (Privatperson)
Website: kernel-error.de
Keine Partner, keine Drittanbieter, keine Investoren.
Der Dienst wird privat finanziert und nicht kommerziell betrieben.

5. Ergebnisfilterung

Keine. Autoritative Antworten werden unverfaelscht an den Client weitergeleitet. Es findet keine Filterung, Umleitung oder Manipulation von DNS-Antworten statt — weder aus kommerziellen, noch aus gesetzlichen Gruenden, noch zur Malware-Praevention. DNSSEC-Validierung kann dazu fuehren, dass Domains mit kaputten Signaturen als SERVFAIL zurueckgegeben werden — das ist kein Filtering, sondern korrekte Validierung.

6. Technische Faehigkeiten (Client-seitig)

Eigenschaft	Detail
Transportprotokolle	DoT (Port 853), DoH (Port 443 via HTTPS)
Authentifizierung	X.509-Zertifikat fuer `dns.kernel-error.de` (ECC/ECDSA, DigiCert)
DANE/TLSA	TLSA-Records publiziert fuer `_853._tcp.dns` und `_443._tcp.dns`
SVCB/HTTPS RRs	Service-Discovery via `_dns.dns.kernel-error.de` (RFC 9461)
TLS-Versionen	TLS 1.2, TLS 1.3
PQC Key Exchange	X25519MLKEM768 (bevorzugt), Fallback X25519, secp256r1, secp384r1
Bevorzugter Cipher	CHACHA20-POLY1305 (TLS 1.3), ECDHE-ECDSA-CHACHA20-POLY1305 (TLS 1.2)
HTTP-Protokolle	HTTP/2, HTTP/3 (QUIC)
DoH-Format	RFC 8484 Wire-Format (kein JSON)
DNSSEC-Validierung	Ja, fuer alle Antworten
EDNS(0) Padding	Client-seitig akzeptiert. Server-seitiges Response-Padding ist in BIND 9.20 nicht verfuegbar.
Session Tickets	Deaktiviert (kein Session-Tracking)
HTTP-Cookies	Nicht erforderlich, nicht gesetzt

7. Upstream-Verhalten (Resolver → Autoritativserver)

Eigenschaft	Detail
QNAME Minimization	Ja, relaxed (RFC 9156)
EDNS Client Subnet (ECS)	Nicht aktiviert — deine IP wird nicht weitergegeben
Aggressive DNSSEC Cache	Ja (RFC 8198)
NXDOMAIN Synthesis	Ja (RFC 8020)
Upstream-Verschluesselung	Nein (Queries an Autoritativserver laufen unverschluesselt — das ist Standard, da Autoritativserver fast nie DoT/DoH anbieten)

8. Bekannte Einschraenkungen

Server-seitiges EDNS(0) Response-Padding: Nicht verfuegbar. BIND 9.20 unterstuetzt kein automatisches Response-Padding (RFC 8467). Clients die Padding senden, erhalten keine gepaddte Antwort. Dies ist eine Limitation der Software, kein bewusster Verzicht.
DoT auf Port 443: Nicht angeboten. DoT laeuft ausschliesslich auf Port 853.
DNS over QUIC (DoQ): Nicht verfuegbar. BIND 9.20 unterstuetzt kein DoQ (RFC 9250).
Encrypted Client Hello (ECH): Nicht verfuegbar. nginx hat keine native ECH-Unterstuetzung.

9. Kontakt

Bei Fragen zu diesem Statement oder dem Dienst: security.txt oder via kernel-error.de.