CNAME-Eintrag: wann er passt und wann nicht

Ein CNAME-Eintrag (Canonical Name) sagt: Dieser Name ist nur ein Alias, die eigentlichen Daten stehen unter einem anderen Namen. Trifft ein Resolver auf einen CNAME, merkt er sich den Eintrag, ersetzt den gesuchten Namen durch das Ziel und stellt seine Frage dort neu ^[1]. Das ist praktisch, weil du die Adresse eines Dienstes nicht selbst pflegen musst. Es hat aber Regeln, die oft erst auffallen, wenn ein Eintrag sich nicht speichern lässt oder Mails plötzlich nicht mehr ankommen.

So arbeitet ein CNAME-Eintrag

Im Datenteil eines CNAME steht nach RFC 1035 der "kanonische" Name, also der Name, unter dem die echten Einträge liegen. Der Name, für den du den CNAME anlegst, ist der Alias ^[2]. Ein einfaches Beispiel aus einer Zone:

Fragt ein Browser nach www.beispiel.de, bekommt sein Resolver zuerst den CNAME und danach die IPv4-Adresse von beispiel.de. Bei blog.beispiel.de liegt die Adresse beim Anbieter des Blogs. Ändert der Anbieter seine Server, bleibt dein Eintrag gleich. Ketten aus mehreren CNAMEs sind erlaubt und werden verfolgt; eine Schleife, in der zwei Namen aufeinander zeigen, gilt als Fehler ^[1]. Wie die übrigen Typen zusammenspielen, steht im Überblick über die DNS-Einträge.

Wann ein CNAME passt

Ein CNAME ist die richtige Wahl, wenn eine Subdomain auf einen Dienst zeigen soll, dessen Adressen ein anderer verwaltet. Typische Fälle sind eine Website bei einem Baukasten- oder Hosting-Dienst, ein Onlineshop auf einer Plattform, ein CDN oder eine Dokumentation bei einem externen Anbieter. GitHub Pages etwa verlangt für eine eigene Subdomain einen CNAME, der auf die Standardadresse der Seite unter github.io zeigt ^[7].

• www als Alias für die Hauptdomain, damit du die IP-Adresse nur an einer Stelle pflegst.
• Subdomains wie shop, blog oder hilfe, die bei einem externen Dienst laufen.
• Mehrere Namen, die auf denselben Server zeigen sollen, etwa alte Projektnamen.

Weniger sinnvoll ist ein CNAME, wenn du den Server selbst betreibst und seine IP-Adresse kennst. Dann sparst du mit einem A-Eintrag (und einem AAAA-Eintrag für IPv6) den Umweg über einen zweiten Namen, und unter dem Namen bleiben weitere Einträge möglich. Auch für eine Subdomain, die eigene E-Mail empfangen oder per TXT-Eintrag bei einem Dienst bestätigt werden soll, sind Adresseinträge die bessere Wahl. Den Grund liefert die Regel im nächsten Abschnitt. Als Faustregel gilt: Gehört dir das Ziel, nimm Adressen; gehört es einem Dienst, der seine Adressen selbst ändert, nimm den CNAME.

Wie du eine Subdomain anlegst und danach Webserver und Zertifikat einrichtest, erklärt die Anleitung Subdomain einrichten.

Neben einem CNAME steht nichts anderes

Die wichtigste Regel: Hat ein Name einen CNAME, darf er keine weiteren Daten haben. RFC 1034 formuliert das schon 1987 ^[1], RFC 2181 hat es 1997 verschärft: Ein Alias darf außer DNSSEC-Einträgen nichts anderes tragen ^[3]. Der Grund ist einfach. Ein Resolver, der einen CNAME im Cache hat, soll ihn für jede Art von Anfrage verwenden können, ohne nachsehen zu müssen, ob es unter dem Namen doch noch einen MX oder TXT gibt ^[1].

Für die Praxis heißt das: Willst du für shop.beispiel.de einen CNAME setzen, kannst du unter genau diesem Namen keinen TXT-Eintrag zur Bestätigung bei einem Dienst und keinen MX für E-Mail anlegen. Viele DNS-Oberflächen lehnen das Speichern dann ab. Wer die Mail einer Subdomain empfangen will, braucht dort A- oder AAAA-Einträge statt eines CNAME.

Warum die Hauptdomain keinen CNAME bekommt

An der Spitze jeder Zone, also bei beispiel.de selbst, stehen immer die NS-Einträge mit den zuständigen Nameservern und genau ein SOA-Eintrag mit den Verwaltungsdaten der Zone ^[1]. Weil neben einem CNAME nichts stehen darf, kollidiert ein CNAME auf der Hauptdomain zwangsläufig mit diesen Pflichteinträgen. Amazon Route 53 lässt ihn deshalb gar nicht erst zu, weder für eine Domain noch für eine Zone, die selbst eine Subdomain ist ^[5].

Das Problem entsteht oft, wenn ein Dienst nur einen Hostnamen nennt und keine feste IP-Adresse. Für www ist das kein Hindernis, für beispiel.de ohne Präfix schon. GitHub Pages bietet deshalb für die Hauptdomain wahlweise A-Einträge mit festen Adressen oder einen ALIAS- beziehungsweise ANAME-Eintrag an ^[7].

Auswege: Flattening, ALIAS und HTTPS-Eintrag

Mehrere DNS-Anbieter haben eigene Lösungen gebaut, die sich in der Zone wie ein CNAME eintragen lassen, nach außen aber Adressen liefern.

CNAME-Flattening

Cloudflare löst einen CNAME auf der Hauptdomain selbst auf, folgt dabei auch weiteren CNAMEs und gibt am Ende die IP-Adresse statt des CNAME zurück ^[4]. Für einen CNAME auf der Hauptdomain geschieht das laut Cloudflare in allen Tarifen automatisch; alle CNAMEs einer Zone zu "flatten", ist nur in bezahlten Tarifen möglich ^[4]. Mehr zum Anbieter steht im Profil Cloudflare.

