DNS-Glossar

Was ist ein CNAME (kanonischer Name)?

Abstract isometric UI showing network ranges, usage bars, region names (EMEA/APAC), and a purple "Deploy" button
Die wichtigsten ErkenntnisseDie wichtigsten Erkenntnisse werden mithilfe von KI generiert. Da automatisierte Zusammenfassungen gelegentlich Fehler enthalten oder wichtige Zusammenhänge auslassen können, sollten Sie für vollständige Informationen stets den vollständigen Blogbeitrag lesen.

CNAME (canonical name) is a DNS record type that maps an alias domain name to a canonical target name, enabling multiple hostnames to depend on a single address through RFC 1034-compliant indirection. When a resolver encounters a CNAME record, it restarts its lookup at the canonical name and returns the target's records, reducing manual updates when services change addresses but introducing operational risks including subdomain takeover, mail delivery failures, and resolution delays. Organizations using CNAMEs extensively must implement regular audits of CNAME targets and remove stale aliases pointing to deprovisioned services to mitigate security vulnerabilities and maintain DNS reliability.

  • CNAME records cannot coexist with other DNS record types at the same name per RFC 1034, and therefore cannot be placed at zone apex where SOA and NS records must exist.
  • Dangling CNAME records pointing to decommissioned external services create security risk through subdomain takeover, where attackers can claim the target domain and serve malicious content under the organization’s name.
  • Long alias chains add extra DNS lookup steps and latency, while circular references between aliases cause resolution to fail with SERVFAIL errors.

CNAME auf einen Blick

AttributeValue
Full nameCanonical name
CategoryDNS record type
Defined inRFC 1034 and RFC 1035
Protocol and portDNS, port 53 over UDP and TCP
OSI layerApplication layer (layer 7)
Primary usePointing one domain name at another so the alias inherits the target's records
Related termsA record, AAAA record, ALIAS record, DNS zone, TTL, Zone apex

So funktioniert CNAME

Ein CNAME-Eintrag speichert einen Aliasnamen und den kanonischen Namen, auf den er verweist. Wenn ein Resolver den Alias abfragt, weist die Antwort ihn an, stattdessen den kanonischen Namen nachzuschlagen.

  1. Client fragt den Alias ab: Ein Client fragt einen rekursiven Resolver nach einem Eintrag, beispielsweise einem A-Eintrag, für den Aliasnamen, zum Beispiel www.example.com.
  2. Der Server gibt den CNAME zurück: Der autoritative Server findet unter dem Alias keine Adressdaten, stößt dort jedoch auf einen CNAME-Eintrag. Er gibt diesen Eintrag zurück, der den kanonischen Namen angibt.
  3. Neustart des Resolvers am Ziel: Der Resolver wiederholt die Abfrage nach dem kanonischen Namen unter Verwendung desselben Datensatztyps. Dies kann eine andere Zone oder einen anderen autoritativen Server betreffen.
  4. Endgültige Antwort wird zurückgegeben: Der Resolver erhält die Einträge für den kanonischen Namen, wie beispielsweise dessen A- oder AAAA-Adressen, und gibt die vollständige Kette an den Client zurück, der die Adressen verwendet.

Ein Name, der über einen CNAME-Eintrag verfügt, darf keine anderen Eintragstypen unter demselben Namen haben. Aus diesem Grund kann ein CNAME nicht an der Spitze einer Zone stehen, wo SOA- und NS-Einträge vorhanden sein müssen. Jedes Glied in der Kette wird entsprechend seiner eigenen TTL zwischengespeichert, und lange Ketten verlängern die Abfragezeit.

Warum CNAME in Unternehmensnetzwerken wichtig ist

CNAME-Einträge ermöglichen es, dass viele Namen auf ein Ziel verweisen. Wenn ein Dienst seine Adresse ändert, müssen nur die A- oder AAAA-Einträge unter dem kanonischen Namen aktualisiert werden, und alle Aliase werden automatisch angepasst. Dies reduziert manuelle Änderungen in großen Zonen und wird häufig genutzt, um Hostnamen auf Content-Delivery-Netzwerke, gehostete Anwendungen und Load Balancer zu verweisen.

