Zusammenfassung

  • CNAME erklärt einen Owner-Namen zum Alias auf genau ein Ziel. Damit Alias und Ziel keine widersprüchlichen Antworten liefern, darf der Owner keine gewöhnlichen A-, MX-, TXT-, NS- oder vergleichbaren Daten besitzen.
  • Ein Resolver speichert den CNAME und setzt die Suche am Ziel fort. Die Quellzone kontrolliert den Umweg, die Zielautorität die terminalen Daten; das ist weder Delegation noch Identitätsnachweis.

Zwei unvereinbare Aufgaben unter demselben Namen

Angenommen, portal.example ist ein CNAME auf service.example.net. Bei einer Adressfrage liefert der Quellserver den Alias, anschließend sucht der Resolver am Ziel nach A oder AAAA. Veröffentlichte die Quellzone zugleich einen eigenen A-Record für portal.example, müsste der Cache zwischen zwei Wahrheiten wählen: der direkten Adresse des alten Namens und der Adresse hinter dem Alias.

RFC 1034 vom November 1987 überließ diesen Konflikt nicht den Implementierungen. Der Owner eines CNAME ist der Alias; der Name im RDATA ist das kanonische Ziel. Befindet sich an einem Knoten ein CNAME, sollen dort keine anderen gewöhnlichen Daten liegen.

Das war keine Stilregel für Zonendateien. Daten des kanonischen Namens und seines Alias durften nicht auseinanderlaufen. Außerdem sollte ein Resolver einen gespeicherten CNAME verwenden können, ohne die Quellautorität erneut nach einem anderen, womöglich widersprechenden Typ zu fragen.

Die Ausschließlichkeit schuf eine schmale Autorität. Der CNAME bestimmt weder Adresse noch Mailserver. Er bestimmt, wo die Frage weitergeht.

Die Antwort veränderte die nächste Frage

Ein CNAME gibt nicht bloß eine zweite Schreibweise zurück. Ist QTYPE nicht CNAME, legt der Algorithmus aus RFC 1034 den CNAME in die Answer Section, ersetzt den Arbeits-QNAME durch das Ziel und beginnt die Suche von vorn. Eine CNAME-Abfrage folgt dem Verweis nicht, weil sie den Verweis selbst untersuchen will.

RFC 9499 unterscheidet originalen, effektiven und finalen QNAME. Der ursprüngliche Name bleibt in der Question Section sichtbar, während das tatsächlich antwortende RRset einem späteren Namen gehören kann.

Diese Trennung begrenzt negative Evidenz. Der Alias kann existieren und autoritativ beantwortet worden sein, obwohl das Ziel fehlt, gestört ist oder unter einer anderen Zone liegt. Ein NXDOMAIN am Ende beweist nicht die Nichtexistenz des ursprünglichen Alias.

Umleitung war keine Delegation

Alias und Delegation schicken Resolver weiter, übertragen aber verschiedene Befugnisse. Ein NS-RRset am Zone Cut bezeichnet die Server, die für eine untergeordnete Zone autoritativ sind. CNAME bleibt eine Aussage der Quellautorität über ihren eigenen Namen. Er löst eine neue Suche aus, übergibt aber nicht die Quellzone an den Zielbetreiber.

Die Quelle kann portal.example anlegen, ändern oder entfernen und dessen TTL wählen. Die Autorität für service.example.net kontrolliert A, AAAA und andere terminale RRsets samt eigener TTL. Ein Verweis gibt der Quelle kein Änderungsrecht am Ziel; das Ziel erhält kein Recht am Alias.

RFC 6604 klärte später Statusangaben über CNAME- und DNAME-Ketten. Eine Antwort kann für den ersten Alias autoritativ sein und zugleich eine spätere Referral oder einen Fehler enthalten. Autorität über den ersten Satz ist keine Garantie für den ganzen Weg.

Ein Ziel pro Alias heißt nicht ein Name pro Rechner

Das Wort „kanonisch“ verführte zu einer größeren Behauptung: Jeder Host oder jedes Interface dürfe nur einen offiziellen Namen haben. RFC 2181 weist diesen Schluss zurück. DNS schreibt einem Rechner keine einzelne Namensidentität vor.

Die Regel ist enger: Ein CNAME-Owner hat genau ein kanonisches Ziel. Auch die umgangssprachliche Bezeichnung des Owners als „CNAME“ verwischt die Richtung. Der Owner ist der Alias, der Record-Wert ist der kanonische Name dieser Beziehung.

Mehrere Domainnamen dürfen zum selben Dienst führen. Ein Nicht-Alias kann verschiedene gewöhnliche RRsets besitzen. Verboten ist nur, dass derselbe Owner gleichzeitig „frage anderswo weiter“ sagt und sich als eigenständiges Ziel ausgibt.

Warum der Zonen-Apex die Abkürzung nicht nehmen konnte

