CNAME oder A-Record: Was wann, und die Apex-Regel

Was ein A-Record und ein CNAME tatsächlich tun

Beide Einträge beantworten dieselbe Frage – wohin zeigt dieser Name? – aber sie beantworten sie mit unterschiedlicher Art von Information, und dieser einzige Unterschied erklärt alle Regeln, die danach kommen.

Ein A-Record verweist einen Namen direkt auf eine IPv4-Adresse. example.com → 203.0.113.10. Damit endet die Kette: der Resolver hat, was er braucht, und hört auf. (Das IPv6-Gegenstück ist der AAAA-Record, und alles in diesem Leitfaden gilt für ihn genauso.)

Ein CNAME-Record verweist einen Namen auf einen anderen Namen. www.example.com → example.com, oder shop.example.com → meinshop.meinanbieter.net. Der Resolver bekommt keine Adresse, sondern einen zweiten Namen, den er nun nachschlagen muss. CNAME steht für „canonical name“, und der Eintrag liest sich am besten als Satz: der eigentliche Name dafür liegt dort, frag stattdessen nach jenem.

Genau diese Weiterleitung ist der Sinn der Sache. Wenn das, worauf Sie zeigen, irgendwann seine IP-Adresse wechselt, funktioniert ein CNAME weiter, ohne dass Sie etwas anfassen – weil Sie die Adresse nie aufgeschrieben haben.

Der Unterschied, auf den es ankommt

In der Praxis läuft die Wahl auf eine Frage hinaus: Wem gehört die Adresse?

• Ihnen – ein Server, ein VPS, ein Load Balancer mit fester IP, die Sie kontrollieren. Nehmen Sie einen A-Record. Sie kennen die Adresse, sie ändert sich nicht ohne Ihr Wissen, und eine direkte Antwort ist die schnellste.
• Jemand anderem – eine Hosting-Plattform, ein CDN, ein Shop-Baukasten, ein Formular- oder Statusseiten-Dienst. Nehmen Sie einen CNAME. Deren Adressen ändern sich, oft stillschweigend und ohne Ankündigung, und ein CNAME macht deren Änderung nicht zu Ihrem Ausfall.

Deshalb verlangt die Einrichtungsseite jeder Plattform einen CNAME statt Ihnen eine IP zu geben. Das ist keine Konvention, sondern der Vorbehalt, umziehen zu dürfen. Wer deren aktuelle IP in einen A-Record schreibt, hat sich stillschweigend aus deren Wartungsfenster ausgeklinkt.

Es gibt noch einen strukturellen Unterschied, und über den stolpern viele: ein Name mit einem CNAME darf keinen weiteren Eintrag haben. Der Standard ist da eindeutig. Ist www.example.com ein CNAME, kann er nicht zusätzlich einen TXT-, MX- oder A-Record tragen. Die meisten Anbieter weigern sich, den zweiten Eintrag zu speichern, manche nehmen ihn an und verhalten sich dann einfach unvorhersehbar – eine ausgesprochen unangenehme Art, einen Nachmittag zu verbringen.

Warum der Apex kein CNAME sein kann

Der Apex – auch Root, Zone-Apex oder nackte Domain genannt – ist example.com ohne etwas davor. Und er ist der einzige Name in Ihrer Zone, der kein CNAME sein kann. Das ist keine Einschränkung, die Ihr Anbieter sich ausgedacht hat, sondern folgt aus der Regel oben.

Ihr Apex trägt bereits Einträge, die existieren müssen, damit die Domain überhaupt funktioniert: die NS-Records, die Ihre autoritativen Nameserver benennen, und den SOA-Record, der die Zone beschreibt. Die liegen per Definition am Apex. Da ein CNAME jeden weiteren Eintrag auf demselben Namen verbietet und der Apex NS und SOA tragen muss, ist ein CNAME am Apex ein Widerspruch. Ein standardkonformer DNS-Server liefert ihn nicht aus.

Das hat eine praktische Folge, die man im schlechtesten Moment entdeckt. Auch Ihre MX-Records liegen am Apex. Lässt ein Anbieter Sie dort je einen CNAME erzwingen, haben Sie nicht nur Ihre Website umgehängt, sondern Ihre E-Mail in einen undefinierten Zustand gebracht: der Name behauptet nun, seinen kanonischen Namen anderswo zu haben, und muss gleichzeitig MX-Anfragen beantworten.

