Zusammenfassung

  • Der Resolver kann nur nach der nächsten unbekannten Grenze fragen, statt überall vollständigen QNAME und ursprünglichen QTYPE offenzulegen.
  • Datenschutz hängt von Cache, begrenzter Iteration und Fallback ab; der rekursive Resolver sieht weiterhin die vollständige Anfrage.

Analyse

Bei leerem Cache kann eine traditionelle Auflösung von www.example.com den ganzen Namen an den Root senden. Dieser braucht nur .com, um die nächste Delegation zu liefern. Der Rest ist Tradition, keine Protokollpflicht.

RFC 9156 lässt den Resolver von der nächsten bekannten Delegation ausgehen und nur ein weiteres Label offenlegen. A oder AAAA können den ursprünglichen Typ verbergen. Nur der Server für den endgültigen Namen benötigt QNAME und QTYPE vollständig.

Die Änderung ist einseitig und verlangt kein neues Protokoll. Zonenschnitte liegen jedoch nicht an jedem Label. Ein kalter Resolver muss mitunter Label für Label ergänzen, bis er die Autoritätsgrenze findet.

Der Cache wird zur Offenlegungsgrenze. RFC 8020 lässt ein gespeichertes NXDOMAIN Nachfahren verneinen; RFC 8198 erlaubt synthetische negative Antworten aus validierten NSEC- oder NSEC3-Beweisen. Bewiesene Abwesenheit braucht keine weitere Upstream-Anfrage.

Iteration muss begrenzt sein. Tiefe Namen können Arbeit vervielfachen; RFC 9156 verlangt eine Begrenzung und nennt 10 als empfohlenes Maximum für einen Mechanismus.

Die Zusage bleibt begrenzt. Der rekursive Resolver sieht alles, Beobachter an mehreren Punkten können korrelieren, und Verschlüsselung behandelt eine andere Exposition. Minimierung reduziert Daten bei Zwischenautoritäten.

Fallback mit dem vollständigen Namen kann Verfügbarkeit retten und Datenschutz still verlieren. Die RFCs belegen keine Praxis eines benannten Betreibers.

Quellen