3. Impact of a Wildcard Domain Name on a Response (Auswirkung)

3. Impact of a Wildcard Domain Name on a Response (Auswirkung eines Wildcard-Domainnamens auf eine Antwort)

Der Algorithmus in RFC 1034, Abschnitt 4.3.2, ist unverändert, außer wie in Abschnitt 3.3.3 dieses Dokuments spezifiziert. Das Problem liegt in der Interpretation des Algorithmus in RFC 1034, Abschnitt 4.3.2, Schritt 3, Teil 'c', wie in Abschnitt 4.3.3 von RFC 1034 dargelegt, der die Wildcards definiert.

In den folgenden Erläuterungen, sofern auf RFC 1034 Bezug genommen wird, gilt der Text auch dann, wenn beliebige Aktualisierungen von RFC 1034 (wie [RFC2672], das DNAME definiert) angewendet werden.

3.1 Step 2 (Schritt 2)

Schritt 2 des Suchalgorithmus besteht darin, "die längstmögliche Übereinstimmung zu finden". Es wurde argumentiert, dass eine zwischengespeicherte Verweisung die Frage der "längsten Übereinstimmung" beantwortet und die Notwendigkeit beseitigt, mit den nachfolgenden Schritten fortzufahren. Dies ist falsch. Das Vervollständigen von Schritt 2 umfasst die Bestimmung, ob weiter oben in der DNS-Hierarchie eine längere Übereinstimmung verfügbar ist.

3.2 Step 3 (Schritt 3)

Schritt 3 des Suchalgorithmus in RFC 1034, Abschnitt 4.3.2, ist der Ort, an dem Wildcards aufgerufen werden, aber nur, wenn ein Ressourceneintragssatz, der dem Typ der Abfrage entspricht, nicht beim Domainnamen gefunden wird. Dies ist der Teil 'c' von Schritt 3. Der Satz lautet wie folgt:

# c. If at some label, a match is impossible (i.e., the
#    corresponding label does not exist), look to see if [...]
#    the "*" label exists.
#
#    If the "*" label does not exist, check whether the name
#    we are looking for is the original QNAME in the query
#    or a name we have followed due to a CNAME.  If the name
#    is original, set an authoritative name error in the
#    response and exit.  Otherwise just exit.
#
#    If the "*" label does exist, match RRs at that node
#    against QTYPE.  If any match, copy them into the answer
#    section, but set the owner of the RR to be QNAME, and
#    not the node with the "*" label. [...]

3.3 Part 'c' (Teil 'c')

Dies ist die Diskussion über den aus RFC 1034, Abschnitt 4.3.2, Schritt 3, Teil 'c' zitierten "look to see"-Text.

3.3.1 Closest Encloser and the Source of Synthesis (Nächster Einschließer und Synthesequelle)

Der "nächste Einschließer (closest encloser)" ist der Knoten im Baum der existierenden Domainnamen der Zone, der die meisten Labels hat, die mit einem Abfragenamen übereinstimmen (aufeinanderfolgend, beginnend beim Wurzel-Label abwärts). Jede Übereinstimmung ist ein "label match" (Label-Übereinstimmung), und die Zählung der Anzahl übereinstimmender Labels ist der "closest encloser proof" (Beweis des nächsten Einschließers). In gewissem Sinne ist der nächste Einschließer der tiefste existierende Domainname in der Zone, der ein Vorfahre des Abfragenamens ist.

Die "Synthesequelle (source of synthesis)" ist der Wildcard-Domainname, der unmittelbar vom nächsten Einschließer absteigt, vorausgesetzt, dass an diesem Ort in der Zone ein Wildcard-Domainname erscheint. Die Synthesequelle wird durch Voranstellen des Sternchen-Labels ("*") an den nächsten Einschließer bestimmt.

Die Verwendung der Phrase "source of synthesis" (Synthesequelle), um den an der Wildcard-Synthese beteiligten Wildcard-Domainnamen zu beschreiben, bietet eine nützliche Terminologie und verursacht keine Probleme bei der Beschreibung der Verwendung von Namen, die kein Sternchen-Label an der am wenigsten signifikanten Position haben, da diese keine Wildcard-Domainnamen sind.

3.3.2 Closest Encloser and Source of Synthesis Examples (Beispiele für nächsten Einschließer und Synthesequelle)

Dies wird anhand der Zone aus dem Beispiel in Abschnitt 2.2.1 erläutert:

Für den Abfragenamen "host.example." ist der nächste Einschließer "example." und die Synthesequelle ist "*.example.".

Für den Abfragenamen "a.host.example." ist der nächste Einschließer "host.example." und die Synthesequelle ist "*.host.example.", aber dieser Wildcard-Domainname ist nicht Teil der Zone und existiert nicht.

Für den Abfragenamen "_telnet._tcp.host.example." existiert eine exakte Übereinstimmung, und es gibt keine Synthesequelle. Dies liegt daran, dass eine exakte Übereinstimmung Vorrang vor der Wildcard-Übereinstimmung hat.

Für den Abfragenamen "_dns._udp.host.example." ist der nächste Einschließer "host.example." und die Synthesequelle ist "*.host.example.", aber dieser Wildcard-Domainname existiert nicht in der Zone, und es gibt keine Synthesequelle.

Für den Abfragenamen "*.example." existiert eine exakte Übereinstimmung, und es gibt keine Synthesequelle.

Für den Abfragenamen "a..example." ist der nächste Einschließer ".example." und die Synthesequelle ist "..example.", aber diese existiert nicht in der Zone, und es gibt keine Synthesequelle.