Was stattdessen an den Apex gehört

Es gibt vier brauchbare Antworten, etwa in der Reihenfolge, in der Sie sie bevorzugen sollten.

Nehmen Sie den Alias-Eintrag Ihres Anbieters

Die meisten modernen DNS-Anbieter haben einen Eintragstyp, der sich wie ein CNAME verhält, am Apex aber zulässig ist: ALIAS, ANAME oder Cloudflares CNAME-Flattening. Die Namen unterscheiden sich, der Mechanismus ist derselbe: der Nameserver löst das Ziel selbst auf und antwortet mit dem sich ergebenden A-Record. Die Außenwelt sieht einen völlig gewöhnlichen A-Record, es wird also keine Regel gebrochen – und Sie haben die IP trotzdem nicht aufgeschrieben.

Das ist die richtige Antwort, wann immer Ihr Anbieter sie anbietet. Der Haken: es ist eine Funktion des Anbieters, nicht des DNS. Ziehen Sie die Zone zu einem Anbieter ohne diese Funktion, kommt der Eintrag nicht mit.

Leiten Sie den Apex auf www weiter

Legen Sie die eigentliche Seite per CNAME auf www – völlig zulässig – und machen Sie aus dem Apex eine Weiterleitung dorthin. Viele Registrare und alle CDNs bieten das als Einzeileneinstellung an, meist Domain-Weiterleitung oder Redirect-Regel genannt. Sie bekommen einen saubereren CNAME an der entscheidenden Stelle und einen kanonischen Hostnamen, was ohnehin gut für SEO ist.

Der Preis ist kosmetisch: in Ihrer sichtbaren URL steht ein www., und manche haben dazu eine feste Meinung.

Nehmen Sie einen A-Record – bewusst

Veröffentlicht die Plattform eine feste IP-Adresse und sagt sie schriftlich zu, ist ein A-Record am Apex in Ordnung. Das entscheidende Wort ist „zusagt“. Eine IP, die Sie durch Anpingen ihres CNAME-Ziels gefunden haben, ist keine Zusage, sondern eine Momentaufnahme – und sie wird sich ändern.

Wenn Sie das tun, senken Sie die TTL des Eintrags vor jeder geplanten Migration, damit Sie nicht auf Caches warten, wenn die Adresse wirklich wechselt.

Prüfen Sie, was tatsächlich eingetragen ist

Bevor Sie etwas ändern, schauen Sie sich den tatsächlichen Zustand der Zone an, statt der Übersicht im Kontrollpanel zu vertrauen. Fragen Sie Apex und www getrennt ab und vergleichen: Sie wollen wissen, ob jeder mit einem A-Record oder einem CNAME antwortet und ob dort schon etwas Unerwartetes liegt. Ein kostenloses DNS-Abfrage-Tool zeigt Eintragstyp, Wert und verbleibende TTL je Zeile.

Wann ein CNAME die richtige Wahl ist

Greifen Sie zum CNAME, sobald das Ziel ein Name ist, den Sie nicht kontrollieren:

• Subdomains, die auf eine Plattform zeigen – shop, docs, status, blog, hilfe auf einen gehosteten Dienst. Das ist mit Abstand der häufigste korrekte Einsatz.
• Ein CDN vor Ihrem Origin, wenn das CDN Ihnen einen Hostnamen wie d1234.cloudfront.net gibt.
• Verifizierungs- und Dienst-Einträge, die ein Anbieter als CNAME anlegen lässt, oft mit einem langen, zufälligen Label.
• www im Gleichschritt mit dem Apex halten, damit eine Änderung beide aktualisiert.

In allen vier Fällen ist der Nutzen derselbe: der Anbieter kann seine Infrastruktur ändern, und Ihr DNS funktioniert unangetastet weiter.

Wann ein A-Record die richtige Wahl ist

Ein A-Record ist richtig, wenn die Adresse Ihnen gehört:

• Ihr eigener Server oder VPS mit fester IP.
• Der Apex, wenn kein Alias-Eintrag verfügbar ist und die Plattform eine stabile IP veröffentlicht.
• Ein Load Balancer, den Ihr Anbieter Ihnen als Adresse und nicht als Hostnamen gibt.
• Infrastruktur-Hosts – ein Mailserver, der in einem MX-Record genannt wird, muss sich etwa über A oder AAAA auflösen. Ein MX-Record darf nicht auf einen CNAME zeigen, und Mailserver lehnen das ab.

