CNAME

Mit einem CNAME Resource Record (CNAME für eng. canonical name) wird zu einem vorhandenen DNS-Namen ein Alias-Name definiert. Links im Resource Record (RR) steht der Alias-Name und rechts der Original-Name oder in der DNS-Terminologie: der kanonische Name. Zu einem kanonischen Namen können beliebig viele Aliase definiert werden. Umgekehrt darf ein Alias-Name nur an einen kanonischen Namen verweisen.

Aufbau

       <name (Alias)>         <TTL> IN CNAME <rdata (Ziel)>

Im folgenden Beispiel wird zum kanonischen Namen example.com ein Alias angelegt:

       example.com.           3600  IN A     192.0.2.42
       www.example.com.       3600  IN CNAME example.com.

Komplexere Fälle

Zu einem kanonischen Namen können mehrere Aliase angelegt werden:

       example.com.           3600  IN A     192.0.2.42
       www.example.com.       3600  IN CNAME example.com.
       de.example.com.        3600  IN CNAME example.com.
       en.example.com.        3600  IN CNAME example.com.

Es ist auch nicht explizit verboten einen Alias auf einen bestehenden Alias zu definieren, also Aliase zu verketten:

       example.com.           3600  IN A     192.0.2.42
       www.example.com.       3600  IN CNAME example.com.
       de.example.com.        3600  IN CNAME www.example.com.

Laut Standard sollen Domainnamen in Resource Records jedoch stets auf den kanonischen Namen zeigen. Es wird also stark davon abgeraten, dass ein CNAME RR auf einen anderen Alias zeigt. Ebenso folgt daraus zum Beispiel, dass ein MX RR nicht auf einen Alias zeigen sollte. Es ist auch möglich, einen Alias zu einem kanonischen Namen aus einer anderen Domain zu definieren. Beispiel:

       example.com.           3600  IN CNAME www.example.net.

Nicht zulässig ist, einen Alias zu definieren, für den ein weiterer RR-Typ gleichen Namens existiert. Der Nameserver wüsste in diesem Fall nicht, wie er sich verhalten sollte. In diesem Beispiel existiert für die Domain example.com sowohl ein A-RR als auch ein CNAME-RR:

       example.com.           3600  IN A     192.0.2.42
       example.com.           3600  IN CNAME www.example.net.

Alias-Auflösung

Wenn ein Nameserver einen DNS-Request empfängt, für den ein CNAME-RR existiert, so löst er diesen selbst auf. Im obersten Beispiel erkennt der Nameserver, dass sich hinter www.example.com der kanonische Name example.com verbirgt und löst diesen auf, d. h. er ermittelt die zugehörigen IP-Adresse 192.0.2.42.

Bei der Antwort auf einen DNS-Request wird neben der IP-Adresse auch der kanonische Name übergeben. Der Resolver kann so erkennen, dass sich seine ursprüngliche Anfrage auf einen Alias-Namen bezogen hatte.

Beispiel

Ein nslookup würde folgende Antwort liefern:

       C:\>nslookup www.example.com

       Name:     example.com
       Address:  192.0.2.42
       Aliases:  www.example.com

Es kann natürlich passieren, dass der Nameserver einen kanonischen Namen nicht auflösen kann. In diesem Fall lässt er bei der Antwort einfach die IP-Adresse weg, und übergibt nur den kanonischen Namen. Der Resolver kann dann selbst versuchen, diesen Namen aufzulösen.

Hinweis:
Ein PTR-RR sollte niemals auf einen Alias zeigen, sondern grundsätzlich auf einen kanonischen Namen. Die meisten Nameserver akzeptieren allerdings auch PTR-RRs auf Aliase.

Korrektes Beispiel (example.com ist ein kanonischer Name):

       42.2.0.192.in-addr.arpa.  IN PTR example.com.

Inkorrektes Beispiel (www.example.com ist ein Alias):

       42.2.0.192.in-addr.arpa.  IN PTR www.example.com.

Bedeutung beim Name-Based Virtual Hosting

Bei einem CNAME-Eintrag wird der angegebene Name unter Beachtung der CNAMEs aufgelöst. Demnach erreicht auch de.example.com aus dem obigen Beispiel den Server von example.com unter der IP 192.0.2.42. Bei einem HTTP-Request würde im Host Header jedoch weiterhin der Domain-Name de.example.com stehen, welcher vom Zielserver erkannt und getrennt behandelt werden kann. Das Verfahren, auf einer einzigen IP mehrere, unterschiedliche Domain-Namen zu verwalten, nennt sich Name-Based Virtual Hosting.

Weblinks

• RFC 1035 – Domain Names – Implementation and Specification. November 1987.