Für den Abfragenamen "_telnet._tcp..example." ist der nächste Einschließer ".example." und die Synthesequelle ist "..example.", aber diese existiert nicht in der Zone, und es gibt keine Synthesequelle.

Für den Abfragenamen "host3..example." ist der nächste Einschließer ".example." und die Synthesequelle ist "..example.", aber diese existiert nicht in der Zone. Es gibt keine Synthesequelle. Das Lehreich an diesem Fall ist, dass "host3.*.example." existiert, aber weder von sich selbst noch von einem anderen Namen die Synthesequelle ist.

Der Kernpunkt dieser Beispiele ist die Identifizierung des nächsten Einschließers und der Synthesequelle und nicht, was der Nameserver als Autorität antwortet (Antwort, Delegierung, NXDOMAIN oder NOERROR/NODATA).

3.3.3 Type Matching (Typabgleich)

Abschnitt 4.3.3 von RFC 1034 besagt:

# 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.

und

# If the "*" label does exist, match RRs at that node against QTYPE.
# If any match, copy them into the answer section, but set the owner
# of the RR to be QNAME, and not the node with the "*" label.

Der zuerst zitierte Abschnitt beschreibt die Synthese von Einträgen aus einem Wildcard-RRSet, indem der Eigentümername des RR geändert wird. Der zweit zitierte Abschnitt besagt "match RRs ... against QTYPE" (gleiche RRs ... mit QTYPE ab) und kopiert nur, wenn eine Übereinstimmung vorliegt. Offensichtlich können, wie bei allen Namensübereinstimmungen, nur RRs des Typs QTYPE kopiert werden. Wenn QTYPE nicht CNAME ist (oder QTYPE ANY ist), gibt es keine CNAME-Übereinstimmung. Das Vorhandensein von CNAME schließt das Vorhandensein anderer Typen aus.

Bei einem Wildcard-CNAME stimmt das CNAME-RRSet nicht mit einer Nicht-CNAME-Abfrage überein und wird nicht für die Synthese verwendet. Dies ähnelt dem Fall, dass ein vorhandenes CNAME-RRSet an einem Terminalknoten ignoriert wird, wenn der angeforderte Typ nicht CNAME ist.

Bei einem Wildcard-CNAME-RRSet wurde der Satz, der die Synthese beschreibt, geändert. Aus RFC 1034:

# If the "*" label does exist, match RRs at that node against QTYPE.
# If any match, copy them into the answer section, but set the owner
# of the RR to be QNAME, and not the node with the "*" label.  Go
# to step 6.

wurde wie folgt geändert:

# If the "*" label does exist, match RRs at that node against QTYPE.
# If any match, copy them into the answer section, but set the owner
# of the RR to be QNAME, and not the node with the "*" label.
# If QTYPE is CNAME, continue with step 3.d.
# If QTYPE is not CNAME and a CNAME RRSet exists at the node,
# copy the CNAME RRSet into the answer section,
# but set the owner of the RRSet to be QNAME,
# and not the node with the "*" label.
# Go to step 6.

Die Verwirrung wurde durch diesen Absatz in RFC 1034 verursacht:

# To illustrate the use of wildcard RRs, suppose a large company with
# a large IT staff wanted to provide a TELNET gateway

Die Verwirrung entstand durch das Beispiel, das nahelegt, dass ein aus einem Wildcard synthetisierter CNAME-RR dann verwendet wird, um eine Adresse für eine A-Abfrage zu erhalten. Eine Interpretation ist, dass das Wildcard eine Art "Makroexpansion" ist und dieses Beispiel zeigt, wie auf eine A-Abfrage geantwortet wird, wenn ein Wildcard-CNAME vorhanden ist. Eine andere Interpretation ist, dass dies ein Sonderfall ist. Eine dritte Interpretation ist, dass das Wildcard expandiert werden sollte, wenn die Zonendaten in den Server geladen werden, und danach ohne besondere Expansionsregeln angewendet werden sollten.

Die von der Arbeitsgruppe übernommene Position ist, dass dieses Beispiel anomal ist und eher verwirrt als lehrt. Durch die Änderung des Wortlauts des Algorithmus wird klargestellt, dass dieses Beispiel eine falsche Verwendung von Wildcards ist.

3.4 Authoritative Name Error (Autoritativer Namensfehler)

Mit der obigen Definition eines Zoneneintrags, der sich unter einem Zonenscheitelpunkt befindet, sowie der des nächsten Einschließers und der Synthesequelle erzeugt Schritt 3.c des Algorithmus aus RFC 1034 (wie oben korrigiert) eine Antwort mit einem autoritativen Namensfehler (NXDOMAIN), wenn keine Synthesequelle gefunden werden kann. Es wird keine Antwort mit einem autoritativen Namensfehler zurückgegeben, wenn eine Synthesequelle gefunden wird, unabhängig davon, ob ein Typabgleich vorliegt oder nicht.

3.5 Empty Non-terminals (Leere Nicht-terminale)

Beachten Sie, dass, wenn ein Wildcard-Domainname "*.example." existiert, dann "example." (der nächste Einschließer) ein leeres Nicht-terminales ist. Dasselbe gilt für alle Vorfahren eines delegierten Wildcard-Domainnamens oder eines solchen, der andere als Zonen-Einträge besitzt; diese Vorfahren sind leere Nicht-terminale. Ein leeres Nicht-terminales ist keine Antwort mit einem autoritativen Namensfehler, da der nächste Einschließer existiert.