1. Introduction (Einführung)

In RFC 1034 [RFC1034] beschreiben die Abschnitte 4.3.2 und 4.3.3 die Synthese von Antworten aus speziellen Ressourceneinträgen (Resource Records, RRs), die Wildcards genannt werden. Die Definition in RFC 1034 ist unvollständig und hat sich als verwirrend erwiesen. Dieses Dokument beschreibt die Wildcard-Synthese durch Hinzufügung zur Diskussion und durch begrenzte Änderungen. Die Änderungen werden vorgenommen, um Inkonsistenzen zu schließen, die zu Interoperabilitätsproblemen geführt haben. Die Beschreibung erweitert nicht den durch die ursprüngliche Definition beabsichtigten Servicerahmen.

Im Geist und Stil der ursprünglichen Dokumente vermeidet dieses Dokument die Spezifikation von Regeln für DNS-Implementierungen bezüglich Wildcards. Die Absicht ist nur zu beschreiben, was für Interoperabilität notwendig ist, nicht Implementierungsentscheidungen einzuschränken. Dieses Dokument berücksichtigt zusätzlich die Minimierung möglicher Abwärtskompatibilitätsprobleme mit Implementierungen, die der Definition von RFC 1034 entsprechen.

Dieses Dokument konzentriert sich auf das Konzept der Wildcards, wie es in RFC 1034 definiert ist. Es wird nichts über alternative Mittel zur Synthese von Ressourceneintragssets (Resource Record Sets, RRSets) impliziert, noch werden Alternativen diskutiert.

1.1 Motivation (Motivation)

Viele DNS-Implementierungen weichen auf verschiedene Weise von der ursprünglichen Definition von Wildcards ab. Obwohl allein dies klar einen Bedarf zur Klärung der ursprünglichen Dokumente zeigt, lag der Anstoß für dieses Dokument im Engineering der DNS-Sicherheitserweiterungen (DNS Security Extensions) [RFC4033]. Mit einer unklaren Definition von Wildcards wurde das Design der authentifizierten Verweigerung (authenticated denial) verwickelt.

Dieses Dokument beschränkt die Änderungen absichtlich auf das, was aufgrund von Implementierungserfahrung als notwendig erachtet wird, und hält sich so eng wie möglich an die ursprünglichen Dokumente. Um zu betonen, dass dieses Dokument Wildcards klären und anpassen, aber nicht neu definieren will, werden die relevanten Abschnitte aus RFC 1034 wörtlich wiederholt, damit neuer und alter Text verglichen werden können.

1.2 The Original Definition (Die ursprüngliche Definition)

Die Definition des Wildcard-Konzepts besteht aus der Dokumentation des Algorithmus, durch den ein Nameserver eine Antwort vorbereitet (Abschnitt 4.3.2 von RFC 1034), und der Art und Weise, wie ein Ressourceneintrag (Set) als Quelle synthetischer Daten identifiziert wird (Abschnitt 4.3.3).

Im Folgenden wird der Begriff "wildcard" aus Abschnitt 4.3.3 von RFC 1034 zitiert.

# In the previous algorithm, special treatment was given to RRs with
# owner names starting with the label "*".  Such RRs are called
# wildcards. Wildcard RRs can be thought of as instructions for
# synthesizing RRs.  When the appropriate conditions are met, the
# name server creates RRs with an owner name equal to the query name
# and contents taken from the wildcard RRs.

Dieser Text folgt unmittelbar auf den Algorithmus, der den Begriff wildcard zum ersten Mal verwendet. In dieser Definition bezieht sich wildcard auf den Ressourceneintrag. In anderen Verwendungen wurde wildcard auf Domainnamen angewandt und auch verwendet, um die von Wildcards abhängige Betriebspraxis zur Erzeugung von Antworten zu beschreiben. Dies zeigt, dass für die Diskussion von Wildcards klare und eindeutige Begriffe definiert werden müssen.

Der Abschnitt 4.3.2 von RFC 1034 trägt den Titel "Algorithm" (Algorithmus), und der Teil 'c' des Schritts 3 erwähnt die Verwendung von Wildcards bei der Vorbereitung einer Antwort. Beachten Sie, dass das Wort "wildcard" im Algorithmus nicht vorkommt; der Algorithmus bezieht sich auf das Label "*". Abschnitt 3 dieses Dokuments zerlegt die wildcard-bezogenen Teile des Algorithmus im Detail. Im Folgenden ist der relevante Anfang des Algorithmus aus "Algorithm" dargestellt.

#    c. If at some label, a match is impossible (i.e., the
#       corresponding label does not exist), look to see if [...]
#       the "*" label exists.

