CNAME vs. A-Record

Immer wieder bekomme ich die Frage, ob ich "mail.<firma>" als CNAME oder weiteren A-Eintrag im DNS eintragen soll. Auch wenn das Ergebnis auf den ersten Blick das gleiche scheint, gibt es wichtige Unterschiede.

A-Record

Jedes System in einem Netzwerk hat erst einmal einen eindeutigen Systemnamen. Auch wenn später mehrere Systeme, z.B. WebServer, später unter einem generischen Namen angesprochen werden, hat jedes System einen realen Namen. Dieser Name wird auch im DNS eintragen, z.B.

server1   A   192.168.1.11
server2   A   192.168.1.12

Ein CNAME kommt hierbei nicht in Betracht.

Bei einem Active Directory gibt es für jeden Computer auch ein passendes Computerkonto und wenn der Computer auch Kerberos unterstützt, hat das Computerkonto auch einen "ServicePrincipalName". Nur so kann der KDC beim Zugriff auf den Server ein Ticket ausstellen

Alte Server erreichbar halten

Ein Aspekt eines zweiten Namens besteht darin, dass der alte Servername nach der Abschaltung ebenfalls noch im DNS so eingetragen werden kann, dass Client eine Gegenstelle finden, sofern der gleiche Service bereitgestellt wird. Der DNS könnte nach Abschaltung von Server 1 wie folgt aussehen.

server1   A   192.168.1.11
server2   A   192.168.1.11

oder

server1     A    192.168.1.12
server2 CNAME    server1.firma.tld.

In beiden Fällen könne eine Anwendung, die noch den mittlerweile deinstallierte "server2" anspricht, den Namen auflösen und landet auf "server1". Solange dieser die gleiche Funktion bereit stellt, ist alles OK

Ich würde auf dem DNS-Server den noch eine Protokollierung aktivieren, um zu sehen, wer diesen Eintrag noch irrtümlich nutzt.

Alias statt realer Server

Es sollte sich aber auch herumgesprochen haben, dass Clients sich besser nicht mit einem echten Servernamen sondern mit einem generischen "Dienstnamen" verbinden. Ein Zugriff auf "mail.<firma.tld> oder "outlook.<firma.tld> ist auch viel lesbarer. Viel wichtiger ist aber die Möglichkeit bei einer Serverumstellung den Namen auf einen neuen Server umzustellen, ohne dass die Clients davon etwas mitbekommen. Aber damit haben wir dann die Herausforderung, wie wir das machen?

Ohne weitere Fachverstand gibt es für einen Administrator nun zwei Optionen. Er kann einfach zusätzliche A-Einträge anlegen

mail    A   192.168.1.11
mail    A   192.168.1.12

Oder er legt mehrere CNAME-Einträge an

mail    CNAME   server1.firma.tld.
mail    CNAME   server2.firma.tld.

Auf den ersten Blick sieht das gleich aus und einige DNS-Server erlauben sogar solche doppelten Einträge. Sie sind aber laut RFC nicht erlaubt.

...If a CNAME RR is present at a node, no other data should be present...
https://datatracker.ietf.org/doc/html/rfc1034

Mein letzter Test mit Windows 2016 Server zeigt auch, dass mehrere CNAME-Einträge nicht möglich sind:

Mehrere A-Records sind aber kein Problem.

Damit können Sie als ein wichtiges Unterscheidungsmerkmal mitnehmen, dass ein CNAME nur genau einmal gesetzt werden darf. Ein CNAME-Eintrag ist damit nicht für "Lastverteilung" per DNS geeignet.

Lastverteilung CNAME

Das ist einen CNAME nur genau einmal pro Name anlegen dürfen, verbietet sich damit der Einsatz als Lastverteilung, d.h. bei der ein Client zwei oder mehr CNAME-Einträge als Antwort bekommt, die auf unterschiedliche Server verwaisten.

Microsoft zeigt aber mittels Teams, dass CNAME durchaus zur Steuerung des Client-Zugriffs verwendet werden können.

Mein Lieblingsbeispiel dabei ist das Teams Media Relay, welches bei jeder Anfrage eine neue IP-Adresse liefert, obwohl ich immer den gleichen DNS-Server frage. Zuerst sehe Sie, dass ich per CNAME nacheinander weiter verwiesen werden.

PS C:\> (Resolve-DnsName worldaz.tr.teams.microsoft.com -Type A)

Name                                          Type  TTL Section NameHost
----                                          ----  --- ------- --------
worldaz.tr.teams.microsoft.com                CNAME  0  Answer  worldaz.tr.teams.trafficmanager.net
worldaz.tr.teams.trafficmanager.net           CNAME  0  Answer  b-tr-teasc-ukso-06.uksouth.cloudapp.azure.com
b-tr-teasc-ukso-06.uksouth.cloudapp.azure.com     A 10  Answer  52.113.202.62