ALIAS-Einträge

Route 53 kennt Alias-Einträge, die nur innerhalb von AWS funktionieren. Sie zeigen auf Dienste wie CloudFront oder S3 oder auf einen anderen Eintrag derselben Zone und dürfen auf der Hauptdomain stehen. In dig oder nslookup erscheinen sie als A oder AAAA, nicht als CNAME ^[5]. Andere Anbieter nennen ähnliche Lösungen ALIAS oder ANAME ^[7]. Das sind keine Standardtypen; ziehst du mit der Zone zu einem anderen Anbieter um, musst du sie neu anlegen.

HTTPS- und SVCB-Einträge

Seit November 2023 gibt es mit RFC 9460 einen standardisierten Weg. Der HTTPS-Eintrag hat einen AliasMode, dessen Hauptzweck die RFC so beschreibt: Er soll Aliase an der Spitze der Zone ermöglichen, wo ein CNAME nicht erlaubt ist ^[6]. Ältere Programme kennen den Eintrag nicht und ignorieren ihn. Deshalb bleiben A- und AAAA-Einträge auf der Hauptdomain als Rückfall nötig ^[6].

MX und NS dürfen nicht auf einen Alias zeigen

Ein zweiter Stolperstein betrifft die Gegenrichtung. Der Zielname eines MX- oder NS-Eintrags darf kein Alias sein. RFC 2181 sagt ausdrücklich, dass ein solcher Name zwar Adressen und andere Daten haben darf, aber nie einen CNAME ^[3]. Wenn dein Mailanbieter also mail.anbieter.example nennt, trägst du diesen Namen als MX-Ziel ein und legst nicht zuerst einen eigenen CNAME mx.beispiel.de an, auf den der MX dann zeigt. Wie der MX richtig gesetzt wird, steht unter MX-Eintrag einrichten.

Vergessene CNAMEs als Sicherheitsrisiko

Ein CNAME, dessen Ziel nicht mehr existiert, kann eine Subdomain angreifbar machen. Microsoft beschreibt den Ablauf so: Ein Dienst wird gelöscht, der CNAME bleibt in der Zone, und ein Angreifer legt beim selben Anbieter einen Dienst mit dem alten Zielnamen an. Danach landet der Verkehr deiner Subdomain bei ihm ^[8]. Microsoft nennt CNAME-Einträge dabei als besonders anfällig. Mit der übernommenen Subdomain kann der Angreifer ein gültiges Zertifikat beantragen und Cookies abgreifen, die für alle Subdomains gelten ^[8].

Die Gegenmaßnahme ist organisatorisch: Wer einen Dienst abschaltet, löscht im selben Arbeitsgang den passenden DNS-Eintrag. Microsoft empfiehlt, die Zone regelmäßig daraufhin zu prüfen, ob jedes Ziel noch existiert und dir gehört ^[8]. GitHub rät außerdem von Wildcard-Einträgen wie *.beispiel.de ab, weil sie ein unmittelbares Übernahmerisiko schaffen ^[7]. Allgemeine Hinweise zu Zugängen und Pflege einer Website stehen auf webseite.domain-root.de.

Was eine CNAME-Kette kostet

Jeder CNAME bedeutet für den Resolver eine zusätzliche Abfrage, sofern er das Ziel nicht schon im Cache hat ^[1]. Route 53 rechnet einen CNAME auf einen anderen Eintrag in Route 53 deshalb als zwei Abfragen ab ^[5]. Bei einer Kette aus mehreren CNAMEs summiert sich das beim ersten Aufruf. Danach greifen die Caches für die Dauer der jeweiligen TTL. Wie lange das ist, erklärt der Beitrag TTL bei DNS.

CNAME prüfen

Ob ein CNAME richtig gesetzt ist, siehst du mit dem DNS-Check oder mit dig und nslookup. Fragst du ausdrücklich nach dem Typ CNAME, zeigt dir der Resolver nur den Alias selbst ^[1]. Fragst du nach A oder AAAA, siehst du die ganze Kette bis zur Adresse. Achte bei der Prüfung auf drei Dinge:

• Das Ziel des CNAME löst sich zu einer Adresse auf und gehört dem Dienst, den du meinst.
• Unter dem Namen stehen keine weiteren Einträge außer DNSSEC-Daten.
• Kein MX- oder NS-Eintrag deiner Zone zeigt auf den Alias.

1. Gesetz RFC 1034: Domain Names, Concepts and Facilities. IETF. Stand November 1987. abgerufen am 29.10.2026
2. Gesetz RFC 1035: Domain Names, Implementation and Specification. IETF. Stand November 1987. abgerufen am 29.10.2026
3. Gesetz RFC 2181: Clarifications to the DNS Specification. IETF. Stand Juli 1997. abgerufen am 29.10.2026
4. Organisation CNAME flattening und Set up CNAME flattening. Cloudflare. Stand 2026. abgerufen am 29.10.2026
5. Organisation Choosing between alias and non-alias records. Amazon Web Services. Stand 2026. abgerufen am 29.10.2026
6. Gesetz RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records). IETF. Stand November 2023. abgerufen am 29.10.2026
7. Organisation Managing a custom domain for your GitHub Pages site. GitHub. Stand 2026. abgerufen am 29.10.2026
8. Organisation Prevent dangling DNS entries and avoid subdomain takeover. Microsoft. Stand 24.07.2026. abgerufen am 29.10.2026

Zuletzt geprüft am 29.10.2026, nächste Prüfung spätestens im Oktober 2027. Fehler entdeckt? Schreib uns.