CNAME-Record im DNS verständlich erklärt: Alias-Verknüpfungen

Der CNAME-Record (kurz für Canonical Name Record) dient im Domain Name System dazu, einen Alias-Namen für eine Domain zu erstellen. Anstatt einen Hostnamen direkt mit einer IP-Adresse zu verknüpfen, verweist ein CNAME-Record auf einen anderen Domainnamen (den sogenannten kanonischen Namen). Dies vereinfacht die Verwaltung von Subdomains und externen Webdiensten.

Während ein A-Record bzw. AAAA-Record einen Namen direkt auf eine IP-Adresse zeigt, schiebt der CNAME eine Indirektionsebene dazwischen. Das Verständnis dieser Records ist Teil der grundlegenden DNS-Hierarchie und entscheidet über Wartbarkeit und Erreichbarkeit einer Domain.

Aufbau und Syntax eines CNAME-Records

In einer DNS-Zonendatei wird der CNAME-Eintrag wie folgt definiert:

blog.example.com.      3600    IN    CNAME    ghs.googlehosted.com.

• Host/Name (blog.example.com.): Der Alias-Name, der aufgerufen wird.
• Time to Live (TTL - 3600): Die Cache-Dauer.
• Klasse (IN): Internet.
• Typ (CNAME): Identifiziert den Eintrag als Alias-Verknüpfung.
• Wert/Ziel (ghs.googlehosted.com.): Der kanonische (echte) Domainname des Zielservers.

Wichtig: Der Zielwert in einem CNAME-Record muss immer eine Domain sein, niemals eine IP-Adresse.

---

Typische Einsatzzwecke eines CNAME-Records

CNAMEs sind im Alltag allgegenwärtig, weil sie die Domainverwaltung entkoppeln. Häufige Szenarien:

Anwendungsfall	Beispiel-Alias	Ziel (kanonischer Name)
Externe Hosting-Plattform	blog.example.com	ghs.googlehosted.com
CDN-Anbindung	cdn.example.com	d111.cloudfront.net
SaaS-Dienst (z. B. Shop)	shop.example.com	shops.myshopify.com
Subdomain-Konsolidierung	mail.example.com	ghs.google.com
Domain-Validierung (ACME)	_acme-challenge.example.com	validate.ssl-provider.net

Der grosse Vorteil: Ändert der Zielanbieter seine IP-Adresse, bleibt Ihr Alias unberührt – Sie müssen nichts anpassen.

---

Die CNAME-Kollisionsregel (RFC 1912)

Ein CNAME-Record unterliegt einer strengen Restriktion: Wenn ein Hostname als CNAME definiert ist, dürfen für diesen Namen keine anderen DNS-Records (wie MX, TXT oder A-Records) existieren.

Dies hat weitreichende Konsequenzen:

• Möchten Sie für Ihre Subdomain shop.example.com einen CNAME auf einen Cloud-Hoster legen, ist das problemlos.
• Möchten Sie das gleiche für Ihre nackte Hauptdomain example.com (Root-Domain) tun, kollidiert das CNAME-Verbot mit den zwingend erforderlichen SOA- und NS-Records sowie den MX-Records für den E-Mail-Empfang. Die Domain wäre nicht mehr erreichbar.

---

Lösungen für das Root-Domain-Problem

Um eine Hauptdomain auf externe Cloud-Dienste (wie CDN-Server oder Shopify-Shops) zu leiten, gibt es zwei Lösungsansätze:

1. A-Records mit HTTP-Redirects: Auf der Root-Domain (example.com) werden klassische A-Records hinterlegt. Der Webserver auf dieser IP leitet Anfragen per HTTP-Statuscode 301 (Permanent Redirect) auf die Subdomain www.example.com um, welche wiederum einen CNAME auf den Cloud-Hoster besitzt.
2. CNAME Flattening (ALIAS / ANAME): Viele moderne DNS-Provider bieten proprietäre Einträge an. Sie erlauben die Konfiguration eines CNAME-ähnlichen Verhaltens auf der Root-Domain, indem der Nameserver die dahinterstehenden IP-Adressen in Echtzeit abfragt und als scheinbare A-Records an den Client ausliefert.

---

Typische Fehlkonfigurationen und ihre Folgen

CNAME-Fehler gehören zu den häufigsten Ursachen für nicht erreichbare Dienste und ausgefallene E-Mail-Zustellung:

Fehler	Folge	Korrektur
CNAME auf der Root-Domain (@)	Kollision mit NS/SOA/MX → Domain fällt aus	A-Record + Redirect oder CNAME Flattening
CNAME neben MX-Record am selben Host	E-Mail-Empfang bricht zusammen	CNAME entfernen, direkte Records setzen
Verkettete CNAMEs (CNAME → CNAME → …)	Höhere Latenz, Auflösungsfehler	Direkt auf den Endpunkt zeigen
Ziel endet ohne abschliessenden Punkt	Domain wird relativ ergänzt (ziel.example.com.example.com)	Vollständigen FQDN mit Punkt angeben
CNAME auf nicht existierendes Ziel (Dangling)	Subdomain-Takeover-Risiko	Verwaiste CNAMEs konsequent löschen

Besonders der letzte Punkt ist sicherheitskritisch: Ein Dangling CNAME, der auf einen aufgegebenen Cloud-Dienst zeigt, kann von Angreifern übernommen werden (Subdomain-Takeover).

---

Beispiel: korrekte Zone mit CNAMEs

Eine typische Zone kombiniert direkte Records auf der Root-Domain mit CNAME-Aliasen auf den Subdomains:

example.com.            3600  IN  A      203.0.113.10
example.com.            3600  IN  MX  10 mail.example.com.
www.example.com.        3600  IN  CNAME  example.com.
blog.example.com.       3600  IN  CNAME  ghs.googlehosted.com.
cdn.example.com.        3600  IN  CNAME  d111.cloudfront.net.
mail.example.com.       3600  IN  A      203.0.113.20

Beachten Sie: Die Root-Domain nutzt einen A-Record (kein CNAME), www zeigt per CNAME zurück auf die Root, und der MX-Record verweist auf einen Host mit eigenem A-Record – niemals auf einen CNAME.

[!TIP] Die Fehlkonfiguration von CNAMEs auf der Root-Domain ist eine der häufigsten Ursachen für nicht erreichbare E-Mail-Postfächer. Prüfen Sie die DNS-Validität Ihrer Alias-Einträge mit dem DNS Check auf balou.tools.