Hauptnavigation:

Sie sind hier: Home > HINTERGRUND > Nameservice > Nameserver- und NSentry-Einträge

Nameserver- und NSentry-Einträge

Es gibt zwei Möglichkeiten, die Erreichbarkeit einer .de-Domain sicherzustellen (die Domain zu "konnektieren"):

  1. Bei einer Delegation werden die relevanten Resource Records (RRs) auf zwei oder mehr für diese Domain (genaugenommen sollte man hier bereits von der "Zone" sprechen) zuständigen Nameservern vorgehalten. Anfragen für eine delegierte Domain werden von den .de-Nameservern an diese Server verwiesen. Nameserver und Zonen müssen eine Reihe technischer Voraussetzung erfüllen. In der .de-Zone stehen für delegierte Zonen nur die verweisenden NS-Records sowie künftig ggf. weitere Infrastrukturdaten.
  2. Alternativ können die Daten auch direkt in der .de-Zone geführt werden. Bei dieser Option ist die Bereitstellung eigener Nameserver nicht notwendig, die publizierbaren Resource Records unterliegen allerdings gewissen Einschränkungen:
  • Es können maximal fünf Resource Records pro .de-Domain direkt in die .de-Zone eingetragen werden. (Minimum: ein RR)
  • Dabei werden nur Records der Typen A (IPv4-Adressen) und MX (Mail eXchanger) unterstützt.
  • Diese A- und MX-Records werden weiteren technischen Prüfungen unterzogen.

Voraussetzungen bei direkten Einträgen

Es sind bis zu fünf NSentries ("A" bzw. "MX" Einträge) möglich. Die Syntax eines NSentry muss dem folgenden Aufbau folgen:

Aufbaus eines NSentry:

domain.de. A <IP-Adresse>

subdomain.domain.de. A <IP-Adresse>

domain.de.  MX <Präferenz> <Hostname des Mailservers>

*.domain.de. MX <Präferenz> <Hostname des Mailservers>

Als NSentry ist ausschließlich die Domain erlaubt, für welche der Auftrag geschickt wird.

Für Address-Records (IN A) gilt: Es ist jede Sub-Domain möglich, die auch die Anforderungen an einen Hostname (gem. RFC952 / RFC1123) erfüllt. Nicht erlaubt ist die Angabe von Wildcards durch *. Das Format der IP-Adresse ist u.a. definiert in RFC1180, Pkt. 5.4 ff. IP-Adressen von internen Netzen (gem. RFC1597) sowie localhost dürfen nicht verwendet werden. Im Rahmen des Load-Balancing ist es jedoch möglich, gleiche NSentries mit unterschiedlichen IP-Adressen anzugeben.

Bei Mail-Exchange-Records (IN MX) gilt: Als Präferenzwerte sind alle Angaben zwischen "0" und "999" möglich, wobei "0" die höchste und "999" die niedrigste Präferenz hat. Wildcards sind bei Mail-Exchange-Records erlaubt. Der Name des Mailservers, der im Mail-Exchange-Record angegeben wird, muss die entsprechenden Vorgaben für gültige Hostnamen (gem. RFC952, RFC1123) erfüllen. Es ist zu beachten, das die Top Level Domain des Mailservers eine existente TLD sein muss. Folglich sind Mail-Exchange-Records, die
auf localhost verweisen, nicht erlaubt.

Für den Mailserver muss ein entsprechender Address-Record vorliegen. Falls der Mailserver in der beantragten Domain steht, muss der entsprechende Address-Record im Antrag enthalten sein.
Beispiel:

denic.de. MX 10 mailer.denic.de.
mailer.denic.de. A 192.0.2.42
Generelle Anforderung
Alle im Auftrag angegebenen Nameserver müssen erreichbar und für die beantragte Zone autoritativ sein.
Redundante Anbindung

  • Es sind mindestens zwei Nameserver erforderlich, die über IPv4 angebunden sind. Für jeden Nameserver werden dessen sämtliche IPv4- und IPv6-Adressen für die weitere Prüfung ermittelt bzw. gegebenenfalls dem Auftrag entnommen. Es muss mindestens einen Nameserver im Auftrag geben, dessen sämtliche IPv4-Adressen sich komplett von sämtlichen IPv4-Adressen sämtlicher anderer Nameserver desselben Auftrags unterscheiden.

Beispiel:
erlaubt: Nameserver1 mit der IP-Adresse: 192.0.2.1 und Nameserver2 mit der IPAdresse: 192.0.2.3

  • Eventuell vorhandene IPv6-Adressen können nicht zur Erfüllung des Redundanzgebotes herangezogen werden.

Glue-Records

  • Falls der Nameserver innerhalb der Domain steht, die beantragt wird, muss mindestens eine IPv4 bzw. IPv6-Adresse mit angegeben werden (Glue Record).
  • Soll ein Nameserver mit einem oder mehreren IPv6-Glue-Records eingetragen werden, sollte dieser zusätzlich über mindestens eine IPv4-Adresse verfügen.
  • Unter jeder im Auftrag angegebenen IP-Adresse (v4 bzw. v6) eines Nameservers müssen dessen A- und AAAA-RRSet unmittelbar, vollständig, konsistent und autoritativ ermittelbar sein und mit den Daten im Auftrag übereinstimmen.

Anforderungen an die SOA-Daten in der Zone

  • Die SOA-Seriennummern der Zonen auf allen Nameservern sollen übereinstimmen
  • Für folgende SOA-Werte werden Richtwerte vorgegeben:

Als Richtwert von "Refresh" gilt: 3600 – 86400 (in Sekunden)
Als Richtwert von "Retry" gilt: 900 – 28800 (in Sekunden), wobei "Retry" soll zwischen 1/8 und 1/3 von "Refresh" betragen
Als Richtwert von "Expire" gilt: 604800 – 3600000 (in Sekunden)
Als Richtwert von "negTTL" gilt: 180 - 86400 (in Sekunden).

Anforderungen an weitere Daten in der Zone

  • Das NS-RRSet muss exakt mit der im Auftrag angegebenen Liste der Nameserver übereinstimmen. Für die beantragte Zone (genauer: am Zonen-Apex) darf kein CNAME-RR existieren.
  • Die Referral-Response muss (bei maximal langem QNAME und inkl. sämtlicher notwendiger Adressinformationen einschl. Glue-Records) in ein DNS-UDP-Paket passen, darf also 512 Bytes nicht überschreiten.
  • Die Angabe des Primary Nameservers im SOA -RR der beantragten Zone soll auf allen Nameservern übereinstimmen.

Sonstige Vorgaben an die Nameserver

IPv6-Adressen müssen aus einem Adressraum von der IANA stammen, der als Global Unicast gewidmet, als ALLOCATED markiert und routbar ist. Dies gilt für alle IPv6-Adressen der angegebenen Nameserver, unabhängig davon, ob es sich um einen Glue-Record handelt.