Letzteres erwischt alle, die ihre E-Mail migrieren. mail.example.com als CNAME sieht harmlos aus und bricht die Zustellung auf Weisen, die mühsam zu diagnostizieren sind.

Die zusätzliche Abfrage und die zweite TTL

Ein CNAME kostet einen Schritt mehr. Der Resolver fragt nach Ihrem Namen, bekommt „frag nach diesem anderen Namen“ und fragt erneut. In der Praxis sind das wenige Millisekunden und fast immer aus dem Cache, also kein Grund, CNAMEs zu meiden – aber zwei Folgen sollte man kennen.

Erstens fügt eine CNAME-Kette, die auf einen weiteren CNAME zeigt, der auf einen weiteren zeigt, jedes Mal einen Schritt hinzu. Zwei Glieder sind normal; eine lange Kette ist ein Latenzproblem und eine fragile Abhängigkeit, denn bricht irgendein Glied, ist Ihr Name weg.

Zweitens bringt ein CNAME eine zweite TTL mit. Der Resolver speichert Ihren CNAME mit Ihrer TTL und den Eintrag des Ziels mit der TTL des Ziels, jeweils mit eigenem Countdown. Ihre echte Wartezeit bei einer Änderung ist die längere der beiden – darum kann ein CNAME auf einen Anbieter mit langer TTL hinter Ihrer eigenen Einstellung zurückbleiben, so niedrig Sie sie auch setzen. Wenn Sie eine Änderung planen, erklärt wie TTL und Propagation wirklich funktionieren die Abfolge, die Ausfälle vermeidet.

Häufige Fehler

• Einen CNAME am Apex erzwingen, weil die Oberfläche des Anbieters es zuließ. Das bringt Ihre MX-Records – Ihre E-Mail – in undefiniertes Verhalten.
• Einen TXT- oder MX-Record zu einem Namen hinzufügen, der schon ein CNAME ist. Nicht zulässig, und die Anbieter sind sich uneins, wie sie scheitern.
• Die aktuelle IP einer Plattform in einen A-Record kopieren statt den verlangten CNAME zu nehmen. Funktioniert bis zu dem Tag, an dem nicht – und man sagt Ihnen nichts davon.
• Einen MX-Record auf einen CNAME zeigen lassen. Empfangende Mailserver lehnen das ab; nehmen Sie einen Namen mit A-Record.
• www einrichten und den Apex vergessen – oder umgekehrt. Entscheiden Sie, welcher kanonisch ist, zeigen Sie den anderen darauf und halten Sie Zertifikate für beide.
• Eintragstyp und Wert in einem Zug ändern, ohne vorher die TTL zu senken, und sich dann fragen, warum die halbe Welt noch das alte Ziel sieht.

Kurzfassung

Nehmen Sie einen A-Record, wenn die IP-Adresse Ihnen gehört; nehmen Sie einen CNAME, wenn Sie auf den Hostnamen eines anderen zeigen und wollen, dass dessen Infrastrukturänderungen für Sie unsichtbar bleiben. Ihr Apex kann kein CNAME sein, weil er NS- und SOA-Records tragen muss und ein CNAME keine Gesellschaft auf demselben Namen duldet – nehmen Sie dort ALIAS, ANAME oder das CNAME-Flattening Ihres Anbieters, leiten Sie den Apex auf www weiter, oder nehmen Sie einen A-Record nur dann, wenn die Plattform eine stabile Adresse veröffentlicht. Prüfen Sie mit dem kostenlosen DNS-Lookup-Tool, worauf eine Domain heute auflöst, samt Eintragstyp und verbleibender TTL, und bestätigen Sie das Zertifikat des neuen Hosts mit dem SSL Checker.

Verwandte Tools und Leitfäden:

• DNS-Abfrage – Fragen Sie A-, AAAA-, MX-, TXT-, NS- und weitere DNS-Einträge mit Werten und TTL sowie Reverse-DNS ab.
• SSL Checker – Prüfen Sie das SSL-Zertifikat jeder Domain: Aussteller, Ablaufdatum und verbleibende Tage.
• Warum DNS-Änderungen dauern: TTL und Propagation – Eine DNS-Änderung ist nicht langsam, sie ist zwischengespeichert

Häufige Fragen