A-Record setzen: Anleitung mit Zone-File und dig-Test

Aktualisiert: 5 Min. Lesezeit Redaktion vserverhost
Kurz gesagt

Einen A-Record setzt du in der DNS-Verwaltung deiner Domain: Als Name trägst du @ für die Domain selbst oder die Subdomain ein (etwa www), als Typ A, als Wert die IPv4-Adresse des Servers und als TTL zum Beispiel 3600 Sekunden. Ob der Eintrag aktiv ist, prüfst du mit dig example.com A +short.

Ein A-Record ist der einfachste Eintrag im DNS, und trotzdem geht beim ersten Mal erstaunlich oft etwas schief. Selten am Eintrag selbst. Meistens am Namensfeld, an einem alten Parking-Eintrag, der noch daneben steht, oder an einer TTL, die das Umstellen um einen Tag verzögert.

Was ein A-Record ist

Ein A-Record (Address Record, definiert in RFC 1035) verknüpft einen Hostnamen mit genau einer IPv4-Adresse. Für IPv6 gibt es den AAAA-Record, der genauso funktioniert. Ein Eintrag besteht aus vier Feldern:

FeldBeispielBedeutung
Name@, www, appFür welchen Hostnamen der Eintrag gilt
TTL3600Wie viele Sekunden Resolver ihn cachen dürfen
TypAIPv4-Adresse
Wert192.0.2.10Die Adresse selbst, ohne Port, ohne http://

Im Zone-File sieht das so aus:

$ORIGIN example.com.
@      3600  IN  A  192.0.2.10
www    3600  IN  A  192.0.2.10
app     300  IN  A  198.51.100.20

A-Record setzen: die vier Felder richtig ausfüllen

Das Namensfeld

Hier passieren die meisten Fehler. Panels unterscheiden sich darin, was sie erwarten:

  • @ oder leeres Feld meint die Domain selbst (example.com).
  • www meint www.example.com. Trägst du www.example.com ein, machen manche Panels daraus www.example.com.example.com.
  • Ein Punkt am Ende (www.example.com.) bedeutet im Zone-File „vollständiger Name“. Ohne Punkt wird die Zone angehängt.

Ob dein Panel den Namen relativ oder absolut interpretiert, siehst du nach dem Speichern an der Anzeige. Im Zweifel einmal mit dig gegenprüfen.

Der Wert

Nur die nackte IPv4-Adresse. Keine Protokolle, keine Ports, keine Leerzeichen. Bei VServern mit NAT (manche Cloud-Anbieter) ist die Adresse in ip addr privat, die öffentliche steht im Panel.

Die TTL

Für einen Server, dessen IP sich selten ändert, sind 3600 Sekunden ein guter Wert. Planst du in den nächsten Tagen einen Umzug, nimm 300. Warum niedrige TTLs nicht automatisch besser sind, steht im Artikel zur DNS-TTL.

Wo du den A-Record einträgst

Den Eintrag setzt du dort, wo die Nameserver der Domain hinzeigen, nicht zwangsläufig beim Hoster des Servers. Welche das sind, verrät:

dig NS example.com +short

Zeigen die Nameserver auf deinen Registrar, pflegst du den Eintrag dort. Bei betadomain liegen die DNS-Einträge im Kundenbereich direkt bei der Domain. Zeigen sie auf einen anderen Dienst, ist der Eintrag beim Registrar wirkungslos, auch wenn das Panel ihn anstandslos speichert. Dieser Fall kostet Leute regelmäßig einen halben Tag.

Prüfen, ob der A-Record aktiv ist

Zuerst direkt beim autoritativen Nameserver, damit kein Cache dazwischenfunkt:

dig @ns1.example-dns.net example.com A +noall +answer
example.com.		3600	IN	A	192.0.2.10

Dann über einen öffentlichen Resolver:

dig @9.9.9.9 example.com A +short
host www.example.com
www.example.com has address 192.0.2.10

Gibt der autoritative Server die neue IP aus und der öffentliche Resolver noch die alte, ist der Eintrag korrekt. Die TTL in der Antwort des Resolvers zählt herunter und zeigt dir, wie viele Sekunden der alte Wert noch gilt. Mehr dazu unter DNS-Propagation.

Typische Fehler beim A-Record

Zwei A-Records für denselben Namen. Die Domain liefert abwechselnd zwei IPs, eine davon ist meist ein alter Parking-Server. Das sieht im Browser aus wie ein Wackelkontakt.

dig example.com A +short
192.0.2.10
198.51.100.7

Lösche den alten Eintrag.

A-Record und CNAME für denselben Namen. Nicht erlaubt. Wer www als CNAME angelegt hat, kann dort keinen A-Record mehr setzen. Welche Variante wann sinnvoller ist, erklärt der Vergleich CNAME oder A-Record.

Wildcard-Eintrag überdeckt nichts. Ein *-A-Record gilt nur für Namen, die nicht explizit existieren. Hast du app als TXT angelegt, greift die Wildcard für app nicht mehr, und app.example.com hat keine A-Antwort.

