Ein CNAME-Record erstellt einen Alias. Er verknüpft einen Domainnamen mit einem anderen Namen. Der Resolver folgt dann diesem Zielnamen, um A- oder AAAA-Records zu finden. Der Browser erhält dann die Serveradresse durch diese Verkettung.
Ein CNAME-Record enthält einen Namen, einen Typ, ein Ziel und eine TTL. Die TTL gibt an, wie lange die Antwort im lokalen Resolver-Cache verbleibt.
| Name | Typ | Ziel | TTL in Sekunden |
|---|
| www | CNAME | hoster.beispiel.net. | 3600 |
In diesem Beispiel ist der Name www ein Alias. Das Ziel ist ein anderer Domainname. Dieser Zielname muss A- oder AAAA-Records veröffentlichen, um eine Adresse zu liefern. Die TTL von 3600 entspricht einer Stunde.
Ein Name kann nicht mehrere CNAME-Records haben. Ein CNAME koexistiert nicht mit anderen Records am selben Ort. Keine A-, AAAA-, MX- oder TXT-Records auf demselben Label. Der CNAME muss allein stehen.
Eine kurze TTL beschleunigt die Sichtbarkeit einer Zieländerung. Nützlich während einer Migration zu einem neuen Anbieter.
Eine mittlere oder lange TTL reduziert Anfragen an die autoritativen Server. Geeignet für einen stabilen Dienst.
Es wird empfohlen, die TTL einige Stunden vor einer Umschaltung zu reduzieren und sie dann wieder zu erhöhen, wenn alles stabil ist.
Gut zu wissen
Ein CNAME kann eine Kette zu einem anderen CNAME erstellen. Das funktioniert, aber jeder Sprung fügt eine kleine Verzögerung hinzu. Es ist besser, direkt auf den finalen Namen zu zielen, wenn möglich.
An der Wurzel eines Domainnamens, die man Apex nennt, vermeidet man den CNAME, da der Apex bereits SOA und NS veröffentlichen muss. Anbieter bieten eine äquivalente Funktion namens Flattening oder ALIAS an.
Für www ist ein CNAME oft praktisch, wenn das Ziel von einem Anbieter verwaltet wird. Für api, für cdn, für static hält ein CNAME die Architektur flexibel. Das Ziel ändert sich, ohne den ursprünglichen Namen zu berühren.
Zu vermeiden
CNAME am selben Ort wie ein A, AAAA, MX oder TXT zu setzen ist nicht konform.
Einen CNAME am Apex ohne dedizierte Funktion des Anbieters zu verwenden.
Einen MX-Record auf einen Namen zu zeigen, der selbst ein CNAME ist. Der MX muss auf einen Namen zeigen, der A oder AAAA veröffentlicht.
Ein DNS-Lookup online ermöglicht es, einen Namen einzugeben. Man erhält das CNAME-Ziel und die vom Internet aus sichtbare TTL. Das ist eine erste nützliche Kontrolle. Danach einen lokalen Test von seinem Rechner aus durchführen.
Windows stellt nslookup zur Verfügung. Man kann es im interaktiven Modus verwenden.
nslookup
set q=cname
www.beispiel.com
nslookup
set q=cname
server 1.1.1.1
www.beispiel.com
Der erste Teil fragt entsprechend der Netzwerkkonfiguration des Rechners ab. Der zweite Teil erzwingt die Nutzung eines Drittanbieter-Resolvers, hier den von Cloudflare.
Auf diesen Systemen ist der dig-Befehl praktisch und einfach zu verwenden.
dig CNAME www.beispiel.com
dig CNAME www.beispiel.com @1.1.1.1
Eine Antwort, die einen CNAME zeigt, gibt den Zielnamen an. Man muss dann überprüfen, dass dieser Zielname tatsächlich A oder AAAA veröffentlicht.
Eine verbleibende hohe TTL kann eine Verzögerung nach einer Zieländerung erklären.
Eine zu lange CNAME-Kette kann eine Verzögerung verursachen. Die Kette reduzieren, wenn möglich.
- Das finale Ziel vorbereiten, das A oder AAAA veröffentlicht.
- Die TTL des CNAME auf 300 oder sogar 60 Sekunden einige Stunden vor der Umschaltung reduzieren.
- Das CNAME-Ziel zum geplanten Zeitpunkt ändern.
- Mit nslookup oder mit dem dig-Befehl von mehreren Netzwerken aus überprüfen.
- Die TTL auf einen komfortablen Wert erhöhen, wenn alles stabil ist.
Praktischer Tipp
Das aktuelle Ziel und das geplante Ziel vor jeder Änderung notieren. Datum, TTL und Grund der Änderung aufbewahren. Diese Spur vermeidet Verwirrungen und beschleunigt einen Rückschritt bei Bedarf.
www als CNAME auf den vom CDN bereitgestellten Namen definieren. A- und AAAA-Records am Apex beibehalten, wenn die Plattform ein CNAME-Äquivalent an der Wurzel anbietet.
Für einen von einem Dritten verwalteten Dienst wie transaktionale E-Mails oder Analysen ermöglicht ein CNAME die Delegation der Auflösung ohne Veröffentlichung einer Adresse.
Preprod als CNAME auf einen separaten Hosting-Namen zeigen. Einfache Umschaltung durch Änderung des Ziels, wenn die Version validiert ist.
- Wenn die Website nicht antwortet, zuerst überprüfen, dass der CNAME auf den richtigen Namen zeigt.
- Überprüfen, dass das Ziel A oder AAAA veröffentlicht. Ohne das liefert die Auflösung keine Adresse.
- Wenn ein Dienst die Infrastruktur ändert, das Ziel aktualisieren. Unnötige Ketten vermeiden.
- Wenn die Antwort alt bleibt, den Ablauf der TTL abwarten und den Cache des lokalen Resolvers wenn möglich löschen.
Zusammenfassend erstellt ein CNAME-Record einen Alias zwischen zwei Namen. Der Resolver folgt dem Ziel, um A- oder AAAA-Records zu erhalten. Ein CNAME muss am selben Ort allein stehen. Man vermeidet CNAME am Apex außer mit einer dedizierten Funktion des Anbieters. Die Überprüfung erfolgt über ein Online-Tool, dann über nslookup und dig.
Mit diesen Orientierungspunkten bleibt die Verwaltung klar. Änderungen verlaufen stressfrei. Besucher greifen ohne Zwischenfälle auf die Website zu.