CNAME-Record: Erklärung des DNS-Record-Typs
Das Domain Name System (DNS) ermöglicht das Surfen durchs World Wide Web, wie wir es kennen: Man gibt den Namen einer Domain in Form einer URL ein und kommt so auf die gewünschte Website. Die eigentliche Kommunikation findet allerdings über eine individuelle IP-Adresse statt. Das DNS basiert auf Einträgen in Zonendateien. Die eigentliche Namensauflösung findet durch die wichtigen Typen der A-Records und AAAA-Records statt.
Es gibt viele verschiedene Record-Typen. In unserem umfangreichen Artikel über DNS-Records erklären wir nicht nur die grundlegenden Eigenschaften der Einträge, sondern bieten auch eine Überblickstabelle mit sämtlichen Typen.
Es ist aber nicht so, dass eine IP-Adresse immer nur mit einem Domainnamen verknüpft ist. Es können auch mehrere Namen auf die gleiche IP-Adresse verweisen. Um das zu ermöglichen, nutzt das DNS die CNAME-Records.
Was sind CNAME-Records?
Das DNS basiert auf einem dezentral organisierten Server-Netzwerk. Nameserver verwalten bestimmte Zonen und verfügen zu diesem Zweck über Zonendateien: Einfache Textdateien, in denen verschiedene DNS-Records Zeile für Zeile aufgeführt sind. Die Einträge setzen sich aus verschiedenen Typen zusammen. Um dem Domainnamen mit einer IPv4-Adresse zu verknüpfen, wählt man den Typ A. Mit dem Typ CNAME verknüpft man wiederum einen Domainnamen mit einem Alias – also einem anderen Namen, unter dem dasselbe Angebot zu erreichen ist.
Der eigentliche Name ist dann jener, der in einem A-Record mit der IP-Adresse verbunden wird. Der Vorteil hierbei: Ändert sich die IP-Adresse, muss man lediglich den A-Record anpassen. Da alle Aliase sich wiederum auf diesen Eintrag des Typs A (oder AAAA) beziehen, werden die CNAME-Records direkt mitangepasst.
Die Bezeichnung CNAME ist ein Kofferwort aus ‚Canonical Name‘, also kanonischer Name – der Name, der Standard ist. Deshalb ist die Bezeichnung auch etwas verwirrend, denn der Eintrag etabliert eben nicht den ‚eigentlichen‘ Domainnamen, sondern sein Alias.
Syntax von CNAME
DNS-Records folgen einer standardisierten Syntax mit verschiedenen Feldern:
- <name>: Im ersten Feld erscheint das Alias der Domain.
- <ttl>: Die „Time to live“ bezeichnet die Zeit, die ein Eintrag im Cache behalten werden darf, bevor man die Informationen neu anfordern muss.
- <class>: Das Class-Feld ist optional und gibt die Art des Netzwerkes an, für das der Eintrag gilt.
- <type>: Dieses Feld legt den Typ des Eintrags fest – in diesem Fall also CNAME.
- <rdata>: Das letzte Feld enthält die Information, auf die sich der Eintrag eigentlich bezieht, in diesem Fall also der eigentliche Name der Domain.
Die Felder werden einfach durch Leerzeichen getrennt und innerhalb einer Zeile angeordnet:
<name> <ttl> <class> <type> <rdata>Die sogenannte Time to live (TTL) gibt praktisch die Haltbarkeit der Informationen an. Der Anbieter garantiert, dass die Daten in diesem Zeitraum korrekt sind und daher im Cache bleiben dürfen. Ist die Zeit abgelaufen, müssen die Informationen erneut vom Server abgerufen werden. In der Praxis taucht das Feld allerdings nur selten in den einzelnen Einträgen auf. Stattdessen legt man global für die komplette Zone eine TTL fest. Die einzelnen Records übernehmen diese dann.
Das optionale Feld zur Klasse hat heute nur noch historischen Wert: Bei der Etablierung des DNS kamen ursprünglich noch die beiden heute nicht mehr existierenden Netzwerke Hesiod (HS) und Chaosnet (CH) in Frage. Inzwischen ist nur noch das Internet übrig geblieben. Deshalb findet man an dieser Stelle entweder das Kürzel IN oder das Feld entfällt komplett.
Namen werden in DNS-Einträgen immer im Format der Fully Qualified Domain Names (FQDN) angegeben. Das bedeutet, dass die Angabe mit einem Punkt endet. Grund dafür: FQDN verfolgen den kompletten Pfad einer Domain nach – und diese beginnt (ganz rechts) mit dem Rootserver. Da das entsprechende Feld allerdings leer ist, bleibt nur der Punkt übrig, der die Bestandteile voneinander trennt.
Ein CNAME-Record muss immer auf eine andere Domain verweisen. Es ist nicht zulässig, stattdessen eine IP-Adresse einzusetzen. Außerdem ist es nicht zulässig, das definierte Alias in anderen Record-Typen zu verwenden. Empfohlen wird zudem, einen CNAME-Eintrag nicht auf einen anderen CNAME-Eintrag verweisen zu lassen. Das führt zwar nicht zu einem Fehler, macht die Zonendatei aber unnötig komplex.
CNAME-Beispiel
In der Praxis sieht ein CNAME-Record folgendermaßen aus:
www.example.net. CNAME www.example.com.Damit der Verweis durch CNAME funktionieren kann, muss ebenfalls ein A- und/oder AAAA-Record in der Zonendatei vorhanden sein.
$TTL 11107
www.example.com. IN A 93.184.216.34
www.example.com. IN AAAA 2606:2800:220:1:248:1893:25c8:1946
www.example.net. IN CNAME www.example.com.
www.example.org. IN CNAME www.example.com.Die beiden CNAME-Records verweisen auf den A- bzw. AAAA-Record. Die Time to live ist global für die ganze Zone (dargestellt wird das durch das Dollarzeichen) auf 11107 Sekunden gesetzt – sie beträgt also etwas mehr als drei Stunden.
CNAME-Check: Wie man den CNAME-Eintrag herausfindet
Möchten man den CNAME-Record einer Website herausfinden, kann man entweder zu einer speziellen Software greifen oder einfach einen Webdienst dafür verwenden. Mit Public DNS stellt Google einen eigenen DNS-Server zur Verfügung, über den man an die verschiedensten DNS-Records von Websites kommt.
Auf der Startseite des Angebots gibt man dazu die gewünschte Domain ein, deren CNAME man checken möchte. Auf der folgenden Seite wechselt man den RR type (standardmäßig ist dieser auf A gestellt) auf den CNAME-Record, dann muss man noch einmal den Resolve-Button anklicken und erhält anschließend das Ergebnis.
Die beiden Einstellungen zu EDNS client subnet und DNSSEC können unverändert bleiben. Ersteres ist ein Mechanismus, der den Standort des Anfragenden mit erfassen und dadurch effizientere Ergebnisse liefern soll – er wird derzeit aber nur von Google und OpenDNS vorangetrieben. DNSSEC auf der anderen Seite garantiert dem Nutzer, dass die Informationen nicht durch einen Dritten manipuliert wurden, der sich unbemerkt in die Kommunikation geschaltet hat.
Ähnliche Artikel
MX-Record: Erklärung des DNS-Eintrags
Das Domain Name System bietet Funktionen, die die Kommunikation im Internet überhaupt erst ermöglichen. Der MX-Record zum Beispiel befasst sich mit der Bekanntgabe von Mailservern. Um zu erfahren, wohin Ihre E-Mail überhaupt gesendet werden muss, führt der Mailserver einen MX-Record-Check durch: Er fragt also nach der konkreten Adresse. Um das Prinzip zu verdeutlichen, erklären wir MX-Records an…
PowerUpShutterstock PTR-Record: Wie funktioniert der DNS-Eintrag?
PTR-Records drehen das DNS auf den Kopf: Statt wie gewohnt vom Namen einer Domain zur entsprechenden IP-Adresse zu gelangen, lässt sich mit Reverse DNS der Umkehrschluss vollziehen und beantworten. Welche Domain gehört zu einer IP-Adresse? Diese Information erhält man über PTR-Records, also spezielle DNS-Record-Typen. Wie müssen die DNS-Einträge dafür aufgebaut sein?
pixelparticleShutterstock SOA-Records: Grundstein jeder Zonendatei
Das Domain Name System, das die Verwendung von Domain-Namen beim Surfen ermöglicht, basiert auf Zonendateien. Diese wiederum bestehen aus verschiedenen Einträgen. Der erste DNS-Eintrag, den man in einer solchen Datei findet, ist immer der SOA-Record. Dieser legt Zuständigkeiten für die Zone fest. Wir erklären, wie die Einträge aufgebaut sind und wie man einen SOA-Record-Check durchführt.
TXT Resource Record
TXT-Records werden für unterschiedlichste Zwecke verwendet, u. a. dazu, bei Google-Diensten wie Google Analytics die Domäne zu verifizieren oder um den öffentlichen Schlüssel der DKIM-Signatur bereitzustellen. Wir erklären, was ein TXT-Record ist, wie Sie ihn erstellen und wie Sie ihn abfragen können.
SPF-Record verstehen und Check durchführen
Wie kann der Empfangende einer E-Mail feststellen, ob die Nachricht tatsächlich vom deklarierten Absendenden stammt? Viele Betrügerinnen und Betrüger versuchen, die Absende-Adresse zu fälschen. Doch man kann sich schützen: Mit der verbreiteten Methode SPF (Sender Policy Framework) lässt sich der sendende Mailserver verifizieren. Wie funktioniert SPF und was kann es leisten?
