10. Naming issues (Benennungsprobleme)
Es wurde manchmal aus einigen Abschnitten der DNS-Spezifikation [RFC1034, RFC1035] abgeleitet, dass ein Host oder vielleicht eine Schnittstelle eines Hosts genau einen autoritativen oder offiziellen Namen hat, den kanonischen Namen genannt. Es gibt keine solche Anforderung im DNS.
10.1. CNAME resource records (CNAME-Ressourceneinträge)
Der DNS-CNAME-Eintrag („kanonischer Name", canonical name) existiert, um den mit einem Aliasnamen verbundenen kanonischen Namen bereitzustellen. Es kann nur einen solchen kanonischen Namen für einen bestimmten Alias geben. Dieser Name sollte im Allgemeinen ein Name sein, der anderswo im DNS existiert, obwohl es einige seltene Anwendungen für Aliase mit begleitendem kanonischem Namen gibt, der im DNS nicht definiert ist. Ein Aliasname (das Label eines CNAME-Eintrags) kann, wenn DNSSEC verwendet wird, SIG-, NXT- und KEY-RRs haben, darf aber keine anderen Daten haben. Das heißt, für jedes Label im DNS (jeden Domainnamen) gilt genau eine der folgenden Aussagen:
- 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 zugehörigen RRs irgendeines Typs
- Der Name existiert überhaupt nicht
10.1.1. CNAME terminology (CNAME-Terminologie)
Es ist traditionell, das Label eines CNAME-Eintrags als „ein CNAME" zu bezeichnen. Dies ist unglücklich, da „CNAME" eine Abkürzung für „kanonischer Name" (canonical name) ist, und das Label eines CNAME-Eintrags ist sicherlich kein kanonischer Name. Es ist jedoch ein fest verwurzelter Gebrauch. Daher muss sehr darauf geachtet werden, sehr klar zu sein, ob das Label oder der Wert (der kanonische Name) eines CNAME-Ressourceneintrags gemeint ist. In diesem Dokument wird das Label eines CNAME-Ressourceneintrags immer als Alias bezeichnet.
10.2. PTR records (PTR-Einträge)
Verwirrung über kanonische Namen hat zu der Überzeugung geführt, dass ein PTR-Eintrag genau einen RR in seinem RRSet haben sollte. Dies ist nicht korrekt, der relevante 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. Es gibt in diesem Abschnitt keine Andeutung, dass nur ein PTR-Eintrag für einen Namen erlaubt ist. Eine solche Einschränkung sollte nicht gefolgert werden.
Beachten Sie, dass, obwohl der Wert eines PTR-Eintrags kein Alias sein darf, es keine Anforderung gibt, dass der Prozess der Auflösung eines PTR-Eintrags keine Aliase trifft. Das Label, das für einen PTR-Wert gesucht wird, könnte einen CNAME-Eintrag haben. Das heißt, es könnte ein Alias sein. Der Wert dieses CNAME-RR, wenn er kein weiterer Alias ist, was er nicht sein sollte, gibt den Ort an, an dem der PTR-Eintrag gefunden wird. Dieser Eintrag gibt das Ergebnis der PTR-Typ-Suche. Dieses Endergebnis, der Wert des PTR-RR, ist das Label, das kein Alias sein darf.
10.3. MX and NS records (MX- und NS-Einträge)
Der als Wert eines NS-Ressourceneintrags verwendete Domainname oder Teil des Werts eines MX-Ressourceneintrags darf kein Alias sein. Nicht nur ist die Spezifikation in diesem Punkt klar, sondern die Verwendung eines Alias in einer dieser Positionen funktioniert weder so gut wie erhofft noch erfüllt sie gut die Ambition, die zu diesem Ansatz geführt haben könnte. Dieser Domainname muss als Wert einen oder mehrere Adresseinträge haben. Derzeit sind dies A-Einträge, aber in Zukunft könnten andere Eintragstypen, die Adressinformationen liefern, akzeptabel sein. Er kann auch andere RRs haben, aber niemals einen CNAME-RR.
Die Suche nach NS- oder MX-Einträgen verursacht „zusätzliche Abschnittsverarbeitung" (additional section processing), bei der Adresseinträge, die mit dem Wert des gesuchten Eintrags verbunden sind, der Antwort hinzugefügt werden. Dies hilft, unnötige zusätzliche Abfragen zu vermeiden, die leicht vorhersehbar sind, wenn die erste gestellt wird.
Die zusätzliche Abschnittsverarbeitung umfasst keine CNAME-Einträge, geschweige denn die Adresseinträge, die möglicherweise mit dem vom Alias abgeleiteten kanonischen Namen verbunden sind. Wenn also ein Alias als Wert eines NS- oder MX-Eintrags verwendet wird, wird keine Adresse mit dem NS- oder MX-Wert zurückgegeben. Dies kann bei jeder Abfrage zusätzliche Abfragen und zusätzliche Netzwerklast verursachen. Es ist für den DNS-Administrator trivial, dies zu vermeiden, indem der Alias aufgelöst und der kanonische Name direkt in den betroffenen Eintrag eingefügt wird, einmal wenn er aktualisiert oder installiert wird. In einigen besonderen schwierigen Fällen kann das Fehlen der zusätzlichen Abschnittsadresseinträge in den Ergebnissen einer NS-Suche dazu führen, dass die Anfrage fehlschlägt.