Zusammenfassung

  • EDNS(0)-Option 12 erlaubt variable Füllbytes in verschlüsselten DNS-Nachrichten. Standardisiert wird ein Drahtformat, kein Privatsphäre-Ergebnis. Die Blöcke von 128 Oktetten für Anfragen und 468 für Antworten sind eine experimentelle Strategie aus RFC 8467.
  • Schutz entsteht gemeinsam: Der Client füllt die Anfrage, der Server die Antwort, TLS, HTTP oder QUIC bildet eine weitere Hülle, der Pfad setzt Kosten- und Fragmentierungsgrenzen. Zeit, Endpunkte und Zahl der Austauschvorgänge bleiben beobachtbar.

Zwei DoT-Resolver können beide „Padding aktiv“ melden und Gegensätzliches bewirken. Der erste rundet Anfragen auf ein Vielfaches von 128 und Antworten auf 468. Der zweite fügt stets 16 Bytes hinzu. Beide verwenden eine gültige Option 12. Beim zweiten bleiben jedoch sämtliche Abstände der ursprünglichen Größen erhalten; der bekannte Zuschlag lässt sich abziehen.

Transportverschlüsselung schützt den Inhalt zwischen Client und Server. Die Länge des Chiffretexts verschwindet nicht automatisch. Bestimmte Namen, RR-Typen und Antwortmengen erzeugen charakteristische Größenpaare. Ein Beobachter mit bekannten Klartextmustern kann versuchen, sie zuzuordnen, ohne einen Namen zu entschlüsseln.

RFC 7830 liefert bewusst nur ein kleines Werkzeug. Im OPT-Pseudo-RR von EDNS trägt Padding den Code 12. Die Option darf höchstens einmal pro Nachricht vorkommen. Ihr Längenfeld zählt Fülloktette; null ist zulässig, obwohl der Optionskopf selbst vier Oktette belegt. Sender sollten Nullen verwenden, Empfänger müssen andere Werte annehmen. Inhaltliche DNS-Bedeutung haben sie nicht.

Die Spezifikation wählt keine Menge. So bleibt gemeinsame Syntax von lokaler Politik getrennt. RFC 8467 verglich später Verfahren und empfahl experimentell Block Padding: Anfragen auf das nächste Vielfache von 128, Antworten auf ein Vielfaches von 468. Mehrere ursprüngliche Größen landen in derselben sichtbaren Klasse.

Eine Klasse ist nicht informationslos. Ist die Blockgröße bekannt, grenzt eine 256-Oktett-Anfrage die vorherige Länge ein. Zeitpunkt, Abstand, Richtung und Zahl der Nachrichten ändern sich nicht. Der Verkehr kann trotz Verschlüsselung und Padding als DNS erkennbar bleiben. Deckverkehr oder künstlicher Jitter beträfen andere Seitenkanäle und andere Kosten.

Die Anfrage erteilt keinen unbegrenzten Befehl. Enthält sie Padding, muss der Server die Antwort füllen, sofern dadurch die erlaubte UDP-Nutzlast nicht überschritten wird. Ohne Padding darf er es bei angekündigtem EDNS tun, ohne EDNS nicht. Der Client eröffnet einen begrenzten Handlungsraum; eine wirksame Antwortgröße schreibt er nicht vor.

Der Pfad macht aus Privatsphäre eine Zustellfrage. Padding wird nach allen anderen EDNS-Optionen angewandt, weil es deren Restplatz verbraucht. Das Zwei-Oktett-Längenfeld von DNS über TCP bleibt aus der Berechnung heraus; sonst verriete ein Transportwechsel allein durch Framing eine andere Klasse. Nahe der MTU verursachen große Blöcke unnötige Fragmentierung, oberhalb erzwingen sie sie bei UDP. RFC 7830 verbietet Padding für Klartext-DNS und warnt vor zusätzlicher Verstärkung.

DoH und DoQ verschieben die Kontrolle. DoH kann Padding in einem authentisierten HTTPS-Kanal tragen, doch Header, Cookies, Verbindungswiederverwendung und Timing bilden andere Korrelationen. DoQ kann DNS-Nachrichten füllen oder, wenn die QUIC-API es erlaubt, ganze QUIC-Pakete auf wenige Größen bringen und Bestätigungen sowie Flusssteuerung berücksichtigen.

Kein Beteiligter besitzt das Endergebnis. Der Client beherrscht Anfrage und Resolverwahl, der Server die Antwort, die Transportbibliothek die äußere Form und das Netz die zuverlässig lieferbare Größe. Der IANA-Eintrag beweist gemeinsames Vokabular, nicht Implementierung, Aktivierung oder Wirkung.

Der Running-Code-Test ist eine Verteilung, kein Häkchen. Benötigt werden Größen vor und nach dem Padding, Belegung der Klassen, ungefüllte Antworten, zusätzliche Bytes, Kürzung, Fragmentierung, Verlust, Wiederholung und Fallback. Erst daraus ergibt sich, ob eine Anonymitätsmenge wuchs.