Zum Inhalt springen

FAQ

Wie kann ich Nameserver-Einträge ändern?

Bei allen über hostNET registrierten Domains ist ein kostenloser DNS-Eintrag auf unseren Nameservern enthalten, den Sie selbst ändern können. Auch das Hinzufügen beliebig vieler A-Records, CNAMES oder MX-Einträge ist möglich. Durch Sie vorgenommene Änderungen eines DNS-Eintrags werden innerhalb weniger Minuten auf unseren Nameservern eingetragen. Bis die Änderung wirksam ist, kann aufgrund der Propagationszeit allerdings ein Zeitraum von bis zu 48 Std. vergehen.

Die Änderung Ihrer Domain können Sie in Ihrer Produktauflistung vornehmen, indem der Link "DNS ändern" der jweiligen Domain ausgewählt wird.

Bevor die Änderung in die Nameserver eingetragen wird, erfolgt eine automatische Validierung der neuen Einträge auf korrekte Syntax, so dass ein auf Grund falscher Syntax ungültiger DNS-Eintrag der Domain auf unseren Nameservern praktisch ausgeschlossen werden kann. Dennoch gibt es einige wichtige Regeln, die es zu beachten gilt, da es sonst zum vollständigen Ausfall der Domain inkl. des E-Mail-Verkehrs kommen kann. Nachfolgend erhalten Sie daher einige wichtige Informationen zur Änderung von DNS-Einträgen:

 

 

Wenn Sie im Kundenbereich den DNS einer Domain ändern möchten, müssen Sie das 'IN' aus den hier stehenden Beispielen weglassen. Das Formular braucht nur die relevanten Daten und den Typ des Records.

 

A-Records anlegen und ändern

Das "A" in A-Record steht für "Address". Das bedeutet, dass ein Eintrag dieses Typs immer auf eine IP-Adresse verweisen muss. Ein Verweis auf einen Hostnamen - wie z.B. "example.com" - ist nicht möglich. 

Beispiel eines korrekten A-Records:

example.com.    IN    A    83.138.67.7

Dieser Eintrag lässt die Domain example.com auf die IP-Adresse 83.138.67.7 verweisen, womit die Grundlage der Erreichbarkeit der Domain über den Browser gegeben ist. Aber was passiert, wenn man "www.example.com" aufruft? Sie haben es bereits geahnt: Zunächst passiert nichts, da der Name nicht aufgelöst werden kann. Hierfür ist ein weiterer Eintrag notwendig:

www    IN    A    83.138.67.7

Der sogenannte "$ORIGIN"-Steuereintrag auf dem Nameserver sorgt dafür, dass relative Einträge wie "www" automatisch auf "www.example.com" in der Namensauflösung ergänzt werden. Wenn alle A-Records der Domain auf eine IP-Adresse verweisen sollen, besteht die Möglichkeit mit einer Wildcard zu arbeiten. Der Eintrag sieht dann so aus:

*.example.com.    IN    A    83.138.67.7

Ob es sich um einen relativen oder absoluten Eintrag handelt, wird durch einen abschließenden '.' festgelegt. Wenn Sie z.B. aus Versehen

example.com    IN    A    83.138.67.7

eintragen, dann wird "example.com" auf Grund des fehlenden Punktes als relativer Eintrag gewertet und vom Nameserver automatisch auf "example.com.example.com" ergänzt und "example.com" wäre über den Browser nicht erreichbar.

Nach Oben

 

MX-Records anlegen und ändern

Das "MX" in MX-Record steht für "Mail Exchange". Diese Einträge sind ausschließlich für den E-Mail-Verkehr zuständig. Das besondere an MX-Einträgen ist, dass sich unterschiedliche Prioritäten (Preferences) der MX-Records festlegen lassen, wodurch sich auf einfachem Wege eine Redundanz des empfangenden Mailsystems erreichen lässt. Die Priorität 0 (Null) ist die höchste Preference - häufig sieht man zehner Abstände (0, 10, 20, etc), wenn mehrere Mailserver aktiv sind.

Im einfachsten Fall ist die Domain, an die die E-Mail gesendet werden soll, selbst der Mailserver. Auf dem Nameserver sieht der Eintrag dann so aus:

example.com.    IN    MX    0    mail.example.com.

Wenn Sie bereits den Abschnitt über die A-Records gelesen haben, so wird Ihnen sofort der abschließende Punkt bei "example.com." und "mail.example.com." auffallen. Auch hier gilt die Regel, dass ein Eintrag mit abschließendem Punkt direkt das Ziel beschreibt. Ein Eintrag ohne Punkt ist ein relativer Eintrag (3rd Level) bezogen auf den Domainnamen. Für die MX-Konfiguration kann man z.B. auch Folgendes eintragen:

example.com.    IN    MX    0    mail

Für beide Beispiele ist aber zwingend ein Record mit "mail" notwenig, der als A-Record auf eine IP-Adresse verweisen muss:

mail            IN    A        83.138.67.7

Warum kann man stattdessen nicht einfach

example.com.    IN    MX    0    83.138.67.7

eintragen und den MX-Record direkt auf die IP-Adresse verweisen lassen?
Im allgemein anerkannten Internetstandard RFC 1035 wurde festgelegt, dass das Ziel immer ein Hostname sein muss. Nach diesem Standard verfahren auch die Mailserver. Diese erfragen zunächst die MX-Einträge am Nameservers. Da das Ziel laut obiger RFC immer ein Hostname sein muss, versucht der Mailserver in einem zweiten Schritt diesen Hostnamen auf eine IP-Adresse aufzulösen. Wenn als Ziel aber bereits eine IP-Adresse definiert ist, schlägt die Namensauflösung fehl und die E-Mail kann nicht zugestellt werden.

Grundsätzlich gilt: Wenn die eigene Domain für den E-Mail-Verkehr zuständig ist, muss als Ziel eines MX-Eintrags ein relativer Eintrag (also ohne abschließenden Punkt) angelegt werden, der den passenden A-Eintrag besitzt.

Sie können die E-Mails auch an einen externen Host weiterleiten, in diesem Fall genügt folgender Eintrag:

example.com.    IN    MX    0    mail.peter-mustermann.de.

Der Nameserver der Domain peter-mustermann.de ist dafür verantwortlich, dass ein korrekter A-Record für "mail.peter-mustermann.de" existiert.

Sollte Ihnen nur die IP-Adresse des externen Mailservers bekannt sein, so lässt sich dies wie im weiter oben aufgeführten Beispiel mit einem zusätzlichem A-Eintrag lösen:

example.com.    IN    MX    0    mail

mail            IN    A        127.34.23.8

Hier ist Ihre eigene Domain "mail.example.com" der MX-Hostname des Ziel-Mailservers und verweist auf die externe IP "127.34.23.8". Dies ist aber riskanter, falls der externe Mailserver irgendwann eine andere IP erhält und Sie nicht informiert werden. Deshalb ist auch hier die Variante mit dem Hostnamen als Ziel der bessere Weg.

Zu guter Letzt kann wie bei den A-Records auch bei MX-Records mit Wildcards gearbeitet werden, um mit einem einzigen Namen alle möglichen Namen abzuhandeln:

*.example.com.    IN    MX    0    mail

Alternativ kann dieser Eintrag auch mit folgender Schreibweise vorgenommen werden:

*    IN    MX    0    mail

Da die Wildcard "*" keinen abschließenden Punkt hat, wird auch dieser Eintrag als relativ gewertet und vom Nameserver intern automatisch auf "*.example.com." ergänzt.

Nach Oben

 

CNAME-Records anlegen und ändern

Das "CNAME" in CNAME-Record steht für "Canonical Name". Dies ist ein Alias auf einen kanonischen Namen. Ein kanonischer Name ist ein "offizieller Hostname", d.h. es findet keine weitere Umwandlung auf weitere Namen statt, sondern ausschließlich auf eine IP-Adresse. Daher muss ein CNAME-Eintrag immer auf einen A-Eintrag verweisen.

Einfacher ausgedrückt: Mit einem CNAME lassen sich Subdomains auf andere Domains weiterleiten.

Möchten Sie beispielsweise erreichen, dass Ihre Subdomain "eins.example.com" auf "zwei.example.com" weitergeleitet wird, dann ist folgender DNS-Eintrag notwendig:

eins            IN    CNAME        zwei

zwei            IN    A        83.138.67.7

Der relative Alias "eins" verweist auf den Namen "zwei", der auf die IP-Adresse "83.138.67.7" verweist. Dabei findet eine Umwandlung des aufgerufenen Hostnamens "eins.example.com" auf den kanonischen Namen "zwei.example.com" statt. Dieser verweist dann auf die Ziel-IP-Adresse. Mit dem Befehl "host" lassen sich diese Einträge überprüfen:

[user@home ~]$ host eins.example.com
eins.example.com is an alias for zwei.example.com.
zwei.example.com has address 83.138.67.7

Der CNAME kann auch auf einen externen Hostnamen verweisen:

eins            IN    CNAME        peter-mustermann.de.

Durch den abschließenden Punkt am Ende von "peter-mustermann.de." weiss der Nameserver, dass es sich um einen Alias auf einen externen Host handelt. Ein funktionierender A-Eintrag auf dem Nameserver von "peter-mustermann.de" ist Voraussetzung dafür, dass der CNAME funktioniert. Natürlich ist auch eine Weiterleitung auf eine Subdomain von "peter-mustermann.de" wie z.B.