Der Geltungsbereich dieses Dokuments ist die Definition von Wildcards in RFC 1034 sowie die Auswirkungen von Aktualisierungen dieser Dokumente, wie etwa DNS Security (DNSSEC). Dieses Dokument berücksichtigt keine Alternativen zur Synthese von Antworten. (Beachten Sie, dass hier keine Referenzen aufgeführt sind. Es ist derzeit keine Dokumentation über Alternativen bekannt, obwohl es Erwähnungen in Mailinglisten gab.)

1.3 Roadmap to This Document (Roadmap zu diesem Dokument)

Dieses Dokument erfüllt diese drei Aufgaben:

Definiert neue Begriffe
Nimmt geringfügige Änderungen vor, um widersprüchliche Konzepte zu vermeiden
Beschreibt die Aktionen bestimmter Ressourceneinträge als Wildcards

1.3.1 New Terms (Neue Begriffe)

Um zu erörtern, welche Ressourceneinträge Wildcards sind, definiert dieses Dokument zwei Begriffe: "asterisk label" (Sternchen-Label) und "wildcard domain name" (Wildcard-Domainname). Diese Begriffe werden in Abschnitt 2.1.1 definiert.

Um die Rolle von Wildcards im Nameserver-Algorithmus aus Abschnitt 4.3.2 von RFC 1034 zu klären, definiert dieses Dokument "source of synthesis" (Synthesequelle) und "closest encloser" (nächster Einschließer). Diese Begriffe werden in Abschnitt 3.3.1 definiert.

1.3.2 Changed Text (Geänderter Text)

Durch den Ersatz des Texts aus Abschnitt 4.3.3 von RFC 1034 durch den Text aus Abschnitt 2.1 dieses Dokuments wurde die Definition davon, was "Wildcards" sind, geändert. Der Ersatztext definiert "wildcard domain name" (Wildcard-Domainname) und "asterisk label" (Sternchen-Label) als Begriffe. Dies soll die Bedeutung nicht ändern, sondern nur klarer ausdrücken.

Der Grund für diese Änderung ist, dass in RFC 1034 der Begriff wildcard auf zwei Arten definiert wird. In Abschnitt 4.3.3 wird "wildcard" zur Benennung von Ressourceneinträgen verwendet. Im Algorithmus aus Abschnitt 4.3.2 sind "wildcards" Domainnamen und Labels, keine Ressourceneinträge. Da im letzteren Fall nicht klar ist, ob der Begriff "wildcard" eine oder zwei Verwendungen ist (eine für das Label, eine für den Namen), wurden neue Begriffe eingeführt.

Ein Teil des Algorithmus aus Schritt 3 von Abschnitt 4.3.2 in RFC 1034 wurde geändert und wird in Abschnitt 3.3.3 dieses Dokuments angegeben. Dies basiert darauf, die Synthese bestimmter Typen zuzulassen und zu verbieten, dass bestimmte Typen Synthesequellen sind, wie etwa SIG (der alte Name für RRSIG).

1.3.3 Considerations with Special Types (Überlegungen zu speziellen Typen)

Abschnitt 4 untersucht verschiedene Ressourceneintragstypen und erläutert, wie sie behandelt werden sollten und nicht sollten.

RFC 1034 stellt fest, dass CNAME ein Typ ist, der nicht mit anderen Daten koexistieren kann. Da jedoch der "wildcard"-Text überarbeitet wurde, ist es notwendig zu erörtern, dass die Synthese verboten ist, wenn ein CNAME-RRSet in der Synthesequelle vorhanden ist.

Die Interaktion anderer Ressourceneintragstypen mit Wildcards wird in der Reihenfolge ihres Status diskutiert: Standard, Experimentell, Veraltet und Zurückgezogen.

1.4 Standards Terminology (Standardterminologie)

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind wie in RFC 2119 [RFC2119] beschrieben zu interpretieren.

Da diese Schlüsselwörter nur bei der Erörterung des Protokolls verwendet werden, ist der einzige relevante Abschnitt Abschnitt 4, und Abschnitt 4 verweist auf Abschnitt 3. Der Rest dieses Dokuments dient nur der Erläuterung und Klärung von Konzepten.

RFC 1034 verwendet den Begriff "authoritative" (autoritativ), um einen Nameserver zu beschreiben, der "the complete information for a zone" (die vollständigen Informationen für eine Zone) besitzt. Um Verwirrung zu vermeiden, verwendet dieses Dokument die Begriffe "authoritative name server" (autoritativer Nameserver) und "zone" (Zone), um dieselbe Beziehung wie in RFC 1034 zu beschreiben, nämlich dass ein Nameserver für den Inhalt einer bestimmten Zone autoritativ ist. Diese Unterscheidung wird getroffen, weil ein Nameserver normalerweise für mehrere Zonen autoritativ ist, aber nicht für den gesamten DNS-Baum.