Zum Hauptinhalt springen

10. Benennungsprobleme

Aus einigen Abschnitten der DNS-Spezifikation [RFC1034, RFC1035] wurde manchmal gefolgert, dass einem Host, oder vielleicht einer Schnittstelle eines Hosts, genau ein autoritativer oder offizieller Name zustehe, der als kanonischer Name bezeichnet wird. Eine solche Anforderung gibt es im DNS nicht.

10.1. CNAME-Ressourcen-Datensätze​

Der DNS-CNAME-Eintrag ("canonical name") existiert, um den zu einem Aliasnamen gehörenden kanonischen Namen bereitzustellen. Für einen einzelnen Alias darf es nur einen solchen kanonischen Namen geben. Dieser Name sollte im Allgemeinen ein Name sein, der anderswo im DNS existiert, obwohl es einige seltene Anwendungen für Aliase gibt, bei denen der zugehörige kanonische Name im DNS nicht definiert ist. Ein Aliasname (Label eines CNAME-Eintrags) darf, wenn DNSSEC verwendet wird, SIG-, NXT- und KEY-RRs haben, aber keine anderen Daten. Das heißt, für jedes Label im DNS (jeden Domainnamen) trifft genau eines der Folgenden zu:

  • es existiert ein CNAME-Eintrag, optional begleitet von SIG-, NXT- und KEY-RRs,
  • es existieren ein oder mehrere Einträge, von denen keiner ein CNAME-Eintrag ist,
  • der Name existiert, hat aber keine zugeordneten RRs irgendeines Typs,
  • der Name existiert überhaupt nicht.

10.1.1. CNAME-Terminologie​

Es war traditionell üblich, das Label eines CNAME-Eintrags als "ein CNAME" zu bezeichnen. Das ist bedauerlich, denn "CNAME" ist eine Abkürzung für "canonical name", und das Label eines CNAME-Eintrags ist mit Sicherheit kein kanonischer Name. Es ist jedoch ein eingebürgerter Sprachgebrauch. Daher muss sorgfältig darauf geachtet werden, eindeutig klarzustellen, ob das Label oder der Wert (der kanonische Name) eines CNAME-Ressourcen-Datensatzes gemeint ist. In diesem Dokument wird das Label eines CNAME-Ressourcen-Datensatzes stets als Alias bezeichnet.

10.2. PTR-Einträge​

Verwirrung über kanonische Namen hat zu der Annahme geführt, dass ein PTR-Eintrag genau einen RR in seiner Ressourcen-Datensätze-Menge haben sollte. Dies ist falsch; der maßgebliche Abschnitt von RFC1034 (Abschnitt 3.6.2) gibt an, dass der Wert eines PTR-Eintrags ein kanonischer Name sein sollte. Das heißt, er sollte kein Alias sein. Dieser Abschnitt impliziert nicht, dass für einen Namen nur ein PTR-Eintrag zulässig ist. Eine solche Einschränkung sollte nicht gefolgert werden.

Beachten Sie, dass der Wert eines PTR-Eintrags zwar kein Alias sein darf, aber nicht verlangt wird, dass der Vorgang der Auflösung eines PTR-Eintrags auf keine Aliase stößt. Das Label, das für einen PTR-Wert nachgeschlagen wird, kann einen CNAME-Eintrag haben. Das heißt, es kann ein Alias sein. Der Wert dieses CNAME-RR, sofern er nicht ein weiterer Alias ist, was er nicht sein sollte, gibt den Ort an, an dem der PTR-Eintrag gefunden wird. Dieser Eintrag liefert das Ergebnis der PTR-Typ-Abfrage. Dieses endgültige Ergebnis, der Wert des PTR-RR, ist das Label, das kein Alias sein darf.

10.3. MX- und NS-Einträge​

Der Domainname, der als Wert eines NS-Ressourcen-Datensatzes oder als Teil des Werts eines MX-Ressourcen-Datensatzes verwendet wird, darf kein Alias sein. Die Spezifikation ist in diesem Punkt nicht nur eindeutig, sondern die Verwendung eines Alias an einer dieser beiden Stellen funktioniert weder so gut, wie man hoffen könnte, noch erfüllt sie in befriedigender Weise das Ziel, das zu diesem Vorgehen geführt haben mag. Dieser Domainname muss als Wert einen oder mehrere Adresseinträge haben. Derzeit werden dies A-Einträge sein, künftig könnten jedoch andere Datensatztypen, die Adressierungsinformationen liefern, akzeptabel sein. Er kann auch andere RRs haben, aber niemals einen CNAME-RR.

Die Suche nach NS- oder MX-Einträgen verursacht eine "additional section processing" (Verarbeitung des Additional-Abschnitts), bei der dem Answer-Abschnitt Adresseinträge angehängt werden, die dem Wert des gesuchten Eintrags zugeordnet sind. Dies hilft, unnötige zusätzliche Anfragen zu vermeiden, die bei der ersten Anfrage leicht vorhersehbar sind.

Die Verarbeitung des Additional-Abschnitts umfasst keine CNAME-Einträge, geschweige denn die Adresseinträge, die dem aus dem Alias abgeleiteten kanonischen Namen zugeordnet sein können. Wenn also ein Alias als Wert eines NS- oder MX-Eintrags verwendet wird, wird kein Adresseintrag zusammen mit dem NS- oder MX-Wert zurückgegeben. Dies kann bei jeder Anfrage zusätzliche Anfragen und zusätzliche Netzlast verursachen. Für den DNS-Administrator ist es trivial, dies zu vermeiden, indem er den Alias auflöst und den kanonischen Namen direkt in den betroffenen Eintrag einträgt, und zwar einmalig, wenn dieser aktualisiert oder installiert wird. In einigen besonders schwierigen Fällen kann das Fehlen der Adresseinträge des Additional-Abschnitts in den Ergebnissen einer NS-Suche dazu führen, dass die Anfrage fehlschlägt.