Diese Indirektion birgt jedoch auch ein Betriebsrisiko. RFC 1034 schreibt vor, dass ein Name mit einem CNAME keine weiteren Daten enthalten darf. Das Hinzufügen eines CNAME-Eintrags an einer Stelle, an der bereits MX-, TXT- oder NS-Einträge vorhanden sind, kann daher die E-Mail-Zustellung oder die Domain-Verifizierung beeinträchtigen. Lange Ketten verlangsamen die Auflösung und erschweren die Fehlerbehebung, und eine Schleife zwischen zwei Aliasen führt dazu, dass Lookups fehlschlagen.

Es gibt zudem eine sicherheitsrelevante Auswirkung. Wenn ein CNAME auf einen externen Dienst verweist, dessen Ressource nicht mehr bereitgestellt wird, kann ein Angreifer möglicherweise dieses Ziel für sich beanspruchen und Inhalte unter der Domain der Organisation bereitstellen – ein Zustand, der als „Dangling Record“ oder „Subdomain-Übernahme“ bezeichnet wird. Regelmäßige Überprüfungen der CNAME-Ziele und das Entfernen von Aliasen, wenn die dahinterliegenden Dienste eingestellt werden, beugen diesem Problem vor.

Wie sich CNAME im Vergleich zu verwandten Begriffen verhält

CNAME vs. A-Eintrag

Ein A-Eintrag ordnet einen Namen direkt einer IPv4-Adresse zu, während ein CNAME-Eintrag einen Namen einem anderen Namen zuordnet, der anschließend aufgelöst werden muss. Was ist ein A-Eintrag?

AttributeCNAMEA record
Points toAnother domain nameAn IPv4 address
Resolution stepsAt least one extra lookup at the canonical nameAnswer is returned directly
Coexistence with other records at the same nameNot allowed, per RFC 1034Allowed alongside MX, TXT and NS records
Use at the zone apexNot permitted, because the apex holds SOA and NS recordsPermitted
Effect of a target address changeAliases follow the target automaticallyEach A record must be edited separately

CNAME vs. Alias-Eintrag

Ein CNAME ist ein in RFC 1034 definierter Standard-DNS-Eintragstyp, während ein Alias-Eintrag eine anbieterspezifische Funktion ist, mit der ein Name – häufig der Zonen-Apex – einem anderen Namen oder einer anderen Ressource zugeordnet werden kann, ohne ein echter CNAME zu sein.

AttributeCNAMEAlias record
StandardizationStandard record typeProvider-specific, not a standard record type
Allowed at the zone apexNoUsually yes, depending on the provider
Answer returned to the clientA CNAME record followed by the target's recordsTypically the final address records, resolved by the provider
Portability between DNS providersPortableBehavior varies and may not transfer

Häufige Probleme mit CNAME-Einträgen

Das Hinzufügen eines CNAME-Eintrags an der Spitze einer Zone steht im Konflikt mit den SOA- und NS-Einträgen, die dort vorhanden sein müssen. Server können das Laden der Zone ablehnen, oder E-Mail- und Delegierungsfunktionen können ausfallen, wenn der Eintrag akzeptiert wird.

Ein CNAME, der unter einem Namen angelegt wird, der bereits MX-, TXT- oder andere Daten enthält, verstößt gegen RFC 1034. Zu den Symptomen gehören Fehler bei der E-Mail-Zustellung, verlorene Verifizierungsdatensätze und inkonsistente Antworten zwischen Resolvern.

Aliase, die auf Aliase verweisen, verursachen zusätzliche Lookups und Latenz, und eine Schleife zwischen zwei Namen führt dazu, dass die Auflösung mit dem Fehler „SERVFAIL“ fehlschlägt. Resolver begrenzen die Kettentiefe, sodass tiefe Ketten zeitweise fehlschlagen können.

