CNAME Resource Record

Art einer Ressource in einem Domain Name System

Ein CNAME Resource Record (CNAME RR) ist im Domain Name System (DNS) dazu vorgesehen, einer Domäne einen weiteren Namen zuzuordnen. Die Abkürzung „CNAME“ steht für canonical name (englisch canonical = „anerkannt“, deshalb: „normalisiert“) und bezeichnet daher den primären, quasi echten Namen.

Im einfachsten Fall verweist der von einem CNAME Resource Record definierte weitere Domänenname („Alias“) auf den Domänennamensteil in einem A Resource Record (oder einem AAAA Resource Record). Dieser Resource Record wiederum verbindet dann den ursprünglichen Domänennamen mit einer IP-Adresse. Beim Wechsel einer IP-Adresse muss folglich nur noch dieser Resource Record geändert werden und alle per CNAME Resource Record definierten Aliase verweisen ebenfalls auf die neue IP-Adresse. Im Gegenzug ist die Namensauflösung über den CNAME Resource Record aufwendiger.

CNAME Resource Records sind in den Internetstandards RFC 1034[1] und RFC 1035[2] von 1987 definiert und im RFC 2181[3] von 1997 nochmals klargestellt, weil diesbezügliche Leistungsanforderungen der Standards ignoriert wurden.

Der Begriff des canonical name wurde vielfach als Einschränkung interpretiert, einen letztlich offiziellen Namen festlegen zu müssen. Daraus wurde wiederum abgeleitet, weitere Namen dürften nur solche von CNAME Resource Records sein, auf die andere CNAME Resource Records aber nicht verweisen dürften. Tatsächlich ist aber gemeint, dass es kein Name eines anderen Resource Records sein muss, sondern dass der Name auch nur irgendwo außerhalb vom Domain Name System anerkannt sein kann.[3]

Ein NS-, MX-, PTR- oder SRV Resource Record darf nicht auf einen CNAME Resource Record verweisen. Umgekehrt darf ein PTR Resource Record aber durchaus nur über einen CNAME Resource Record zugänglich sein. Der Name eines CNAME Resource Records darf nicht als Name anderer Resource Records verwendet werden, da er stellvertretend für alle Resource Records des Ziels steht. Einzige Ausnahme hiervon bilden die Domain Name System Security Extensions.

Syntax Bearbeiten

<Name> IN CNAME <Ziel>

Beispiele Bearbeiten

Im folgenden einfachen Beispiel wird mit einem A-Record sowie einem AAAA-Record zuerst ein Hostname mit einer IP-Adresse angelegt und anschließend mit einem CNAME RR auf diesen CNAME verwiesen (der Begriff „CNAME“ bezieht sich verwirrenderweise auf die rechte Seite des CNAME RR, er bezeichnet den eigentlichen bzw. ursprünglichen Namen der Domäne und bezeichnet nicht den linken Teil, also den „Alias“; häufig wird jedoch fälschlicherweise der Alias als „CNAME“ bezeichnet):

  www.example.com. IN A     192.0.2.42
                   IN AAAA  2001:db8::42
  www.example.net. IN CNAME www.example.com.

Mehrere CNAME Resource Records können auf dasselbe Ziel verweisen, aber auch verschachtelt werden:

  www.example.com. IN A     192.0.2.42
                   IN AAAA  2001:db8::42
  www.example.org. IN A     192.0.2.42
                   IN AAAA  2001:db8::42
  www.example.net. IN CNAME www.example.com.
  en.example.net.  IN CNAME www.example.net.
  de.example.net.  IN CNAME www.example.net.

Namensauflösung Bearbeiten

Wenn ein Nameserver eine Anfrage empfängt, für die ein CNAME RR existiert, folgt er im Regelfall dem Verweis und wiederholt den Auflösungsversuch für den kanonischen Name.[4] Im Beispiel erkennt der Nameserver, dass der angefragte Name www.example.net einen Alias darstellt, der auf www.example.com verweist. Ein autoritativer Nameserver schlägt in einem solchen Fall nach, ob er für www.example.com zuständig ist. Ein rekursiver Resolver wiederholt die Namensauflösung für www.example.com.[5]

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

Ein nslookup unter Windows würde folgende Antwort liefern:

  C:\>nslookup www.example.net
  Server:  router.box
  Address:  fd00::2666:12ff:feaf:581f
  Nicht autorisierende Antwort:
  Name:    www.example.com
  Addresses:  2001:db8::42
              192.0.2.42
  Aliases:  www.example.net

Unter Unix-Systemen wäre die Ausgabe des Programms host folgende:

  $ host www.example.net
  www.example.net is an alias for www.example.com.
  www.example.com has address 192.0.2.42
  www.example.com has IPv6 address 2001:db8::42

Es kann passieren, dass ein Nameserver nicht bis zur IP-Adresse auflösen kann, beispielsweise wenn für den kanonischen Namen kein Resource Record im DNS auffindbar ist. In diesem Fall gibt er nur den CNAME zurück.

Einschränkungen Bearbeiten

Für einen Alias in einem CNAME-Record dürfen zwecks Eindeutigkeit keine weiteren RR (A-Record, AAAA-Record, MX-Record etc.) gesetzt werden.

If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different.[4]

CNAME-Records dürfen daher nur bei Subdomains eingesetzt werden, da eine Hauptdomain immer einen SOA-Record und ein bis fünf NS-Records hat.

Unzulässig:

  example.com.      CNAME     somedomain.example.
  example.com.      A         192.0.2.42

Zulässig hingegen, da unterschiedliche Namen:

  example.com.      A         192.0.2.42
  www.example.com.  CNAME     example.com.

Dieser Einschränkung wegen wurden 2017 die ähnlichen und schon verbreiteten ALIAS oder ANAME Resource Records dokumentiert,[6] deren offizieller Status aber nicht über den eines Entwurfs hinauskam.[7]

Einzelnachweise Bearbeiten

  1. RFC 1034 – Domain Names – Concepts and Facilities. November 1987 (englisch).
  2. RFC 1035 – Domain Names – Implementation and Specification. November 1987 (englisch).
  3. a b RFC 2181 – Clarifications to the DNS Specification. Juli 1997 (englisch).
  4. a b RFC 1034 – Domain Names – Concepts and Facilities. November 1987, Abschnitt 3.6.2: Aliases and canonical names. (englisch).
  5. RFC 1034 – Domain Names – Concepts and Facilities. November 1987, Abschnitt 4.3.2: Algorithm. (englisch).
  6. E. Hunt, P. van Dijk, A. Eden: Address-specific DNS Name Redirection (ANAME). Internet Engineering Task Force, April 2017, abgerufen am 5. Mai 2023.
  7. History for draft-ietf-dnsop-aname-04. Internet Engineering Task Force, abgerufen am 5. Mai 2023.