---
id: "dns-record"
kind: "glossary-term"
title: "DNS-Record"
language: "de"
category: "DNS und technische Grundlagen"
updated: "2026-10-10T23:12:43Z"
canonical: "https://tldlog.com/de/glossar/dns-record/"
translations:
  en: "https://tldlog.com/glossary/dns-record/"
  es: "https://tldlog.com/es/glosario/registro-dns/"
  fr: "https://tldlog.com/fr/glossaire/enregistrement-dns/"
  it: "https://tldlog.com/it/glossario/record-dns/"
  pt-BR: "https://tldlog.com/pt/glossario/registro-dns/"
  ru: "https://tldlog.com/ru/glossariy/zapis-dns/"
  zh-Hans: "https://tldlog.com/zh/cihui/dns-jilu/"
---

# DNS-Record

Ein einzelner Eintrag in einer DNS-Zone. Er hat einen Namen, einen Typ wie A, MX oder TXT, eine TTL und die eigentlichen Daten, zum Beispiel eine IP-Adresse. Alle Records mit demselben Namen und Typ bilden eine Menge, die immer gemeinsam beantwortet und signiert wird.

Ein DNS-Record (DNS-Eintrag) ist ein einzelner Eintrag in der DNS-Zone einer Domain. Jeder Record beantwortet eine Frage zu einem Namen, etwa welcher Server die Website bereitstellt oder wohin E-Mails gehen sollen. Domaininhaber bearbeiten meist einige wenige Records über ihren DNS-Anbieter, und ein einziger falscher Record kann eine Website oder die E-Mail lahmlegen.

## Was ein DNS-Record ist: Name, Typ, TTL und Daten

Jeder Record besteht aus denselben Teilen: dem Namen, zu dem er gehört (etwa `www.example.com`), einem Typ (A, MX, TXT und so weiter), einer TTL und den eigentlichen Daten, etwa einer IP-Adresse.

Die TTL ist die Zahl der Sekunden, die ein Resolver die Antwort aufbewahren darf, bevor er neu fragt. Sie ist eine Obergrenze, kein Versprechen. Nach einer Änderung sehen manche Nutzer den alten Wert, bis die alte TTL abgelaufen ist; das nennt man umgangssprachlich DNS-Propagation.

Records mit demselben Namen und Typ bilden ein Resource Record Set (RRset). Eine Abfrage liefert immer das ganze Set, alle seine Records müssen dieselbe TTL haben, und DNSSEC signiert das Set als Einheit.

## Die Records, die die meisten Inhaber brauchen: A, AAAA, CNAME, MX und TXT

- **A** verweist einen Namen auf eine Adresse im Internet Protocol Version 4 (IPv4). Mehrere Adressen bedeuten mehrere A-Records.
- **AAAA** tut dasselbe für die neuere, längere Version 6 (IPv6).
- **CNAME** macht einen Namen zum Alias für genau einen anderen Namen, und die Abfrage beginnt dort neu. Neben einem Alias dürfen keine anderen Daten stehen, außer DNSSEC-Records.
- **MX** nennt die Mailserver einer Domain, jeweils mit einer Präferenzzahl; niedrigere Zahlen werden zuerst versucht. Das Ziel muss ein echter Hostname sein, nie ein Alias. Gibt es gar keinen MX, greifen sendende Server auf die A- oder AAAA-Records der Domain zurück. Eine Domain, die keine E-Mails annimmt, kann einen „Null MX“ veröffentlichen: Präferenz 0 und ein einzelner Punkt als Ziel.
- **TXT** enthält Text, dessen Bedeutung davon abhängt, wo er veröffentlicht ist. Dienste verlangen oft einen TXT-Wert als Nachweis, dass man eine Domain kontrolliert. SPF muss als TXT veröffentlicht werden, mit nur einem SPF-Record pro Name. Eine DMARC-Richtlinie ist ein TXT-Record unter `_dmarc.example.com`.

## Records, die die Zone steuern: NS und SOA

NS-Records listen die autoritativen Nameserver einer Zone auf. Sie stehen an der Spitze der Zone und zusätzlich in der übergeordneten Zone, etwa der TLD-Zone, wo sie die Delegation markieren und Resolvern sagen, wo sie als Nächstes fragen sollen. Sie müssen auf echte Hostnamen zeigen, nicht auf Aliasse.

Jede Zone hat genau einen SOA-Record (Start of Authority), an ihrer Spitze. Er enthält den primären Server, das Postfach der verantwortlichen Person, eine Seriennummer und Zeitwerte in Sekunden. Sekundäre Server holen neue Daten nur, wenn die Seriennummer steigt. Sein Feld MINIMUM legt heute zusammen mit der eigenen TTL des SOA fest, wie lange Antworten vom Typ „existiert nicht“ zwischengespeichert werden. DNS-Anbieter verwalten den SOA meist für ihre Kunden.

## Spezielle Records: SRV, PTR, CAA, HTTPS und Wildcards