Ein CNAME, der auf ein gelöschtes oder stillgelegtes Ziel verweist, gibt für den Alias den Status „NXDOMAIN“ zurück. Gehört der Zielname zu einem externen Dienst, den jemand anderes beanspruchen kann, kann der Alias für die Übernahme von Subdomains missbraucht werden.

Der Alias und der kanonische Name haben jeweils ihre eigene TTL, sodass eine Änderung am Ziel die Clients zu unterschiedlichen Zeitpunkten erreichen kann. Techniker beobachten, dass einige Nutzer nach einer Umstellung noch auf die alte Adresse zugreifen, bis beide zwischengespeicherten Einträge abgelaufen sind.

Erfahren Sie, wie ein einheitliches DDI den Netzwerkbetrieb vereinfacht

Verwalten Sie DNS, DHCP und IP-Adressen über eine einzige Plattform mit integrierter Automatisierung, Transparenz und Kontrolle.

CNAME-FAQ

Verwandte Begriffe

Network visualization showing IP addresses and interconnected nodes representing IPAM infrastructure and data flow

Einrichtung von geregelten, auditfähigen IPAM-Workflow- und Genehmigungsmodellen für Unternehmensnetzwerke

Entdecken Sie IP-Management-Lösungen für geregelte, auditfähige IPAM-Workflows. Ermöglichen Sie bereichsbezogene Genehmigungen und lückenlose…

Read more
Content Hub

Das OSI-Modell verstehen: Wo DNS und IP-Adressierung in die 7 Schichten passen

Machen Sie sich mit den sieben Schichten des OSI-Modells vertraut und erfahren Sie, wie DNS und IP-Adressierung in dieses Modell eingebunden sind. Lernen…

Read more
Fiber optic cables with glowing blue and cyan light points representing high-speed network data transmission and connectivity

Skalierung von DNS und IPAM für IPv6- und Dual-Stack-Unternehmensnetzwerke

Skalieren Sie DNS und IPAM für Dual-Stack-Unternehmensnetzwerke. Erfahren Sie, wie Micetro Teams bei der Verwaltung von IPv6-Migrationen mit integrierten…

Read more
Hand holding digital pen interacting with holographic network diagrams and data visualization on laptop screen, representing

Einbindung von DNS, DHCP und IPAM in Ansible- und Git-basierte Infrastructure-as-Code-Pipelines

Durch die Einbindung von DNS, DHCP und IPAM in Ansible- und Git-basierte IaC-Pipelines mit Micetro werden Adress- und Eintragsänderungen zu versionierten,…

Read more
Podcast

Podcast: Wie KI die Entwicklung von Unternehmenssoftware verändert

KI verändert die Netzwerkautomatisierung, doch eine sichere Implementierung erfordert solide Softwarepraktiken, Tests und Fachwissen, um Ausfälle zu…

Read more
Podcast

Podcast: Why Open Platforms Matter in Network Operations

Open platforms and API-first architecture enable intelligent network operations, automation, and AI-driven workflows across hybrid enterprises.

Read more
Network engineer reviewing LiveNX flow and telemetry data visualized across server racks in a hybrid multicloud environment

Erhalten Sie mit LiveAssist Antworten aus den LiveNX-Daten, über die Sie bereits verfügen

Erfahren Sie, wie LiveAssist, das KI-gestützte Add-on für LiveNX, Ihre Netzwerkdaten in schnelle, gezielte Antworten umwandelt – mit einem Mehrwert, den…

Read more
Hands on laptop with digital dashboard showing IP address usage, overlapping ranges, and cost analytics for DDI infrastructur

Erstellung einer Kostenanalyse für den Ersatz bestehender appliancebasierter DDI-Lösungen durch eine Overlay-Verwaltungsschicht

Manuelle DDI-Arbeiten kosten die befragten Teams 1.040 Stunden pro Jahr. Hier erfahren Sie, wie Sie die Kosten für eine Verlängerung, den…

Read more

Verwandte Artikel