Ein Zonen-Apex braucht SOA und NS. Weil ein CNAME-Owner nicht mit diesen gewöhnlichen Daten koexistieren darf, kann der Apex kein normaler CNAME sein. RFC 1912 hielt die Gefahr in einem historischen BIND-Beispiel fest: CNAME neben den Apex-NS konnte dazu führen, dass der Server die übrigen Ressourcen ignorierte und selbst Namen unterhalb der Zone unsichtbar wurden.

Das genaue Verhalten gehörte zu damaligen Versionen; der Widerspruch gehört zum Datenmodell. Anbieter können am Apex Adressantworten synthetisieren oder Flattening anbieten. Das mag nützlich sein, ist aber kein gewöhnlicher CNAME RR auf dem Draht. Wer beides gleich nennt, verliert beim Ausfall die Grenzen von Autorität und Cache aus dem Blick.

NS und MX durften ihre nächste Adresse nicht hinter einem Alias verstecken

RFC 2181 verbietet Aliase auch als NS-Target oder MX-Exchange. Bei NS- und MX-Antworten kann der Server passende Adressen in Additional mitliefern. Diese Verarbeitung verfolgt keinen CNAME, um anschließend Adressen des kanonischen Ziels anzuhängen.

Ein Alias an solchen Stellen verursacht zusätzliche Anfragen und Last; in schwierigen Delegationsfällen kann die fehlende Adresse die Auflösung verhindern. Der Administrator soll den Alias einmal auflösen und direkt den Namen veröffentlichen, der die Adress-RRsets besitzt.

Das ist kein allgemeines Verbot von Namensverweisen. Geschützt werden Positionen, an denen vorhersehbare Adressfindung zum Funktionspfad gehört.

DNSSEC fügte Beweise hinzu, nicht ein zweites Ziel

„Keine anderen Daten“ erhielt mit DNSSEC eine notwendige Ausnahme. RFC 2181 erlaubte die damaligen Sicherheitsrecords; RFC 4034 verlangt RRSIG und NSEC am CNAME-Owner einer signierten Zone.

Diese Records konkurrieren nicht mit dem Ziel. RRSIG authentisiert das CNAME-RRset, NSEC unterstützt authentisierte Verneinung und Typenevidenz. Sie beweisen den Zustand des Alias-Knotens, ohne ihm eine eigene Adresse, Mailroute oder Anwendungsnutzlast zu geben.

RFC 4033 begrenzt auch die Sicherheitsbehauptung. DNSSEC liefert bei erfolgreicher Validierung Datenursprungsauthentisierung, Integrität und authentisierte Verneinung. Es zertifiziert weder Dienstgesundheit noch Unternehmen, Vertrag oder rechtliches Eigentum am Quellnamen.

Ketten waren erlaubt, Schleifen nicht

Ein Alias kann auf einen weiteren Alias zeigen. RFC 1034 rät aus Effizienzgründen von vielen Ebenen ab, erklärt aber eine endliche Kette nicht zum Fehler. Resolver müssen Schleifen und Ketten erkennen, die bei einem nicht existierenden Namen enden.

Das Betriebsobjekt ist daher ein Graph. Jede Kante besitzt Owner, Autorität, TTL und womöglich DNSSEC-Status; das terminale RRset hat seine eigene Lebensdauer. Zwei Caches können verschiedene Phasen derselben Umstellung zeigen, weil alte Kanten nicht gleichzeitig verfallen.

Diese Entkopplung ist wertvoll. Die Quelle verschiebt einen vertrauten Namen, ohne Zieldaten zu kopieren. Das Ziel ändert Adressen, ohne jede verweisende Zone zu bearbeiten. Der Preis sind unabhängige Änderungen, während Caches frühere Aussagen bis zum TTL-Ende bewahren.

Minimale Koordination brauchte unvermischte Wahrheit

CNAME löste verteilte Wartung mit einem absichtlich dünnen Mechanismus. Weder ein Weltregister äquivalenter Namen noch ein zentraler Richter über die „wahre“ Alias-Adresse war nötig. Eine eindeutige Kante genügte, die jeder Resolver speichern und verfolgen konnte.

Die Ausschließlichkeitsregel ist das institutionelle Zentrum. Der Quellname kann Umweg oder Ziel sein, nicht beides. Wählt er den Umweg, bleibt seine Autorität real und eng: ein Ziel veröffentlichen, die Evidenz der Kette erhalten und die terminalen Daten ihrer eigenen Autorität überlassen.

Quellen und Grenzen

Ursprungsmodell und Algorithmus stammen aus RFC 1034 und RFC 1035, Betriebsfehler und Klarstellungen aus RFC 1912 und RFC 2181, DNSSEC-Ausnahmen aus RFC 4033 und RFC 4034, Kettenstatus und Terminologie aus RFC 6604 und RFC 9499. Diese Texte belegen weder heutige Verbreitung noch anbieterspezifisches Flattening, moderne Kettenlimits, Häufigkeit verwaister Aliase, Anwendungseigentum oder aktuelle Verfügbarkeit.