2. Nameserver Predelegation Check
2.1 Warnungen und Fehlermeldungen des Nameserver Predelegation Checks (Nameserver-Policy)
Obligatorisch zu erfüllende Anforderungen werden mit "muss" oder "darf nicht" beschrieben, ein Verstoß führt zur Ausgabe von ERROR.
Empfehlungen werden mit "soll" beschrieben, ein Verstoß führt zur Ausgabe von WARNING.
2.1.1 Generelle Anforderung
Alle im Auftrag angegebenen Nameserver müssen erreichbar und für die beantragte Zone autoritativ sein [sonst Ausgabe von ERROR].
Erläuterung: Da der Betreiber des Nameservers sich sowohl vom Domaininhaber als auch vom verwaltenden Mitglied unterscheiden kann und darum im Rahmen der Domaindelegation kein Vertragspartner der DENIC ist, eine Delegation aber zu seinen Lasten geht, wird auf diesem Wege das Einverständnis mit dieser Delegation unterstellt, wenn die Zone autoritativ bedient wird. Im übrigen entspricht die Vorabprüfung dem Geist und Text der RFCs 1034 und 1035.
2.1.2 Redundante Anbindung
1. Es sind mindestens zwei Nameserver erforderlich, von denen mindestens ein Nameserver über IPv4 angebunden sein muss. 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 IP-Adresse sich von den IP-Adressen sämtlicher anderer Nameserver desselben Auftrags unterscheidet [sonst Ausgabe von ERROR].
Erläuterung: RFC 1035 sieht ausdrücklich vor, dass aus Redundanzgründen jede DNS-Zone von mindestens zwei unabhängigen Nameservern versorgt wird. Zur Vermeidung von negativen Effekten für die TLD-Server (siehe RFC 4697) bei der Nichterreichbarkeit der Nameserver einer delegierten Zone wird besonderer Wert auf die Diversität in der Netztopologie gelegt.
Beispiel:
erlaubt:
a. Nameserver1 mit der IP-Adresse: 192.0.2.1 und Nameserver2 mit der IP-Adresse: 198.51.100.1
b. Nameserver1 mit der IP-Adresse: 192.0.2.1 und Nameserver2 mit der IP-Adresse: 2001:db8:85a3::8a2e:370:7334
nicht erlaubt:
c. Nameserver1 mit der IP-Adresse: 192.0.2.1 und Nameserver2 mit der IP-Adresse: 192.0.2.1
d. Nameserver1 mit IP-Adresse: 2001:db8:85a3::8a2e:370:7334 und Nameserver2 mit der IP-Adresse: 2001:db8:85a3::8a2e:370:7336
2.1.3 Glue-Records
1. Grundsätzlich gilt die Narrow Glue Policy: Glue-Records werden dann und nur dann in die .de-bzw. 9.4.164.arpa Zone eingetragen, wenn der Name eines Nameservers innerhalb der delegierten Domain liegt.
a. Liegt der Nameserver innerhalb der zu delegierenden Domain, muss mindestens eine IPv4- oder IPv6-Adresse (A-/AAAA-RRSet) angegeben werden [sonst Ausgabe von ERROR].
Erläuterung: In der angegebenen Konstellation ist in jedem Fall mindestens ein Glue-Record erforderlich.
b. Liegt der Nameserver nicht innerhalb der zu delegierenden Domain, und es wird trotzdem mindestens eine IP-Adresse (v4 oder v6) dazu im Auftrag
angegeben, werden diese IP-Adressen bei der Ausführung des Auftrags nicht berücksichtigt [sonst Ausgabe von WARNING].
Erläuterung: Die DENIC wendet sowohl für .de als auch für 9.4.e164.arpa die „Narrow Glue Policy“ an, erlaubt also Glue-Records nur im eng begrenzten Fall, dass der Nameserver innerhalb der delegierten Zone liegt. Zusätzlich angegebene Adressen sind überflüssig und werden nicht übernommen. Die Warnung soll auf mögliche Eingabefehler hinweisen.
2. Unter jeder im Auftrag angegebenen und berücksichtigten (vergl. 2.1.3, Absatz1, a und b) 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 [sonst Ausgabe von ERROR].
Erläuterung: Da die Glue-Daten mit den autoritativen Daten koexistieren, muss sichergestellt werden, dass sie konsistent sind, die Adressangaben in den GlueRecords also mit den auf „normalem Wege“ ermittelten autoritativen Daten übereinstimmen. Des Weiteren gebietet die Konsistenz, RRSets (Record Sets, also ein oder mehrere Records gleichen Typs) immer vollständig anzugeben, nicht etwa nur eine von zwei Adressen eines Nameservers für die Glue-Records zu verwenden. Schließlich wird die „Narrow Glue Policy“ sowohl auf IPv4 als auch auf IPv6 angewandt, d.h. wenn entsprechende Records-Sets (A oder AAAA) in den autoritativen Daten existieren, müssen sie in Glue-Records bereitgestellt werden.
2.1.4 Anforderungen an die SOA-Daten in der Zone
1. Entfällt: Die SOA-Seriennummern der Zonen auf allen Nameservern sollen übereinstimmen [sonst Ausgabe von WARNING].
2. Für folgende SOA-Werte werden Richtwerte vorgegeben:
a. "Refresh" soll in folgendem Bereich liegen: 3600 – 86400 (in Sekunden) [sonst Ausgabe von WARNING].
Erläuterung: Dieser Wert bestimmt die Häufigkeit des Datenabgleichs zwischen den Secondary Nameservern und dem Primary Master. Niedrige Werte erzeugen mehr DNS-Verkehr und mehr Last auf den beteiligten Systemen, hohe Werte verringern ggf. die Aktualität der Daten. Da diese Werte letztlich zwischen den Betreibern der beteiligten Nameservern abgestimmt sein müssen, wird lediglich gewarnt, wenn „übliche“ Werte unter- oder überschritten werden.
b. "Retry" soll in folgendem Bereich liegen: 900 – 28800 (in Sekunden) [sonst Ausgabe von WARNING].
Erläuterung: Dieser Wert ersetzt nach dem ersten fehlgeschlagenen Versuch den unter „Refresh“ angegebenen, bis entweder ein Abgleich erfolgreich war oder der „Expire“-Wert erreicht ist. Er ist darum kürzer zu wählen als „Refresh“, wobei ein zu kleiner Wert erneut zu Lastspitzen führen kann und ebenfalls eine Warnung auslöst.
c. "Retry" soll zwischen 1/8 und 1/3 von "Refresh" betragen [sonst Ausgabe von WARNING].
Erläuterung: Hiermit wird sichergestellt, dass die Werte „Refresh“ und „Retry“ in einem solchen Verhältnis zueinander stehen, dass die Umschaltlogik überhaupt zu einem nennenswerten Vorteil führen kann.
d. "Expire" soll in folgendem Bereich liegen: 604800 – 3600000 (in Sekunden) [sonst Ausgabe von WARNING].
Erläuterung: Dieser Wert bestimmt, wie lange erfolglose Abgleichversuche unternommen werden, bevor ein Slave die weitere Unterstützung der Zone einstellt. Werte unterhalb einer Woche sind sehr kritisch, weil sie dafür sorgen können, dass eine Zone binnen kurzer Zeit sämtliche autoritativen Nameserver verliert und dadurch zu 100% lahm delegiert wird. 1000 Stunden, hier als Obergrenze angenommen, ist ein verbreiteter Wert, oberhalb dessen von einem ernsten Abgleichproblem ausgegangen werden kann, dass nicht ignoriert werden sollte.
e. "negTTL" soll in folgendem Bereich liegen: 180 – 86400 (in Sekunden) [sonst Ausgabe von WARNING].
Erläuterung: Dieser Wert bestimmt gemeinsam mit der TTL des SOA-Records die Lebensdauer negativer Antworten nach RFC 2308. Zu große Werte (hier: länger als ein Tag) reduzieren den DNS-Verkehr nicht merklich bzw. werden von DNS-Caches ohnehin beschnitten. Sie wären darum wirkungslos. Zu geringe Werte (hier: kleiner als drei Minuten) führen letztlich zu einer kompletten Abschaltung des „negative Caching“, was es zu vermeiden gilt.
2.1.5 Anforderungen an weitere Daten in der Zone
1. Das NS-RRSet muss exakt mit der im Auftrag angegebenen Liste der Nameserver übereinstimmen [sonst Ausgabe von ERROR].
Erläuterung: RFC 1034 sieht vor, dass die Angaben zu autoritativen Nameservern in der delegierenden und in der delegierten Zone übereinstimmen.
2. Für die beantragte Zone (genauer: am Zonen-Apex) darf kein CNAME-RR existieren [sonst Ausgabe von ERROR].
Erläuterung: Zu einem CNAME-Record dürfen keine weiteren Record-Typen am selben Knoten im DNS-Baum existieren. Da für eine delegierte Zone aber mindestens der SOA-Record und die NS-Records vorhanden sein müssen, wäre das Vorhandensein eines CNAME-Records eine Protokollverletzung.
3. Die Referral-Response muss (bei bis zu 191 Bytes langem QNAME und inkl. sämtlicher notwendiger Adressinformationen einschl. Glue-Records) in ein DNS-UDP-Paket passen, darf also 512 Bytes nicht überschreiten [sonst Ausgabe von ERROR].
Erläuterung: Die Nameserver der DENIC antworten bei Anfragen nach Daten in delegierten Zonen mit einem Verweis (Referral) auf die tatsächlich zuständigen Nameserver der nächsten Hierarchiestufe. Standard-UDP-Pakete lassen maximal 512 Bytes Nutzlast zu. Um zu verhindern, dass die Antworten abgeschnitten werden und infolgedessen die Fragen über TCP erneut gestellt werden und die DENIC-Nameserver überproportional belasten, wird diese Längenbeschränkung eingeführt. Da der Platzverbrauch sowohl von der Länge der Nameservernamen und deren Komprimierbarkeit als auch von der Anzahl der Glue-Records abhängt, ist eine solche Berechnung sicherer als die Vorgabe einer maximalen Anzahl von Nameservern.
4. Die Angabe des Primary Nameservers im SOA -RR der beantragten Zone soll auf allen Nameservern übereinstimmen [sonst Ausgabe von WARNING].
Erläuterung: Auch dieser Test dient der Sicherstellung der unter 2.1.4, Absatz 1, angesprochenen Konsistenz.
2.1.6 Sonstige Vorgaben an die Nameserver
1. IPv6-Adressen müssen aus einem Adressraum 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 [sonst Ausgabe von ERROR].
Erläuterung: IPv6 kennt verschiedene Gültigkeitsbereiche für Adressen („Scoping“). Um die Prüfergebnisse eindeutig und nachvollziehbar zu machen und global einheitliche Erreichbarkeit der Nameserver sicherzustellen, werden nur solche Adressen akzeptiert, die global eindeutig sind.
2. Rekursive Abfragen sollen nicht zugelassen sein [sonst Ausgabe von WARNING].
Erläuterung: Aus Gründen der Sicherheit und der korrekten Sicht auf den Namensraum entspricht eine strikte Trennung von autoritativen und rekursiven Nameservern der operationellen Praxis.
3. Erreichbarkeit über TCP soll gegeben sein [sonst Ausgabe von WARNING].
Erläuterung: RFC 1034 und 1035 spezifizieren für DNS sowohl die Nutzung von UDPals auch TCP-Transport, wobei UDP Vorrang genießt und den überwiegenden Anteil des Verkehrs auch bedient. Unter gewissen Umständen (z.B. Antwortgröße) kann es für einen Resolver notwendig werden, auf TCP auszuweichen, was von RFC 1123 ausdrücklich unterstützt wird.