Für die Hauptdomain (example.com) brauchst du einen A-Record, weil dort auch SOA-, NS- und MX-Einträge stehen und ein CNAME daneben nicht erlaubt ist. Für Subdomains wie www ist ein CNAME sinnvoll, wenn sie dieselbe IP wie ein anderer Name haben sollen oder auf einen externen Dienst zeigen, dessen IP sich ändern kann.
Die Frage taucht meistens in einem von zwei Momenten auf. Entweder ein externer Dienst verlangt „setze einen CNAME auf xyz.dienst.net“, und an der Hauptdomain lässt das Panel das nicht zu. Oder du ziehst um und überlegst, wie viele Einträge du dabei anfassen musst. Beides hat dieselbe Antwort, sobald klar ist, was die zwei Typen tun.
CNAME oder A-Record: der Unterschied in einem Satz
Ein A-Record sagt: „Dieser Name hat diese IPv4-Adresse.“ Ein CNAME sagt: „Dieser Name ist nur ein Alias, frag stattdessen nach jenem Namen.“
$ORIGIN example.com.
@ 3600 IN A 192.0.2.10
@ 3600 IN AAAA 2001:db8:10::1
www 3600 IN CNAME example.com.
shop 3600 IN CNAME shops.example-saas.net.Fragt ein Resolver nach www.example.com, bekommt er den CNAME, folgt ihm zu example.com und liefert die A-Adresse von dort. Mit dig sieht man die Kette:
dig www.example.com A +noall +answerwww.example.com. 3600 IN CNAME example.com.
example.com. 3600 IN A 192.0.2.10Die vier Regeln, die die Entscheidung abnehmen
1. An der Hauptdomain geht kein CNAME. Die Zonenspitze trägt immer SOA und NS. Ein CNAME darf aber keine anderen Daten neben sich haben (RFC 1034, Abschnitt 3.6.2). Also: example.com bekommt A und AAAA. Ausnahme sind DNS-Anbieter mit ALIAS/ANAME oder „CNAME-Flattening“, die das Ziel serverseitig auflösen und als A-Record ausliefern. Das ist eine Eigenheit des Anbieters, kein Standard-Record-Typ.
2. Ein Name mit CNAME hat nichts anderes. Kein MX, kein TXT, kein zweiter CNAME. Willst du für mail.example.com einen TXT-Eintrag setzen, darf mail kein CNAME sein.
3. MX und NS zeigen nie auf einen CNAME. RFC 2181, Abschnitt 10.3. Ein MX mail.example.com muss einen eigenen A-Record haben.
4. Externe Dienste mit wechselnden IPs bekommen einen CNAME. Wenn ein SaaS-Anbieter, ein CDN oder ein Status-Dienst dir einen Hostnamen nennt, setzt du den CNAME darauf. Der Anbieter kann seine IPs ändern, ohne dass du etwas tun musst.
Entscheidungstabelle
| Fall | Empfehlung | Warum |
|---|---|---|
example.com auf eigenen VServer | A + AAAA | CNAME an der Spitze verboten |
www auf denselben VServer | CNAME auf example.com. oder A | Geschmackssache, CNAME spart Pflege |
app auf zweiten eigenen Server | A + AAAA | Eigene IP, kein Alias nötig |
shop auf SaaS-Anbieter | CNAME auf Anbieter-Host | Anbieter-IPs können wechseln |
mail als MX-Ziel | A + AAAA | MX darf nicht auf CNAME zeigen |
_acme-challenge für Wildcard-Delegation | CNAME | Typisches acme-dns-Muster |
Den letzten Fall erklärt der Artikel zum Wildcard-Zertifikat: Du delegierst die DNS-Challenge per CNAME an eine Zone, die ein Skript automatisch beschreiben darf.
CNAME für www: lohnt sich das?
Bei einem einzelnen VServer bringt der CNAME für www vor allem eins: Beim Serverumzug änderst du nur den A- und AAAA-Record der Hauptdomain, www folgt automatisch. Bei zwei Einträgen ist das ein kleiner Gewinn, bei zwanzig Subdomains auf demselben Server ein großer.
Der Nachteil ist rein theoretisch: Ein Resolver braucht beim kalten Cache zwei Antworten statt einer. Liegen Alias und Ziel in derselben Zone, liefert der Nameserver beide in einer Antwort, wie im dig-Beispiel oben.
Konflikte, die du im Panel siehst
„Record conflicts with existing CNAME“ oder ähnliche Meldungen bedeuten fast immer Regel 2. Typischer Fall: Du hast www als CNAME angelegt und willst jetzt für die Google-Search-Console-Verifizierung einen TXT auf www setzen. Geht nicht. Entweder TXT auf die Hauptdomain, oder www auf A/AAAA umstellen.
Manche Panels lassen den Konflikt zu und speichern beides. Dann antworten Nameserver je nach Software unterschiedlich, und du jagst einen Fehler, der nur bei manchen Resolvern auftritt. Prüfe nach dem Anlegen:
dig www.example.com ANY +noall +answer @ns1.example-dns.netViele Nameserver beantworten ANY inzwischen nur noch verkürzt (RFC 8482). Frag im Zweifel die Typen einzeln ab.
CNAME, Zertifikate und Reverse Proxy
Für Let’s Encrypt ist es egal, ob www per CNAME oder A-Record auf deinen Server zeigt. Die HTTP-01-Validierung folgt der Auflösung und landet am Ende auf derselben IP. Wichtig ist nur, dass der Name im Zertifikat steht: certbot -d example.com -d www.example.com.
Auf dem Server selbst ändert der CNAME nichts. Der Browser schickt im Host-Header und im SNI weiterhin www.example.com, nicht das CNAME-Ziel. Dein nginx oder Caddy muss also den ursprünglichen Namen kennen. Wie das mit mehreren Domains aussieht, steht unter Reverse Proxy für mehrere Domains.
CNAME-Ketten vermeiden
Ein CNAME darf auf einen Namen zeigen, der selbst ein CNAME ist. Das ist erlaubt, aber jede Stufe ist eine weitere mögliche Fehlerquelle, und Resolver folgen solchen Ketten nur bis zu einer begrenzten Tiefe. In der Praxis entstehen Ketten unbemerkt: shop zeigt auf den SaaS-Anbieter, der intern auf sein CDN verweist, das wieder auf einen regionalen Host zeigt. Drei Stufen, von denen du zwei nicht kontrollierst.
dig shop.example.com A +noall +answerDie Ausgabe zeigt jede Stufe als eigene Zeile. Für deine eigenen Namen gilt: höchstens eine Stufe. www zeigt auf example.com, nicht auf web, das wiederum auf example.com zeigt.
Umzug: was ein CNAME dir abnimmt
Beim Umzug auf einen neuen VServer musst du nur die Einträge anfassen, die eine IP enthalten. Mit CNAMEs für alle Subdomains sind das genau zwei: A und AAAA der Hauptdomain. Wie du das ohne Ausfall machst, beschreibt Server-Umzug ohne Downtime, und die Grundlagen zum A-Eintrag selbst findest du unter A-Record setzen.
Die Einträge pflegst du bei betadomain direkt im Kundenbereich der Domain. Wer gerade eine Domain für ein neues Projekt sucht, kann den Domain-Check von betadomain nutzen, die .app-Endung liegt bei 22,99 € im Jahr, und die Preise aller Endungen stehen auf einer Seite.
Domain gefunden? Prüfen und registrieren kannst du sie direkt bei Domain registrieren – Jahrespreis ab 2,99 €.
Häufige Fragen
Warum kann ich keinen CNAME auf die Hauptdomain setzen?
Ein CNAME darf laut RFC 1034 und RFC 2181 keine anderen Einträge neben sich haben. An der Zonenspitze stehen aber immer SOA und NS, meist auch MX und TXT. Manche DNS-Anbieter bieten dafür ALIAS- oder ANAME-Einträge an, die der Nameserver intern in A-Records auflöst.
Ist ein CNAME langsamer als ein A-Record?
Minimal. Liegt das Ziel in einer anderen Zone, muss der Resolver beim ersten Abruf eine zweite Kette auflösen. Danach ist beides gecacht. Für die Ladezeit einer Website spielt das praktisch keine Rolle.
Kann ein MX-Record auf einen CNAME zeigen?
Laut RFC 2181 nicht. Das Ziel eines MX- oder NS-Eintrags muss ein Name mit eigenem A- oder AAAA-Record sein. Manche Mailserver tolerieren es, verlassen solltest du dich darauf nicht.
Soll www ein CNAME oder ein A-Record sein?
Liegt www auf demselben Server wie die Hauptdomain, ist ein CNAME auf example.com bequem, weil du bei einem Umzug nur einen Eintrag änderst. Ein eigener A-Record funktioniert genauso gut und spart eine Auflösungsstufe.