Zum Inhalt springen 
A-Record CNAME klingt ähnlich, erledigt im DNS aber zwei verschiedene Aufgaben: Der A-Record weist eine Domain direkt einer IPv4-Adresse zu, der CNAME setzt stattdessen einen Alias auf einen anderen Hostnamen. In diesem Beitrag erkläre ich den praktischen Unterschied, wo jeder Eintragstyp glänzt, und wie du beides sauber einsetzt, damit Subdomains, www und externe Dienste zuverlässig an die richtige Adresse zeigen.
Zentrale Punkte
- A-Record: direkte Zuordnung einer Domain zu einer IPv4-Adresse
- CNAME: Alias von einer Subdomain auf einen anderen Hostnamen
- Performance: A-Record meist schneller, CNAME flexibler
- Apex-Domain: für die Stamm-Domain nutze gewöhnlich A-Record
- Wartung: IP-Wechsel nur am A-Record, CNAMEs folgen
DNS in kürzester Form erklärt
Ich vergleiche DNS gern mit einem Telefonbuch: Menschen merken sich Namen, Rechner sprechen IPs, und DNS übersetzt zwischen beiden. Wenn du beispiel.de aufrufst, holt der Resolver die passenden Einträge von autoritativen Nameservern und liefert die IP, damit der Browser die Anfrage an den richtigen Server schickt. Damit dieser Ablauf flott bleibt, arbeiten Resolver mit Zwischenspeichern und respektieren die festgelegte TTL, die regelt, wie lange ein Ergebnis gültig bleibt. Für einen kompakten Einstieg empfehle ich die Erklärung zu DNS und Domain Name System, die die wichtigsten Bausteine auf den Punkt bringt. Behalte als Grundregel: Ohne richtige DNS-Einträge erreicht ein Nutzer deine Website nicht, selbst wenn der Webserver tipptopp läuft.
A-Record: direkte Zuordnung zur IPv4-Adresse
Ein A-Record verbindet eine Domain oder Subdomain unmittelbar mit einer konkreten IPv4, etwa 203.0.113.10, dadurch landet die Anfrage ohne Umweg direkt auf der gewünschten Maschine. Diese Direktheit bringt Tempo, denn der Resolver benötigt normalerweise nur eine Abfrage, was spürbar kurze Antwortzeiten liefern kann. Setze A-Records für Hauptdomains und für Subdomains mit eigenem Zielserver ein, wenn du die IP kontrollierst und sie nicht ständig wechselst, so behältst du die Hoheit über die Auflösung. Plane die TTL so, dass sie zu deiner Änderungsfrequenz passt: seltene Änderungen erlauben eine längere TTL für weniger DNS-Traffic, häufige Umzüge profitieren von kurzer TTL, damit sich neue IPs schneller verbreiten. Nutzt du zusätzlich IPv6, ergänze den AAAA-Record, denn der A-Record deckt ausschließlich IPv4 ab.
CNAME: Alias für Hostnamen und Subdomains
Ein CNAME zeigt nicht auf eine IP, sondern auf einen anderen Hostnamen, weshalb man ihn als Alias versteht, der die Verwaltung vieler Subdomains vereinfacht. Beispiel: www.beispiel.de weist als CNAME auf beispiel.de, die eigentliche IP sitzt nur auf der Stamm-Domain und bleibt dein einzelner Anpassungspunkt. Ändert sich die Server-IP, passe ausschließlich den A-Record der Hauptdomain an, und alle abhängigen CNAMEs folgen automatisch dem neuen Ziel. So halte ich Setups mit Blog-, Shop- oder App-Subdomains schlank, gerade wenn mehrere Dienste das gleiche Backend nutzen. Binde auf diese Art auch externe Plattformen an, etwa cdn.provider.net, ohne die dahinterliegende IP kennen oder pflegen zu müssen.
Direkter Vergleich: Eigenschaften, Performance und Einsatz
Beide Eintragstypen erfüllen klare Aufgaben, unterscheiden sich aber bei Ziel, Auflösung und Einsatzschwerpunkt, was du in der täglichen Arbeit spürst. Greife für die Apex-Domain üblicherweise zum A-Record, weil E-Mail-Einträge wie MX parallel stehen müssen und ein CNAME dort Probleme verursacht. Für Subdomains gewinnt der CNAME an Charme, denn er reduziert deinen Pflegeaufwand und hält die Konfiguration übersichtlich, besonders in großen Umgebungen. In puncto Antwortzeit punktet der A-Record, weil ein Lookup genügt, während ein CNAME mindestens einen zusätzlichen Schritt erfordert, der je nach Resolver kaum messbar, bei vielen Ketten jedoch spürbar sein kann. Die folgende Tabelle fasst die Kerndaten zusammen und zeigt, warum ich beides je nach Zielsetzung bewusst mische:
| Eigenschaft | A-Record | CNAME |
|---|---|---|
| Zieltyp | IP-Adresse (IPv4) | Hostname (Alias) |
| Auflösung | meist 1 Lookup | mind. 2 Lookups |
| Hauptdomain (Apex) | geeignet | problematisch mit MX |
| Wartung bei IP-Wechsel | alle betroffenen A-Records ändern | nur A-Record am Ziel, CNAMEs folgen |
| Einsatzprofil | feste, kritische Ziele | viele Subdomains, externe Dienste |
Praxis: Beispiele für saubere Konfigurationen
Ich starte bei neuen Projekten mit einer klaren Trennung: Die Apex-Domain bekommt einen A-Record, www zeigt über CNAME auf die Apex, und weitere Subdomains folgen je nach Bedarf. Zeigt ein Shop auf eine SaaS-Plattform, setze ich shop.deinedomain.de als CNAME auf shop.example.net, damit spätere Umstellungen ohne IP-Kenntnis funktionieren. Für interne Tools mit eigener Maschine wie monitor.deinedomain.de wähle ich einen A-Record, da ich dort die IP bewusst steuere und direkte Auflösung bevorzuge. Die folgende Mini-Matrix macht den Unterschied greifbar und zeigt, wie flexibel CNAMEs in größeren Setups wirken. So halte ich die DNS-Verwaltung übersichtlich und reaktionsfähig:
| Subdomain | Typ | Ziel |
|---|---|---|
| www | CNAME | beispiel.de |
| blog | CNAME | beispiel.de |
| shop | CNAME | shop.external.com |
| beispiel.de | A-Record | 192.0.2.10 |
TTL, Performance und Ketten von CNAMEs
Die TTL (Time to Live) beeinflusst, wie lange Resolver Antworten zwischenspeichern, was Performance und Aktualität direkt berührt. Für statische Ziele nutze ich längere TTLs, um die Anzahl der DNS-Abfragen zu senken, während ich vor geplanten Umzügen die TTL frühzeitig senke, damit Änderungen schnell weltweit ankommen. Bei CNAMEs gilt: Jede zusätzliche Kette erhöht die Anzahl der Auflösungen, weshalb ich Ketten kurz halte und Alias-Pfade regelmäßig prüfe. Achte darauf, dass du keine Schleifen erzeugst und dass das finale Ziel tatsächlich mit A- oder AAAA-Record auflösbar ist, sonst bleibt die Website unerreichbar. Teste Änderungen mit Tools wie dig oder nslookup, beobachte die Antwortzeiten und kontrolliere, ob der Resolver die erwartete TTL respektiert.
AAAA-Record und IPv6: doppelt erreichbar, sauber priorisiert
Neben A-Records setze ich konsequent AAAA-Records ein, damit Clients auch über IPv6 verbinden können. Moderne Stacks nutzen das „Happy Eyeballs“-Verfahren und wählen automatisch den schnelleren Pfad – du gewinnst Reichweite und Resilienz. Wichtig: Veröffentliche einen AAAA-Record nur, wenn der Dienst über IPv6 vollständig erreichbar ist (Firewall, Routing, TLS-Zertifikat, VirtualHost/SNI). Ein kaputter IPv6-Pfad führt sonst zu Zeitouts, obwohl IPv4 funktionieren würde. Ich halte die TTL von A und AAAA identisch, damit beide Pfade synchron altern, und prüfe regelmäßig mit dig AAAA, ob die Antwort stimmt.
Wildcards: Platzhalter gezielt einsetzen
Mit einem Wildcard-Eintrag (*.deinedomain.de) fängst du unbekannte Subdomains ab – praktisch als Fallback oder für kurzlebige Test-Hosts. Ich setze hier meist einen CNAME auf ein zentrales Ziel oder einen A-Record auf eine Landing-Page. Beachte die Priorität: Explizite Einträge schlagen Wildcards. Vermeide Wildcard-MX oder Wildcard-NS, die unbeabsichtigt Mail- oder Zonenstruktur verändern könnten. Halte Wildcards transparent dokumentiert, damit du weißt, welche Subdomains tatsächlich über den Platzhalter aufgelöst werden.
Mehrere A-Records: Round-Robin und Failover richtig einschätzen
Trägst du mehrere A-Records für dasselbe Label ein, verteilen Resolver die Antworten oft round-robin. Das ist einfache Lastverteilung, aber kein Health-Check: Fällt ein Ziel aus, liefern Caches es trotzdem, bis die TTL abläuft. Für echte Hochverfügbarkeit kombiniere ich DNS mit Upstream-Checks (z. B. Load-Balancer oder CDN) oder nutze Anbieter-Features wie gewichtet/aktiv-passiv. Plane die TTL bewusst: kurz genug für schnelle Umschaltung, lang genug gegen unnötige Last. Mit getrennten A- und AAAA-Sätzen kannst du zudem per-family subtil steuern, ohne asymmetrische Erreichbarkeit zu riskieren.
Apex-Domain, E-Mail und CNAME-Alternativen
Auf der Apex-Domain (beispiel.de) liegen neben A- oder AAAA-Record oft weitere Einträge wie MX für E-Mail, TXT für SPF und manchmal SRV, weshalb ein CNAME dort zu Konflikten führt. Einige Anbieter bieten sogenannte ALIAS- oder ANAME-Typen an, die am Apex wie CNAME wirken, dem Resolver aber eine IP präsentieren, damit parallele Einträge störungsfrei bestehen. Wenn dein Provider das nicht anbietet, bleib bei A- und AAAA-Records auf dem Apex und verwende CNAMEs nur auf Subdomains, so bleibt das Setup stabil und wartungsarm. Für E-Mail-Zustellung prüfe ich stets, dass MX sauber gesetzt und SPF, DKIM sowie DMARC vollständig sind, damit Auslieferung und Reputation passen. Diese Ordnung sorgt dafür, dass Web und E-Mail zuverlässig zusammenspielen und du bei Wartungen die richtige Stelle änderst.
E-Mail, MX und CNAME: Regeln, die Ärger sparen
Ich halte mich an zwei Grundsätze: 1) Ein Label, das MX oder andere Records hat, bekommt keinen CNAME (Regel „no CNAME and other data“). 2) Die Ziel-Hostnamen in MX zeigen idealerweise direkt auf A/AAAA und nicht auf einen CNAME, damit Mailserver nicht ins Leere laufen. Für DKIM nutze ich gern CNAMEs auf Vendor-Selector, denn dort existiert am Selector-Label ausschließlich der CNAME, was sauber funktioniert. Für die Zustellung selbst setze ich am Mail-Host (z. B. mail.deinedomain.de) dedizierte A/AAAA-Records und pflege SPF, DKIM und DMARC via TXT, damit Mail-Flows robust bleiben.
Stolperfallen: typische Fehler schnell erkennen
Die häufigsten Probleme sehe ich bei zu langen CNAME-Ketten, Alias-Schleifen und CNAMEs auf der Apex-Domain, wo bereits MX existieren und Konflikte auslösen. Ich prüfe in solchen Fällen die Zonendatei von oben nach unten, reduziere Ketten auf ein Minimum und setze den A-Record dort, wo andere Einträge benötigt werden. Ein weiterer Klassiker: verwechsele nicht die Reihenfolge von www-Subdomain und Apex, sonst laufen Zertifikate und Weiterleitungen auseinander. Beobachte außerdem die Propagation nach Änderungen, denn Caches rund um den Globus brauchen je nach TTL etwas Zeit, bis neue Werte erscheinen. Mit einer strukturierten Kontrolle sparst du dir Fehlersuche, und deine Besucher erreichen das Ziel zuverlässig.
Änderungen sauber umsetzen beim Provider
Bevor ich DNS-Records ändere, reduziere ich die TTL, warte die Cache-Laufzeit ab und setze dann die neuen Werte, damit Nutzer zügig die frischen Daten erhalten. Für gängige Hoster existieren klare Oberflächen mit Feldern für A, AAAA, CNAME, MX, TXT und SRV, was planbare Abläufe erlaubt. Falls du dich an einem konkreten Beispiel orientieren möchtest, wirf einen Blick in den kompakten Leitfaden zu DNS-Einstellungen, der die Eingabefelder und typischen Kombinationen zeigt. Nach dem Speichern kontrolliere ich per dig/nslookup, ob Antworten und TTL stimmen, und teste anschließend Web- und E-Mail-Erreichbarkeit über mehrere Netze. So stellst du sicher, dass der Wechsel keine unerwarteten Lücken hinterlässt.
Diagnose in der Praxis: dig- und nslookup-Muster
Für schnelle Checks nutze ich klare Kommandos. Mit dig +trace siehst du die gesamte Auflösungskette bis zum autoritativen Server – ideal, um CNAME-Ketten oder Delegationsprobleme sichtbar zu machen. Mit dig www.deinedomain.de A +ttlunits prüfe ich, welche TTL der Resolver tatsächlich zurückgibt. Und mit dig cname.ziel.tld CNAME erkennst du, ob der Alias auf ein auflösbares Ziel zeigt. Wichtig ist außerdem ein Test mit AAAA, um IPv6 nicht zu vergessen. Auf Windows liefert nslookup ähnliche Ergebnisse; ich setze den Server auf 8.8.8.8 oder 1.1.1.1, um unabhängige Antworten zu bekommen und lokale Caches auszuschließen.
Zertifikate und CNAMEs: was der Browser wirklich prüft
Auch wenn ein Hostname via CNAME auf ein anderes Ziel zeigt, validiert der Browser das Zertifikat immer gegen den ursprünglich aufgerufenen Namen. Das Zertifikat muss daher den Alias-Namen enthalten (SAN/CN), nicht zwingend den Zielhost. Für die Automatisierung nutze ich häufig DNS-01-Challenges: Das Label _acme-challenge kann per CNAME an einen Anbieter delegiert werden, der die Validierung verwaltet, ohne dass ich TXT-Records manuell anpassen muss. Achte nur darauf, dass der CNAME korrekt aufgelöst wird und keine Parallel-Records am gleichen Label liegen.
CDN- und SaaS-Integration: Host-Header und Apex-Strategien
Bei CDNs oder SaaS-Diensten ist der Host-Header entscheidend: Der Zielserver erwartet die originale Domain im HTTP-Header, auch wenn du per CNAME auf einen anderen Hostnamen zeigst. Prüfe, ob dein Anbieter „Custom Domains“ inkl. TLS für deine Hostnamen hinterlegt hat, sonst scheitert SNI. Für die Apex-Domain ohne ALIAS/ANAME arbeite ich mit 301-Weiterleitungen auf www, das als CNAME zum CDN zeigt – so bleibt die Auflösung sauber und SEO konsistent.
Split-Horizon DNS: intern vs. extern
In Unternehmensnetzen nutze ich gern Split-Horizon: Interne Resolver liefern andere Antworten als externe (z. B. private IPs für interne Dienste). Wichtig ist dabei klare Trennung der Zonen und einheitliche Labels. Ich dokumentiere, welche Namen intern abweichen, und verhindere, dass interne Hostnamen versehentlich öffentlich werden. Setze hier sparsam CNAMEs, um Ketten über Zonengrenzen hinweg zu vermeiden, und halte die TTL intern kurz für schnelle Rollouts.
Sicherheit: Dangling CNAMEs und Subdomain-Takeover vermeiden
Besonders kritisch sind dangling CNAMEs auf externe Anbieter, deren Ziel-Endpoint nicht mehr existiert. Angreifer können dann den freien Endpunkt registrieren und unter deiner Subdomain Inhalte ausliefern. Meine Gegenmaßnahmen: Regelmäßig die Zone auditieren, ungenutzte CNAMEs entfernen, externe Abhängigkeiten dokumentieren und bei Projektauslauf die DNS-Einträge aktiv aufräumen. Ergänzend setze ich CAA-Records, um Zertifikatsausstellung zu beschränken, und minimiere Wildcards auf das notwendige Maß.
SEO-Aspekte von Aliasen und Weiterleitungen
DNS-Einträge lösen Namen auf, sie ersetzen keine Weiterleitung, deshalb achte ich zusätzlich auf HTTP-Weiterleitungen und konsistente Canonical-Tags, damit Suchmaschinen die Hauptadresse erkennen. Nutzt du www als CNAME auf die Apex, dann führe alle Nutzer auf eine bevorzugte URL, damit Signale gebündelt ankommen. Für Subdomains, die wie Aliase wirken, beachte ich interne Verlinkung und Canonicals, damit Inhalte nicht doppelt erscheinen und Crawling-Budget sinnvoll bleibt. Praktische Hinweise rund um Aliase und Reichweite findest du im kompakten Beitrag zu Domain-Alias und SEO, der Prioritäten für saubere Strukturen setzt. Halte DNS und SEO getrennt im Blick: DNS löst schnell und verlässlich auf, SEO steuert Sichtbarkeit und Konsistenz.
Zusammenfassung in Klartext
Der A-Record verbindet eine Domain direkt mit einer IPv4-Adresse und liefert Tempo sowie Kontrolle, besonders auf der Apex-Domain mit parallel nötigen MX- und TXT-Einträgen. Der CNAME setzt einen Alias auf einen Hostnamen und glänzt, wenn viele Subdomains auf dasselbe Ziel zeigen sollen oder externe Dienste eingebunden werden. Für Änderungen am Ziel reicht meist ein Griff zum A-Record der Hauptdomain, während alle CNAMEs automatisch folgen und die Pflege klein bleibt. Achte auf kurze Ketten, passende TTLs und vermeide CNAME auf der Apex, wenn dort E-Mail-Einträge liegen, sonst riskierst du Ausfälle. Mit dieser klaren Aufgabenteilung wählst du pro Host den passenden Eintrag, hältst die Zone aufgeräumt und sorgst für schnelle, sichere Auflösung.