eins            IN    CNAME        subdomain.peter-mustermann.de.

oder die eigene Domain (im ersten Beispiel "eins.example.com") möglich. Jedoch sollte man darauf achten, dass "subdomain.peter-mustermann.de." bzw. "zwei.example.com" selbst kein CNAME-Eintrag ist, sondern ein A-Record.

Die Konstellation

eins            IN    CNAME        zwei

zwei            IN    CNAME        drei

drei            IN    A        83.138.67.7

sollte vermieden werden. Sie sollten auch auf keinen Fall CNAMES in irgendeiner Form für MX-Einträge verwenden. MX-Einträge müssen immer auf einen kanonischen Namen verweisen, um Endlosschleifen des Mailservers bei der Namensauflösung für den MX-Hostnamen vorzubeugen.

Leider lässt sich mit einem CNAME nicht die gesamte Domain auf einen anderen Host weiterleiten, hierfür gibt es aber folgende Optionen:

  • IP-Adresse der Ziel-Domain in den A-Eintrag eintragen und auf dem Ziel-Webserver einen virtuellen Host einrichten
  • auf eigenen Webserver URL-Weiterleitung mit Hilfe eines redirects oder einer mod_rewrite-Regel in einer .htaccess installieren
  • Weiterleitung mit Hilfe eines Scriptes, z.B. der PHP-header()-Funktion
  • Weiterleitung über HTML und Meta-Tags

Weitergehende Informationen zu URL-Weiterleitungen finden Sie hier.

Nach Oben

 

SPF-Records anlegen und ändern

Das "SPF" in SPF-Record steht für "Sender Policy Framework". Hiermit wird festgelegt, welche Mailserver die Domain für E-Mails als Absender-Domain nutzen darf.

Ein SPF-Eintrag besteht aus der SPF-Versionsnummer "v=spf1", die grundsätzlich erforderlich ist. Anschließend können Regeln definiert werden, anhand derer ein Mailserver, der SPF unterstützt, erkennen kann, ob der versendende Mailserver zum Versenden im Auftrag der Domain autorisiert ist. Die Regeln werden von links nach rechts ausgewertet:

Beispiel eines korrekten SPF-Records:

example.com.    IN    TXT    "v=spf1 ip4:127.34.23.8 -all"

In diesem Fall darf nur der Mailserver 127.34.23.8 im Auftrag der Domain example.com E-Mails versenden. Der empfangende Mailserver erkennt die Regel "ip4:127.34.23.8" und prüft, ob der versendende Mailserver tatsächlich die IP 127.34.23.8 hat. Ist das der Fall, war der Test erfolgreich und die E-Mail wird angenommen. Hat der versendende Mailserver eine andere IP, verläuft der Test auf "ip4:127.34.23.8" negativ und es tritt Mechanismus "-all" in Kraft. "-all" veranlasst den Empfänger, die Überprüfung als "Fail" zu werten. Nur bei dem Ergebnis "Fail" ist es vorgesehen, dass eine E-Mail vom empfangenden Mailserver abgelehnt wird. Wenn die E-Mail von einem falschen Mailserver kommt, ist das Kernziel des SPF erreicht: Der Empfänger-Mailserver nimmt die E-Mail nicht an und es wird keine Bounce-E-Mail (Mailer-Daemon) an den Absender generiert.

Mailer-Daemon-geplagten Domain-Betreibern ist dieses Szenario hinlänglich bekannt. Man erhält "Mailer-Daemons" von E-Mails, die man nie selbst versendet hat. Genau dieses Problem wird mit SPF beseitigt, sofern der empfangende Mailserver eine SPF-Überprüfung durchführt und E-Mails bei einem "Fail" ablehnt.

Würde der Eintrag "~all" lauten, so ergäbe sich ein "SoftFail" und der empfangende Mailserver sollte die E-Mail in jedem Fall annehmen.

Wenn die Domain mehrere Mailserver zum Empfangen von E-Mails betreibt (mehrere MX-Records auf unterschiedliche IPs) und jeder dieser Mailserver auch E-Mails versenden dürfen soll, dann kann der Eintrag so aussehen:

example.com.    IN    TXT    "v=spf1 mx -all"

Man könnte den SPF-Eintrag auch mit mehreren "ip4"-Einträgen (die IP-Adressen der jeweiligen MX-Records) gestalten, um zum gleichen Ergebnis zu kommen:

example.com.    IN    TXT    "v=spf1 ip4:127.34.23.8 ip4:127.34.23.9 -all"

Auch die Angabe eines ganzen IP-Netzes ist in der CIDR-Notation möglich:

example.com.    IN    TXT    "v=spf1 ip4:127.34.23.0/24 -all"

Eine sehr gute Übersicht der weiteren Konfigurationsmöglichkeiten finden Sie unter

www.openspf.org/SPF_Record_Syntax

Nach Oben

 

Was ist eine MX-Priorität?

Die MX-Priorität beschreibt die Wichtigkeit eines MX-Records auf dem Nameserver. Je niedriger der Präferenzwert, umso höhere Priorität hat der Eintrag. Ein Mailserver fragt zunächst immer den MX-Eintrag mit dem niedrigsten Präferenzwert ab und versucht, an diesen die E-Mail zuzustellen. Reagiert der Mailserver nicht, so wird der nächsthöhere Eintrag genommen. Auf diesem Wege lässt sich über das DNS eine Redundanz des empfangenden Mailsystems erzeugen.

Nach Oben

 

Was ist ein Alias-Record?

Ein Alias-Record ist ein anderer Ausdruck für CNAME-Record - nicht zu verwechseln mit dem A-Record (Address-Record).

Nach Oben

 

Warum muss ein A-Record auf eine IP-Adresse verweisen?

"A" wie "Adresse"! In Adress-Einträge gehören ausschließlich IP-Adressen.

Nach Oben

 

Warum muss ein MX-Record auf einen Hostnamen verweisen?

Der allgemein anerkannte Internetstandard RFC 1035 besagt, dass das Ziel immer ein Hostname sein muss. Nach diesem Standard verfahren auch die Mailserver. Da das Ziel immer ein Hostname sein muss, versucht der Mailserver, den Hostnamen auf eine IP-Adresse aufzulösen. Wenn als Ziel aber bereits eine IP-Adresse definiert ist, schlägt die Namensauflösung fehl und die E-Mail kann nicht zugestellt werden. Es gibt mittlerweile Mailserver, die mit diesem Konfigurationsfehler umgehen können, verlassen kann man sich darauf jedoch nicht.

Nach Oben

 

Wie lange dauert es, bis eine Nameserveränderung wirksam ist?

Eine DNS-Änderung ist innerhalb von 24-48 Stunden wirksam. Weitere Informationen zu diesem Zeitraum, der auch Propagationszeit genannt wird, finden Sie hier.

Nach Oben

 

Was ist DNS-basiertes Loadbalancing?

Existieren für einen Hostnamen mehrere A-Records, die auf verschiedene IP-Adressen wie z.B.

roundrobin.example.com.    IN    A    127.34.23.1

roundrobin.example.com.    IN    A    127.34.23.2

roundrobin.example.com.    IN    A    127.34.23.3

verweisen, erhält der Host "roundrobin.example.com" insgesamt drei IP-Adressen. Der Traffic wird sich auf diese drei IP-Adressen aufteilen. Damit lässt sich mit sehr einfachen Mitteln eine Lastaufteilung erzielen, die aber nur begrenzt nutzbar ist.

Ursache ist das DNS-Caching, das weltweit angewandt wird, um den DNS-Traffic in Grenzen zu halten und die DNS-Server zu entlasten. Theoretisch kann man zwar die TTL (Time to Live) des DNS-Eintrags herabsetzen. Dies wird aber von vielen Caching DNS-Servern ignoriert und funktioniert daher nicht zuverlässig. DNS-basiertes Loadbalancing existiert, aber verzichten Sie am Besten darauf.

Nach Oben

 

Was ist ein PTR-Record?

Genauso wie sich Hostnamen auf IP-Adressen auflösen lassen, lassen sich auch IP-Adressen auf Hostnamen auflösen. Dies wird mit einem PTR-Record (Pointer Record), auch reverse lookup genannt, realisiert. Welcher Nameserver für PTR-Records zuständig ist, wird bei der zuständigen IP-Adressen-Registrierungsstelle hinterlegt. Für den europäischen Raum ist das die RIPE.

Die hostNET Medien GmbH als offizielles RIPE-Mitglied legt für Ihren hostNET-Server automatisch einen PTR-Record an. Der Hauptgrund für diesen Eintrag ist, dass viele Mailserver E-Mails von Mailservern, die einen PTR-Record nicht aufweisen können, ablehnen.

Nach Oben

 

Wie überprüfe ich, ob ein DNS-Eintrag korrekt angelegt ist?

Zum Überprüfen von DNS-Einträgen sind für technisch interessierte Menschen die Kommandozeilenprogramme "host", "nslookup" und "dig" geeignet. Eine Überprüfung lässt sich aber auch bequem über den Webbrowser z.B. mit dem Nameserver Predelegation Check Webinterface der DENIC durchführen.

Zurück

Sie brauchen Hilfe?

0421 4089-000