Mail bricht weg. Der A-Record hat mit Mail nichts zu tun, solange der MX-Record auf einen eigenen Namen zeigt. Zeigt der MX aber auf example.com selbst, landet nach dem Ändern des A-Records auch die Mail auf dem neuen Server. Prüfe vorher mit dig MX example.com +short. Wie Mail-DNS sauber aussieht, steht unter MX-Record einrichten.

Subdomains, Wildcards und mehrere IPs

Für jede Subdomain, die auf einen anderen Server soll, setzt du einen eigenen A-Record:

api     3600  IN  A  198.51.100.20
*.dev   3600  IN  A  192.0.2.10

Die Wildcard *.dev fängt feature1.dev.example.com, test.dev.example.com und so weiter ab. Praktisch für Preview-Umgebungen, die ein Reverse Proxy auf dem Server verteilt. Ein passendes Zertifikat bekommst du dann nur per DNS-Challenge, siehe Wildcard-Zertifikat.

Mehrere A-Records mit gleichem Namen sind DNS-Round-Robin. Das verteilt Last, erkennt aber keine Ausfälle. Für zwei Server ohne Load Balancer ist es ein brauchbarer Notbehelf, mehr nicht.

A-Record oder Failover-IP beim Hoster

Wenn du einen Server häufiger tauschst, etwa weil du Images neu ausrollst, wird das ständige Umstellen des A-Records lästig. Viele VServer-Anbieter verkaufen dafür zusätzliche IPs, die du per Panel oder API zwischen Servern verschieben kannst (die Namen variieren: Floating IP, Failover-IP, Reserved IP). Der A-Record zeigt dann dauerhaft auf diese Adresse, und der Wechsel passiert beim Hoster in Sekunden, ohne dass eine TTL abläuft.

Für einen einzelnen Server mit seltenen Umzügen ist das unnötig. Wenn du aber schon zweimal im Jahr umziehst, rechnet sich der kleine Aufpreis schnell, weil du dir die TTL-Planung sparst. Die zusätzliche Adresse musst du auf dem Server im Netzwerk-Interface eintragen, sonst kommen die Pakete zwar an, werden aber verworfen.

Prüfliste nach dem Setzen

  • dig @<autoritativer-NS> example.com A +short zeigt die neue IP.
  • dig example.com A +short liefert genau eine Zeile, nicht zwei.
  • curl -sI http://example.com kommt von deinem Server (Header Server: prüfen).
  • Der MX-Record zeigt weiterhin dorthin, wo Mail hin soll.
  • Die TTL ist so gewählt, wie du sie für die nächsten Wochen brauchst.

Nächster Schritt

Wenn der A-Record steht, kommt der Webserver dran: virtueller Host, dann das Zertifikat. Die komplette Reihenfolge zeigt die Anleitung Domain auf Server umleiten.

Brauchst du für ein Projekt eine neue Domain, kannst du bei betadomain nachsehen, ob der Name frei ist. Die aktuelle Preisliste zeigt Jahrespreise für rund 490 Endungen, eine .com registrieren kostet 14,99 € im Jahr, und die A-Records setzt du anschließend im selben Kundenbereich.

Schritt für Schritt

  1. DNS-Verwaltung öffnenIm Kundenbereich des Registrars oder DNS-Anbieters die Zone der Domain öffnen.
  2. Name festlegen@ oder leer für die Domain selbst, sonst den Subdomain-Teil wie www oder app eintragen, ohne die Domain anzuhängen.
  3. Typ A und IPv4-Adresse eintragenTyp A wählen und die öffentliche IPv4-Adresse des Servers eintragen, zum Beispiel 192.0.2.10.
  4. TTL wählen3600 Sekunden für stabile Einträge, 300 Sekunden, wenn der Wert bald wieder geändert wird.
  5. Mit dig prüfendig example.com A +short gegen den autoritativen Nameserver und gegen einen öffentlichen Resolver ausführen.

Domain gefunden? Prüfen und registrieren kannst du sie direkt bei betadomain – Jahrespreis ab 2,99 €.

Häufige Fragen

Was bedeutet das @ beim A-Record?

Das @ steht im Zone-File für den Ursprung der Zone, also die Domain selbst ohne Subdomain. Manche Panels erwarten stattdessen ein leeres Feld oder den vollen Namen. Gemeint ist in allen drei Fällen dasselbe.

Kann ein A-Record auf mehrere IP-Adressen zeigen?

Ja, du legst dafür mehrere A-Records mit demselben Namen an. Resolver liefern dann alle Adressen, und Clients wählen eine davon. Das ist eine einfache Lastverteilung ohne Health-Check: Fällt ein Server aus, landet ein Teil der Besucher trotzdem dort.

Kann ich beim A-Record einen Port angeben?

Nein. Ein A-Record enthält ausschließlich eine IPv4-Adresse. Ports löst du auf dem Server, typischerweise mit einem Reverse Proxy, der auf 80 und 443 lauscht.

Darf neben einem A-Record ein CNAME mit demselben Namen existieren?

Nein. Ein CNAME schließt alle anderen Einträge für denselben Namen aus. Die meisten Panels verweigern die Kombination, manche überschreiben stillschweigend den bestehenden Eintrag.