Zusammenfassung

  • Ein individueller Internet-Draft schlägt vor, dass ein nicht validierender rekursiver Resolver das DO-Bit auch stromaufwärts löscht, wenn die eingehende Anfrage ohne DO kommt.
  • Fragt später ein validierender Client nach, muss der Resolver den Cache-Eintrag ohne DNSSEC-Belege erkennen und den autoritativen Server erneut befragen.

Die erste Anfrage bekommt eine schlanke Antwort. Die zweite verlangt den kryptografischen Beleg. Im Cache liegt die Antwort, aber der Beleg war nie dabei. Genau diesen zweiten Weg verhandelt der am 30. Oktober von Warren Kumari, Geoff Huston und Peter Thomassen eingereichte Entwurf Clearing the DO bit for DNSSEC. Er ist ein individueller Diskussionsbeitrag, kein beschlossener IETF-Standard.

Das DO-Bit fordert DNSSEC-Datensätze an. RFC 3225 und RFC 4035 verlangen bislang, dass ein DNSSEC-fähiger rekursiver Resolver seine ausgehende Anfrage mit DO versieht, auch wenn der ursprüngliche Client darauf verzichtet. Für diesen Client kann er die Belege aus der Antwort entfernen und sie dennoch für spätere Anfragen vorhalten.

Der Entwurf greift einen engeren Fall heraus: Der Resolver validiert selbst nicht und die eingehende Anfrage trägt kein DO. Dann soll auch seine ausgehende Anfrage ohne DO laufen. Der autoritative Server fügt keine DNSSEC-Belege automatisch hinzu. Größere künftige Post-Quanten-Signaturen könnten Antworten aufblähen, Abschneidungen und TCP-Rückfälle vermehren. Messwerte zu Ersparnis, Fehlern oder Betriebseinsatz liefert das Papier nicht.

Das Kleingedruckte steht im Cache. Der Resolver muss markieren, welche Einträge ohne DNSSEC-Daten beschafft wurden. Kommt eine Anfrage mit DO, muss er dieselben Daten mit DO erneut vom autoritativen Server holen. Ein gewöhnlicher Cache-Treffer enthält sonst gerade nicht das Material, das der validierende Client braucht. In der DNSOP-Debatte steht dem Vorschlag die Forderung nach mehr Stream-Transport für große Antworten gegenüber. Entscheidend wären Implementierungstests beider Ankunftsreihenfolgen, korrekte Validierung und die gesamte Last auf den beteiligten Servern.

Entwurf · RFC 3225 · RFC 4035