„Setzen Sie www oder Ihre Subdomain per CNAME auf customers.anbieter.example“: Solche Anweisungen stehen häufig in den Einrichtungsdialogen von Shops, Helpdesks, CDNs und SaaS-Diensten. Gemeint ist weder eine IP-Adresse noch eine sichtbare Webseitenumleitung. Sie sollen einen DNS-Namen mit einem anderen DNS-Namen verknüpfen.
Ein CNAME-Record ist ein DNS-Eintrag, der einen Namen als Alias auf einen anderen Namen verweist. Beispielsweise kann shop.beispiel.de ein Alias auf anbieter.example.net sein. Der CNAME enthält dabei keine Server-IP. DNS folgt dem genannten Zielnamen und löst dessen weitere Einträge auf, bis eine nutzbare Adresse gefunden ist.
Der Browser fordert weiterhin https://shop.beispiel.de an. Die eigene Subdomain bleibt daher grundsätzlich in der Adresszeile stehen. Soll der Browser stattdessen sichtbar zu einer anderen URL wechseln, benötigen Sie eine HTTP-Weiterleitung, etwa mit dem Statuscode 301 oder 302. Diese Trennung zwischen DNS-Auflösung und Webserverantwort verhindert die häufigsten CNAME-Missverständnisse.
CNAME erklärt: DNS-Alias statt sichtbarer Webseitenweiterleitung
Bei einem CNAME müssen Sie zwei Namen auseinanderhalten: Der Recordname ist der Alias, das eingetragene Datenfeld enthält das Ziel. In shop.beispiel.de CNAME anbieter.example.net ist daher shop.beispiel.de der Aliasname und anbieter.example.net das CNAME-Ziel. Der historische Ausdruck „Canonical Name“ bedeutet nicht, dass dieses Ziel der einzig richtige oder offiziell registrierte Name eines Systems sein muss.
So folgt DNS dem CNAME-Ziel bis zur IP-Adresse
Rufen Sie shop.beispiel.de auf, fragt das System nach den für die Verbindung benötigten Adressdaten. Die DNS-Antwort teilt zunächst mit, dass dieser Name ein Alias auf anbieter.example.net ist. Anschließend wird die Auflösung beim Zielnamen fortgesetzt. Dort können A-Records mit IPv4-Adressen, AAAA-Records mit IPv6-Adressen oder weitere Aliasstufen liegen.
Vereinfacht entsteht die Kette shop.beispiel.de → anbieter.example.net → IPv4- oder IPv6-Adresse. Der CNAME übernimmt nur die Namensverknüpfung. Er stellt weder Webspace bereit noch legt er fest, welche Seite die Anwendung ausliefert. Existiert das Ziel nicht oder liefert es keine nutzbaren Adressdaten, bleibt der Alias trotz formal vorhandenem CNAME unerreichbar.
Dieser Aufbau ist besonders nützlich, wenn ein externer Dienst seine Infrastruktur selbst verwaltet. Der Dienst kann die A- und AAAA-Records seines Zielnamens ändern, ohne dass Sie bei jeder neuen Server-IP Ihren CNAME anpassen müssen. Verändert der Anbieter jedoch den vorgegebenen Zielhostnamen, müssen Sie den Alias entsprechend aktualisieren.
Warum die eigene Subdomain im Browser sichtbar bleibt
DNS arbeitet vor und unterhalb der eigentlichen HTTP-Verbindung. Es hilft dem Browser, den technischen Endpunkt für shop.beispiel.de zu finden. Der Browser ersetzt den aufgerufenen Hostnamen dadurch nicht automatisch durch anbieter.example.net. Auch die URL-Pfade werden vom CNAME nicht verändert: Aus shop.beispiel.de/produkte wird durch DNS allein keine andere Webadresse.
Dass die Kundendomain sichtbar bleibt, ist keine Maskierungs- oder Tarnfunktion. Der Browser kommuniziert weiterhin unter dem ursprünglich angeforderten Namen. Deshalb muss das Zielsystem diesen Hostnamen akzeptieren und bei HTTPS ein Zertifikat präsentieren, das genau diese Kundendomain abdeckt.
CNAME und HTTP-Weiterleitung erfüllen verschiedene Aufgaben
Eine sichtbare Weiterleitung entsteht erst, wenn ein Webserver oder Weiterleitungsdienst eine HTTP-Antwort aus der 3xx-Gruppe sendet und eine andere Ziel-URL nennt. Übliche Statuscodes sind 301 und 308 für dauerhafte sowie 302 und 307 für vorübergehende Weiterleitungen. Der Browser ruft daraufhin die neue URL auf und kann die Adresszeile ändern.
Soll beispiel.de sichtbar auf www.beispiel.de wechseln, genügt ein DNS-Alias nicht. Sie benötigen einen erreichbaren Webdienst, der die Anfrage beantwortet und die HTTP-Weiterleitung ausliefert. Dass beide Namen technisch auf denselben Server zeigen, ändert daran nichts.
Ein Server hinter einem CNAME kann seinerseits eine Weiterleitung senden. Ändert sich beim Aufruf eines Alias die URL, stammt diese Änderung daher aus der HTTP-Antwort oder der Anwendungslogik – nicht aus dem CNAME-Record.
CNAME, A und AAAA richtig wählen: Subdomains, Einsatzfälle und Apex-Grenzen
Die Auswahl folgt einer einfachen Regel: Nennt der Dienst eine IPv4-Adresse, verwenden Sie A. Für eine IPv6-Adresse ist AAAA vorgesehen. Erhalten Sie einen Zielhostnamen wie customers.anbieter.example, ist meist ein CNAME verlangt. Übernehmen Sie den Recordtyp exakt aus der Anbieteranleitung; gleich aussehende Eingabefelder sind technisch nicht austauschbar.
A, AAAA und CNAME unterscheiden sich durch ihr Datenfeld
- A-Record: Der Name zeigt direkt auf eine IPv4-Adresse, beispielsweise eine Adresse aus dem Dokumentationsbereich
192.0.2.0/24. - AAAA-Record: Der Name zeigt direkt auf eine IPv6-Adresse.
- CNAME-Record: Der Name ist ein Alias für einen anderen DNS-Namen, der anschließend weiter aufgelöst wird.
Ein CNAME kann nicht auf eine IP-Adresse zeigen. Tragen Sie eine Ziffernfolge in das CNAME-Zielfeld ein, lehnt das Portal den Wert entweder ab oder behandelt ihn syntaktisch als Domainnamen. Daraus entsteht kein A- oder AAAA-Record. Wechseln Sie in diesem Fall zum passenden Adressrecord.
Typische CNAME-Einsatzfälle bei extern betriebenen Diensten
CNAMEs werden vor allem für Subdomains verwendet, deren technische Infrastruktur ein anderer Dienst kontrolliert. Häufige Beispiele sind www, ein Shop, ein Helpdesk, eine Statusseite, ein Kundenportal, ein Newsletter-System, ein CDN oder eine SaaS-Anwendung. Auch manche Verifizierungsverfahren verlangen einen CNAME mit einem speziell vorgegebenen Zielnamen.
Für www.beispiel.de kann das Ziel etwa beispiel.de oder ein Anbieterhostname sein. Bei status.beispiel.de kann der Alias auf die Plattform des Statusseiten-Dienstes verweisen. Entscheidend ist nicht die Bezeichnung der Subdomain, sondern der vom Zieldienst verlangte Recordtyp und Zielname.
Der Alias erleichtert Infrastrukturwechsel auf Anbieterseite, garantiert aber keine funktionierende Anwendung. DNS kann den technischen Endpunkt finden; es konfiguriert dort weder ein Kundenkonto noch Website-Inhalte, Hostnamenregeln oder Zertifikate.
Ein CNAME schließt gewöhnliche Parallelrecords am selben Namen aus
An einem Aliasnamen dürfen neben dem CNAME grundsätzlich keine gewöhnlichen Nutzrecords wie A, AAAA, MX oder TXT stehen. www.beispiel.de gleichzeitig als A-Record und CNAME zu konfigurieren, ist daher falsch. DNSSEC-bedingte Signatur- und Nachweisdaten sind protokollbedingte Sonderfälle und ändern diese praktische Konfigurationsregel nicht.
Benötigt ein Dienst zusätzlich einen TXT-Record, prüfen Sie dessen exakten Recordnamen. Häufig liegt die Verifizierung auf einem separaten Namen wie _verify.shop.beispiel.de und kollidiert deshalb nicht mit dem CNAME von shop.beispiel.de. Verlangt der Anbieter beide Typen tatsächlich für denselben Namen, muss dessen Dokumentation eine alternative Konfiguration vorsehen.
Warum CNAME auf der Domainwurzel nicht regulär funktioniert
Der Zonenanfang heißt technisch Zone Apex. In einer DNS-Zone für beispiel.de ist dies beispiel.de selbst, während www.beispiel.de eine Subdomain ist. Umgangssprachliche Begriffe wie Hauptdomain oder Root-Domain meinen häufig den Apex, sind aber weniger präzise.
Ein gewöhnlicher CNAME ist am Zone Apex nicht zulässig, weil dort bereits für den Betrieb der Zone notwendige SOA- und NS-Daten vorhanden sein müssen. Das widerspricht der Regel, dass ein CNAME nicht mit gewöhnlichen anderen Daten am selben Namen koexistiert. Eine Subdomain wie www hat dieses grundsätzliche Problem nicht.
DNS-Anbieter lösen das Apex-Problem teilweise mit Funktionen namens ALIAS, ANAME oder CNAME Flattening. Dabei löst der autoritative DNS-Dienst den angegebenen Zielnamen selbst auf und liefert gegenüber Abfragenden typischerweise daraus abgeleitete Adressdaten. Das Bedienfeld kann deshalb eine CNAME-ähnliche Eingabe am Apex erlauben, ohne einen regulären Apex-CNAME auszuliefern.
Diese Bezeichnungen stehen nicht für eine anbieterübergreifend identische Standardfunktion. Zulässige Ziele, Aktualisierungsverhalten und Unterstützung weiterer Records unterscheiden sich. Flattening kann außerdem eine CNAME-basierte Verifizierung stören, wenn der prüfende Dienst ausdrücklich den CNAME selbst sehen will. Klären Sie vor der Einrichtung, welchen Recordtyp der Zieldienst verlangt, welche Apex-Funktion Ihr autoritativer DNS-Anbieter unterstützt und ob das konkrete Ziel zulässig ist.
CNAME-Fehler systematisch prüfen: DNS-Ziel, SaaS-Zuordnung, TLS und Cache
Ein gespeicherter CNAME beweist nur, dass im DNS eine Aliasregel angelegt wurde. Für eine funktionierende Website müssen zusätzlich das Ziel auflösbar, der angefragte Hostname beim Dienst eingerichtet und das HTTPS-Zertifikat passend sein. Prüfen Sie diese Ebenen getrennt, statt jedes Problem pauschal mit „DNS-Propagation“ zu erklären.
Diagnosematrix für die häufigsten CNAME-Probleme
Beginnen Sie mit der autoritativen Antwort für den Aliasnamen. Lösen Sie danach das vollständige CNAME-Ziel auf und schließen Sie Recordkonflikte aus. Erst anschließend prüfen Sie die Domainzuordnung im Dienst sowie HTTPS und Zertifikat.
| Beobachtung | DNS-Befund | Wahrscheinliche Ursache | Gezielt prüfen |
|---|---|---|---|
| Das Portal lehnt den CNAME-Wert ab. | Im Zielfeld steht eine IP-Adresse. | Eine Adresse wurde in den falschen Recordtyp eingetragen. | IPv4 als A, IPv6 als AAAA anlegen; für CNAME den vollständigen Zielhostnamen übernehmen. |
| Der Eintrag lässt sich nicht speichern oder liefert widersprüchliche Antworten. | Am selben Namen existieren CNAME und A, AAAA, TXT oder ein anderer Nutzrecord. | Der Aliasname verletzt die CNAME-Exklusivität. | Alle Records des exakten Namens prüfen und den Konflikt nach Anbieteranleitung auflösen. |
| Die Hauptdomain akzeptiert den CNAME nicht. | Der Recordname ist der Zone Apex. | SOA- und NS-Daten verhindern dort einen regulären CNAME. | A beziehungsweise AAAA oder eine unterstützte ALIAS-, ANAME- oder Flattening-Funktion verwenden. |
| Die aufgerufene URL bleibt unverändert. | Der CNAME löst korrekt auf. | Es wurde eine HTTP-Weiterleitung erwartet, aber nur ein DNS-Alias eingerichtet. | Für einen sichtbaren URL-Wechsel eine 301-, 302-, 307- oder 308-Antwort konfigurieren. |
| Die Subdomain ist nicht auflösbar. | Der CNAME existiert, sein Ziel liefert aber keine nutzbaren Daten oder existiert nicht. | Falscher, veralteter oder unvollständiger Zielhostname. | Zielzeichenfolge einschließlich Punkten und Schreibweise mit der aktuellen Dienstanleitung vergleichen. |
| Die Auflösung endet mit einem Fehler oder ungewöhnlich vielen Aliasstufen. | Das Ziel führt zurück zum Ausgangsnamen oder durch eine lange Kette. | CNAME-Schleife oder unnötige Verkettung. | Jede Aliasstufe verfolgen; geschlossene Schleifen entfernen und Ketten möglichst verkürzen. |
| Einige Geräte sehen noch den alten Wert. | Autoritative Server liefern bereits den neuen CNAME. | Resolver, Betriebssystem oder Anwendung nutzen einen gecachten Eintrag. | TTL des alten Records, verwendeten Resolver und lokale Caches prüfen; nicht blind eine feste Stundenfrist abwarten. |
| DNS stimmt, der SaaS-Dienst meldet die Domain aber als inaktiv. | Die Subdomain zeigt auf das verlangte SaaS-Ziel. | Die Kundendomain wurde noch nicht validiert oder dem Konto zugeordnet. | Custom-Domain-Status und den exakt eingetragenen Hostnamen im Dienst kontrollieren. |
| Es erscheint eine Standardseite, Fehlerseite oder Ablehnung. | DNS führt zum vorgesehenen Endpunkt. | Das Zielsystem kennt den angefragten Hostnamen nicht oder ordnet ihn keinem Mandanten zu. | Hostname- und Mandantenzuordnung beim Betreiber prüfen; DNS allein konfiguriert diese Zuordnung nicht. |
| HTTP reagiert, HTTPS zeigt jedoch eine Zertifikatswarnung. | CNAME und Zielauflösung sind funktionsfähig. | Das Zertifikat fehlt, ist noch nicht aktiv oder deckt nur den Anbieterhostname ab. | Prüfen, ob das Zertifikat den tatsächlich aufgerufenen Namen wie portal.beispiel.de enthält. |
Vergleichen Sie immer vollständige Namen. Ein Eintrag für shop.beispiel.de behebt keinen Fehler bei www.shop.beispiel.de. Prüfen Sie außerdem, ob das DNS-Portal Zielnamen automatisch um die eigene Zone ergänzt. Aus einem falsch interpretierten relativen Namen kann sonst unbemerkt ein Ziel wie anbieter.example.net.beispiel.de entstehen.
Warum ein korrekter SaaS-CNAME allein nicht genügt
Angenommen, portal.beispiel.de zeigt per CNAME auf customers.saas.example. DNS kann dadurch den technischen Endpunkt der Plattform finden. Beim Verbindungsaufbau fordert der Browser jedoch weiterhin portal.beispiel.de an. Der SaaS-Dienst muss diesen konkreten Hostnamen deshalb zusätzlich kennen.
Auf Anwendungsebene ordnet die Plattform den angefragten Namen dem richtigen Kundenkonto oder Mandanten zu. Fehlt diese Zuordnung, kann trotz korrekter DNS-Auflösung eine Standardseite, ein Plattformfehler oder eine abgewiesene Verbindung erscheinen. Das genaue Fehlerbild hängt vom Dienst ab.
Für HTTPS kommt eine dritte Ebene hinzu: Das präsentierte Zertifikat muss portal.beispiel.de abdecken. Ein Zertifikat ausschließlich für customers.saas.example reicht nicht, weil der Browser die Identität des aufgerufenen Kundennamens prüft. Viele Plattformen stellen das Zertifikat automatisiert aus, aber erst nach Domainvalidierung und Aktivierung.
Eine SaaS-Kundendomain ist daher erst betriebsbereit, wenn drei Bedingungen erfüllt sind: DNS führt zum vorgesehenen Endpunkt, die Anwendung hat den Hostnamen dem richtigen Kunden zugeordnet und TLS deckt die Kundendomain ab. Ein grüner DNS-Test bestätigt nur die erste Schicht.
Alte DNS-Werte haben keine pauschale Propagierungsfrist
Die TTL legt fest, wie lange ein DNS-Eintrag regulär im Cache verbleiben darf. Nach einer Änderung können Resolver und Geräte deshalb vorübergehend unterschiedliche Antworten liefern. Auch ein zuvor gecachtes Nichtexistieren des Namens kann die Sichtbarkeit eines neuen Records verzögern.
Prüfen Sie zuerst, ob alle autoritativen Nameserver den neuen Wert ausgeben. Erst dann sind Resolver- und lokale Caches die naheliegende Erklärung. Eine feste Wartezeit von 24 oder 48 Stunden ist keine belastbare Diagnose; TTL, alter Cachezustand und Resolververhalten sind entscheidend. Unter Ausfallbedingungen können einzelne Resolver zudem abgelaufene Daten vorübergehend weiterverwenden.
Häufige Fragen zu CNAME-Records
Was ist ein CNAME?
Ein CNAME-Record ist ein DNS-Eintrag, der einen Namen als Alias auf einen anderen Namen verweist. DNS setzt die Auflösung beim Zielnamen fort, bis die angefragten Daten gefunden werden oder die Auflösung scheitert.
Ist CNAME eine Weiterleitung?
Nein. Ein CNAME ist ein DNS-Alias und keine sichtbare Webseitenweiterleitung. Eine URL-Weiterleitung entsteht durch eine HTTP-Antwort, beispielsweise mit 301, 302, 307 oder 308.
Was ist der Unterschied zwischen CNAME und A-Record?
Ein A-Record enthält direkt eine IPv4-Adresse. Ein CNAME enthält einen anderen DNS-Namen als Ziel. Für IPv6-Adressen ist der AAAA-Record vorgesehen.
Kann ein CNAME auf eine IP-Adresse zeigen?
Nein. Das CNAME-Zielfeld ist für einen Domainnamen vorgesehen. Verwenden Sie für eine IPv4-Adresse einen A-Record und für eine IPv6-Adresse einen AAAA-Record.
Warum funktioniert CNAME auf der Hauptdomain nicht immer?
Am Zone Apex müssen bereits SOA- und NS-Records vorhanden sein. Ein regulärer CNAME darf dort nicht zusätzlich stehen. Manche DNS-Anbieter ermöglichen eine CNAME-ähnliche Apex-Konfiguration über eigene Alias- oder Flattening-Funktionen.
Was bedeutet ALIAS-Record?
ALIAS bezeichnet meist eine anbieterspezifische Funktion, die einen Zielhostnamen serverseitig in Adressdaten auflöst und deshalb häufig am Zone Apex eingesetzt werden kann. Funktionsumfang und zulässige Ziele hängen vom DNS-Anbieter ab.
Warum bleibt die URL gleich?
DNS hilft nur bei der Ermittlung des technischen Endpunkts. Der Browser fordert weiterhin den ursprünglich eingegebenen Hostnamen an. Erst eine HTTP-Weiterleitung kann ihn auf eine andere URL schicken.
Warum verlangt ein SaaS-Anbieter einen CNAME?
Der Anbieter kann Ihre Subdomain damit auf einen von ihm verwalteten Zielnamen führen und nachgelagerte IP-Adressen selbst ändern. Zusätzlich muss er Ihre Kundendomain aktivieren, der richtigen Anwendung zuordnen und für HTTPS ein passendes Zertifikat bereitstellen.
Praktische Prüfreihenfolge: Kontrollieren Sie zuerst Recordtyp, Recordname und Ziel, danach die vollständige DNS-Auflösung. Prüfen Sie anschließend die Domainzuordnung im Dienst und zuletzt das Zertifikat für den tatsächlich aufgerufenen Hostnamen.
Werbung
(**) UVP: Unverbindliche Preisempfehlung
Preise inkl. MwSt., zzgl. Versandkosten