Sie sehen hier aber auch den sehr kurzen TTL von "0", über den "trafficmanager.net" je nach Anfrage immer wieder einen anderen CNAME ausliefert. Sie könnten also sogar glauben, dass hier mehrere CNAME-Einträge existieren.

PS C:\> 1..10 | %{(Resolve-DnsName worldaz.tr.teams.microsoft.com -Type A)[-1].IPAddress}
52.112.173.6
52.112.168.209
52.114.248.44
52.114.94.184
52.112.172.108
52.113.202.67
52.114.253.193
52.114.94.48
52.114.233.198
52.114.248.44

Sie müssen also schon genauer hinschauen, was hier wie verteilt wird. Für den Client liefern die DNS-Server auf die erste Anfrage nämlich immer genau einen CNAME aus, der sich aber immer wieder ändert.

Lastverteilung mit A-Record

Eine Lastverteilung per DNS ist aber sehr wohl mit A-Records möglich. Es müssen nur alle Server die gleichen Funktionen anbieten. Natürlich gibt es noch weitere kleinere Voraussetzungen z.B. hinsichtlich einer "Affinität" von Verbindungen, einer Verfügbarkeit u.a. Dazu habe ich aber auf weiteren Seiten umfangreiche Informationen bereit gestellt.

Die meisten größeren Firmen nutzen aber immer eine "angepasste" Version der Lastverteilung, indem ein DNS-Loadbalancer auf die Anfragen eines Clients genau die IP-Adresse eines Server zurück gibt, der gerade verfügbar und nicht überlastet ist. Das geht aber kaum mit Bordmitteln.

Kerberos

Nun wissen wir, dass viele Dienste nicht anonyme erreichbar sein und anstatt "BasicAuth" oder "NTLM" auch eine Anmeldung per Kerberos seine Vorteile hat. Dabei greift ein Client auf den Servername zu und bekommt die Information, dass auch Kerberos möglich ist. Der Client fragt dann den KDC (Meist ein Windows Domain Controller) nach einem Ticket und der KDC schaut in seinem Verzeichnis (Meist Active Directory) nach dem Schlüsselmaterial für den Server um das Ticket zu signieren und zu verschlüsseln.

Damit ist klar, dass der Service selbst im Verzeichnisdienst einen passenden "ServicePrincipalName" (SPN) besitzen muss. Das kann der Server selbst oder bei einem Cluster das gemeinsam genutzte "Servicekonto" sein. Aber dann stellt sich noch die Frage, welche Namen der Client denn nun tatsächlich abfragt. Meine Erfahrung dazu sind

Client DNS-Zone Angefragter SPN 
http://webmail
 
server1  A   192.168.1.11
webmail CNAME server1.msxfaq.de.
 
HOST/server1
 
http://webmail
 
server1  A   192.168.1.11
webmail  A   192.168.1.11
 
HOST/webmail

Sie sehen hier, dass der Client beim CNAME, den es laut RFC ja auch nur genau einmal geben darf, den realen Servernamen verwendet. Das kann von Vorteil sein, wenn der alte Server schon lange deinstalliert ist und der neue Server die Funktion übernommen hat. Es kann aber auch verwirren, wenn Sie ein Dienstkonto mit dem SPN "host/webmail" konfigurieren und die Einstellung einfach nicht greift.

Wenn Sie stattdessen mit A-Records arbeiten, dann erwartet der Client auch eine Gegenstelle, die unter genau dem Namen erreichbar ist. Eine umgekehrte Suche per Reverse-DNS , wie der reale Server hinter der IP-Adresse lautet, findet nicht statt.

SSL

Ein weiterer Aspekt ist natürlich die Verbindung per HTTPS oder TLS im allgemeinen. Auch hier kann der Client per Namensaufösung auf einen CNAME oder auf einen A-Record stoßen.

Client DNS-Zone Erwarteter CN/SNI 
http://webmail
 
server1  A   192.168.1.11
webmail CNAME server1.msxfaq.de.
 
webmail
 
http://webmail
 
server1  A   192.168.1.11
webmail  A   192.168.1.11
 
webmail

Anderes als beim Kerberos kann der Client zwar auch hier erkennen, dass die DNS-Anfrage nach dem Namen über einen CNAME auf den wirklichen Namen verweist, aber das bringt den Client nicht dazu, beim TLS-Handshake den wirklichen Namen per SNI anzugeben oder im Zertifikat zu prüfen. Hier bleibt der Client beim konfigurierten oder vom Anwender eingegeben Namen.

Erst nach dem Handshake kann der Service dann im Rahmen des Protokolls z.B. per 301/302 Move oder einen HTTP-Redirect, einen SIP-REFER o.ä. den Client zu einem anderen Server verweisen.

Weitere Links