Zusammenfassung

  • Eine DNS-Wildcard ist keine Mustersuche, sondern ein RRset unter einem Namen mit dem ersten Label *; sie kommt erst nach dem Scheitern exakter Baumübereinstimmung infrage.
  • RFC 4592 bestimmt den nächsten vorhandenen Umschließer und genau einen Kandidaten, *.<closest-encloser>; ein anderer Stern wird bei Misserfolg nicht gesucht.
  • DNSSEC beglaubigt Quelldaten und den Beweis, dass kein exakter oder näherer Name Vorrang hatte, nicht aber Sicherheit oder Absicht des erzeugten Ziels.

Eine konkrete Antwort ohne konkreten Eintrag

Enthält eine Zone bei *.example eine Adresse, aber keinen Eigentümernamen blau.example, kann die Antwort dennoch diesen sichtbaren Eigentümer tragen. Wert und TTL stammen vom Wildcard-RRset. Die konkrete Form entstand für die Anfrage; als eigener Eigentümer war sie nicht gespeichert.

RFC 1034 beschrieb Wildcards 1987 als Anweisungen zur Synthese von Datensätzen. Ein frühes Beispiel war die gemeinsame Mailzustellung für unbekannte Namen. Der Stern registrierte dabei weder unendlich viele Eigentümer noch führte er reguläre Ausdrücke ein. Er erlaubte dem autoritativen Server eine bedingte Handlung innerhalb seiner Zone.

Eine positive DNS-Antwort belegt daher nicht, dass jemand den genauen Namen einzeln eingerichtet, geprüft oder beabsichtigt hat. Sie belegt das Ergebnis der veröffentlichten Zonenregel. Absicht und Anwendungsvertrauen brauchen eigene Nachweise.

Vorhandene Namen haben das erste Ablehnungsrecht

Zunächst vergleicht der Server die Labels exakt. Existiert der Name, darf die Wildcard keinen fehlenden Typ ergänzen. Ein Eigentümer mit AAAA, aber ohne MX bleibt ohne MX und leiht sich keinen MX von *.example.

Ein Name kann auch ohne eigenes RRset existieren. Hat er einen tieferen Nachfahren, bildet er einen leeren Nicht-Endknoten. Dieser stille Knoten verändert den Suchweg. Ein neuer tiefer Datensatz kann deshalb eine scheinbar unabhängige Wildcard-Antwort abschalten.

Wird der letzte Nachfahre entfernt, kann der leere Knoten verschwinden und eine breitere Wildcard wieder greifen. Nicht der Stern änderte sich, sondern der Baum, der seine Befugnis begrenzt.

Ein nächster Umschließer, eine mögliche Quelle

Implementierungserfahrung und DNSSEC verlangten eine eindeutigere Fassung. RFC 4592 nennt den vorhandenen Zonenknoten mit der längsten vom Wurzellabel aus übereinstimmenden Labelkette den Closest Encloser.

Fällt die exakte Suche aus dem Baum, entsteht genau ein Kandidat unmittelbar darunter: *.<closest-encloser>. Existiert er, ist er Synthesequelle. Existiert er nicht, findet keine Wildcard-Synthese statt.

Der Server sucht nicht bei Vorfahren nach einem Ersatz. Fehlt der angefragte Typ an der Quelle, entsteht Wildcard-No-Data; eine weiter entfernte Vorgabe füllt die Lücke nicht. Pro Anfrage gibt es höchstens eine Quelle.

Damit werden verschachtelte Wildcards berechenbar. Zugleich verliert die Aussage „deckt alles darunter ab“ ihren Sinn: Schon ein näherer, selbst leerer Knoten berechnet die einzige zulässige Quelle neu.

Der Stern ist ein Label, keine Mustersprache

Nur ein erstes Label, das genau * lautet, macht einen Domainnamen zur Wildcard. Ein Stern an anderer Stelle hat keine solche Wirkung. Auch ein wörtlicher Stern in der Anfrage fordert keine Mehrfachsuche, sondern wird wie ein normales Label behandelt.

Nach der Synthese gelten die üblichen Regeln des RR-Typs. Ein Wildcard-CNAME kann erzeugt und danach als gewöhnlicher Alias verfolgt werden. Das macht DNS weder zum Anwendungsrouter noch zur Zertifikatsrichtlinie oder Teilzeichen-Suche.

Delegation beendet die Vorgabe des Elternteils

Schon RFC 1034 ließ Wildcard-Vorgaben nicht über Zonengrenzen laufen. Trifft der Elternserver auf eine Delegation, verweist er auf das Kind, statt unterhalb des Schnitts seinen Stern anzuwenden. Das Kind kann eine eigene Wildcard veröffentlichen, nun unter eigener Autorität.

Die Regel trennt Kontrolle. Wer einen Teilbaum delegiert, behält keine versteckte Ersatzantwort für seine Lücken. Der neue Betreiber erbt umgekehrt die Bequemlichkeit des Elternteils nicht automatisch.

Die Abwesenheit beweisen, die Synthese erlaubte

Jede Wildcard-Antwort setzt voraus, dass nichts Genaueres Vorrang hatte. RFC 4035 macht diese Voraussetzung in signierten Zonen prüfbar. Neben erweitertem RRset und Signatur gehören authentisierte NSEC-Belege dazu, die eine exakte oder nähere Übereinstimmung ausschließen.

Die Labelanzahl in RRSIG lässt den Prüfer den ursprünglich signierten Wildcard-Eigentümer rekonstruieren, obwohl die Antwort den Anfragenamen zeigt. So werden Quelle und strukturelle Lücke gemeinsam geprüft.

DNSSEC bestätigt weder sichere Dienste noch menschliche Absicht oder Anwendungsrechte. Es beglaubigt die Aussage der Zone und ihre Anwendung nach der Baumrangfolge.

Quellen und Grenzen

Der geschlossene Satz umfasst RFC 1034, RFC 4592 und RFC 4035. Er belegt Mechanismus, Begriffe und DNSSEC-Nachweise, nicht heutige Nutzung, Anfragevolumen, Missbrauch oder Produktverhalten.