Gibt es eine offizielle Grenze für die Indirektion von Nameservern?

Klebedatensätze sind normalerweise nicht verfügbar, wenn eine Domäne und ihr Nameserver keine TLD gemeinsam nutzen, und sind technisch nicht erforderlich, wenn sie nicht dieselbe Domäne der zweiten Ebene gemeinsam nutzen. Dies kann zu zusätzlichen Schritten zum Auflösen einer Domäne führen. Der Resolver muss zuerst die Adresse des Nameservers nachschlagen, bevor er die Adresse für Ihre Domain finden kann. Aber theoretisch könnten Sie dort mehr Schritte hinzufügen als nur diese beiden.

Die Frage ist hier, wie lang darf diese Kette sein ?

wenn xyz.comVerwendungen Name - Server ns1.xyz.info,
und xyz.infoVerwendungen Name - Server ns1.xyz.co,
und xyz.coVerwendungen Name - Server ns1.xyz.cc,
und xyz.ccVerwendungen Name - Server ns1.xyz.co.uk, ... und so weiter

... Sie könnten eine sehr lange Kette haben, die der Resolver entwirren kann, bevor er den ursprünglich gewünschten Namen auflösen kann.

Vermutlich gibt es eine praktische Grenze - BIND sollte nur bereit sein, so viele Links zu durchqueren, sonst besteht die Möglichkeit eines Denial-of-Service. Aber gibt es eine offizielle Grenze? Einige Schritte, ab denen der Resolver offiziell nicht mehr fortfahren muss?

if xyz.com uses nameserver ns1.xyz.info,

In diesem Fall fragt Ihr lokaler Resolver zuerst die Server nach .com(z. B. a.gtld-servers.net), wo sich die Nameserver für die Domäne xyz.com befinden. Der .com-Domänenserver stellt normalerweise Kleberdatensätze für die IP-Adressen der Nameserver für die xyz.com-Domäne bereit.

z.B:

$ dig  gmail.com @a.gtld-servers.net 

; <<>> DiG 9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntu1.1 <<>> gmail.com @a.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46893
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 5
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;gmail.com.         IN  A

;; AUTHORITY SECTION:
gmail.com.      172800  IN  NS  ns2.google.com.
gmail.com.      172800  IN  NS  ns1.google.com.
gmail.com.      172800  IN  NS  ns3.google.com.
gmail.com.      172800  IN  NS  ns4.google.com.

;; ADDITIONAL SECTION:
ns2.google.com.     172800  IN  A   216.239.34.10
ns1.google.com.     172800  IN  A   216.239.32.10
ns3.google.com.     172800  IN  A   216.239.36.10
ns4.google.com.     172800  IN  A   216.239.38.10

;; Query time: 375 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Thu Jul 10 01:10:57 EST 2014
;; MSG SIZE  rcvd: 181

Nach meiner Erfahrung ist Ihre Aussage, dass "Klebedatensätze normalerweise nicht verfügbar sind, wenn eine Domain und ihr Nameserver keine TLD gemeinsam nutzen", einfach nicht wahr. Dies hängt jedoch von den vom Registrar für die Domain bereitgestellten Daten ab, und ihre Richtlinien variieren. Bei einigen muss die IP angegeben werden. Einige überlassen es dem Domaininhaber. Ich denke, ich erinnere mich an einen in Australien, der sie nicht unterstützt. Wenn die Anzahl der Registrare, die sich mit der Domain Ihres Landes befassen, gering ist, trifft dies möglicherweise auf diesen Teil des Domain-Bereichs zu, aber für das gesamte Netz ist dies untypisch.

Es ist sicherlich eine gute Praxis für Domaininhaber, Glue-Einträge bereitzustellen, aber manchmal wird die Möglichkeit, einen DNS-Server namentlich anzugeben, ohne die IP-Adresse festzulegen, als flexibel angesehen, und viele Domaininhaber verstehen das dadurch verursachte Leistungsproblem nicht.

Wenn Sie ein DNS-Berichtstool bereitstellen, ist dies wirklich die absolute Grenze für eine solche Fehlkonfiguration, an der Sie interessiert sind? Sicherlich ist es für Sie wichtiger, die fehlenden Kleberaufzeichnungen als Warnung zu melden, wenn auch nur ein solches Problem mit fehlenden Kleberaufzeichnungen auftritt. Sie möchten wahrscheinlich mindestens einige von Ihnen bereitgestellte Indirektionen verfolgen (und die fehlenden Klebstoffaufzeichnungen melden), aber es muss einige Grenzen geben, wie weit Sie dies befolgen sollten. Ich würde mich sehr freuen, wenn ein DNS-Berichtstool vor den ersten drei warnen würde, da ich nur wirklich daran interessiert wäre, entweder die Klebereinträge zu meiner Domain hinzuzufügen oder den DNS-Anbieter für die Domain zu einem kompetenteren zu wechseln.

Ich bezweifle Ihren vorgeschlagenen DOS-Ansatz für BIND, da BIND die gesammelten Informationen über den Standort von Nameservern zwischenspeichert. Ein Angreifer müsste viele Domänen ohne Klebstoff einrichten und dann viele Fragen dazu stellen. Die Kosten für die Einrichtung von Domains, die wahrscheinlich vom Registrar nach der Verwendung storniert werden, machen dies für einen Angreifer wahrscheinlich unattraktiv.