- **SRV** gibt Server und Port für einen Dienst an, unter einem Namen wie `_service._protocol.example.com`. Clients versuchen zuerst die niedrigste Priorität und verteilen die Last nach Gewichtung. Das Ziel darf kein Alias sein.
- **PTR** ordnet eine Adresse wieder einem Namen zu. Reverse-Records liegen unter in-addr.arpa (IPv4) und ip6.arpa (IPv6), Zonen, die der Struktur der IP-Adressen folgen, nicht der von Domainnamen; sie werden daher nicht in der eigenen Zone einer Domain gesetzt. Betriebliche Empfehlungen sagen, PTR- und A-Records sollten übereinstimmen.
- **CAA** (Certification Authority Authorization) listet die Zertifizierungsstellen auf, die Zertifikate für einen Namen ausstellen dürfen. Zertifizierungsstellen, die dem Standard folgen, müssen ihn vor der Ausstellung prüfen und dabei bei Bedarf zu übergeordneten Namen aufsteigen; ein CAA bei example.com gilt also auch für `www.example.com`, wenn www keinen eigenen hat. Browser dürfen ihn nicht zur Prüfung von Zertifikaten verwenden.
- **SVCB und HTTPS** sagen Clients schon vor dem Verbindungsaufbau, welche Server, Protokolle und Ports sie nutzen sollen. HTTPS ist die Variante für das Web; der Name bezeichnet den Record-Typ, nicht das Protokoll.
- **Wildcards** beginnen mit dem Label `*`, wie in `*.example.com`. Sie antworten nur für Namen, die überhaupt nicht existieren, nur mit den Typen, die sie enthalten, und nicht für Namen unterhalb ihrer selbst. Stand Oktober 2026 verbietet das am 21. Januar 2024 gebilligte Base Registry Agreement der ICANN gTLD-Registrys, Wildcards oder eine andere Methode zu verwenden, um für nicht registrierte Namen zu antworten: Solche Anfragen müssen NXDOMAIN liefern.

## Warum ein CNAME nicht auf der Stammdomain stehen kann, und ALIAS als Ausweg

Die Stammdomain (die Spitze der Zone, Zone Apex) muss die SOA- und NS-Records enthalten, und ein CNAME darf seinen Namen nicht mit anderen Daten teilen. Ein CNAME dort gerät mit ihnen in Konflikt: Manche Server ignorieren dann die NS-Records, und die Domain funktioniert nicht mehr.

Die Standardlösung sind A- und AAAA-Records auf der Stammdomain. Ein HTTPS-Record im „AliasMode“ kann die Stammdomain ebenfalls auf einen anderen Namen verweisen lassen, doch Clients, die ihn nicht unterstützen, ignorieren ihn, deshalb müssen die A- und AAAA-Records bleiben.

Viele DNS-Anbieter bieten eine eigene Funktion an, genannt ALIAS, ANAME oder CNAME-Flattening: Der Anbieter schlägt das Ziel nach und antwortet mit dessen Adressen. Stand Oktober 2026 sind diese Funktionen proprietär. Der Entwurf zur Standardisierung von ANAME ist abgelaufen, und das IANA-Register der Record-Typen enthält keinen Typ ALIAS oder ANAME. Das Verhalten unterscheidet sich, was einen Anbieterwechsel oder die Nutzung mehrerer Anbieter erschwert.

## Häufige Fehler beim Bearbeiten von Records und wie man sie prüft

- Den abschließenden Punkt eines vollständigen Namens in einer Zonendatei weglassen, sodass der Zonenname angehängt wird: `mail.example.com.example.com`.
- Ein CNAME neben anderen Records oder auf der Stammdomain.
- Ein MX-, NS- oder SRV-Record, der auf einen CNAME zeigt.
- Zwei SPF-Records unter demselben Namen.
- Die SOA-Seriennummer nicht erhöhen, wenn man eine Zonendatei von Hand bearbeitet.
- CNAMEs, die noch auf einen entfernten Host zeigen, oder CNAMEs, die auf CNAMEs zeigen.
- Eine TTL erst nach einer Änderung senken: Caches können die alte Antwort bis zum Ablauf der alten TTL behalten.

Nach jeder Änderung den Record mit einem Abfragewerkzeug wie `dig` prüfen. Eine direkte Abfrage beim autoritativen Server zeigt den neuen Wert unabhängig von Caches. Wer nicht sicher ist, welche Records ein Dienst braucht, fragt beim DNS-Anbieter nach.

## Quellen

- [Domain names - implementation and specification (RFC 1035)](https://www.rfc-editor.org/rfc/rfc1035.txt)
- [Clarifications to the DNS Specification (RFC 2181)](https://www.rfc-editor.org/rfc/rfc2181.txt)
- [Common DNS Operational and Configuration Errors (RFC 1912)](https://www.rfc-editor.org/rfc/rfc1912.txt)
- [Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records) (RFC 9460)](https://www.rfc-editor.org/rfc/rfc9460.txt)
- [Address-specific DNS aliases (ANAME), draft-ietf-dnsop-aname-04](https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/)

## verwandte begriffe

- [Zonendatei](https://tldlog.com/de/glossar/zonendatei/)
- [TTL](https://tldlog.com/de/glossar/ttl/)
- [A-Record](https://tldlog.com/de/glossar/a-record/)
- [SOA-Record](https://tldlog.com/de/glossar/soa-record/)
- [RRSIG](https://tldlog.com/de/glossar/rrsig/)
