DNS: Müssen die NS-Namen, die für eine Zone festgelegt sind, den NS-Namen entsprechen, die von den TLS-Servern in der Upstream-Umgebung gemeldet werden?

Question

Ich habe festgestellt, dass mehrere Dienstanbieter DNS-Dienste für die Domänen ihrer Clients mit für die Zone festgelegten und vom autorisierenden Nameserver zurückgegebenen NS-Namen ausführen, die nicht mit dem NS übereinstimmen (im Berechtigungsabschnitt/NS & SOA-Einträge) Namen, die vom Upstream-Server (z. B. TLD-Server) zurückgegeben wurden und für die Suche verwendet wurden.

Beispiel:

$ dig the-domain-name-here.com NS

; <<>> DiG 9.4.2-P1 <<>> the-domain-name-here.com NS 
;; global options: printcmd 
;; Got answer: 
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7844 
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 

;; QUESTION SECTION: 
;the-domain-name-here.com.   IN  NS 

;; ANSWER SECTION: 
the-domain-name-here.com. 172370 IN  NS  ns1.service-provider-here.net. 
the-domain-name-here.com. 172370 IN  NS  ns2.service-provider-here.net. 

;; ADDITIONAL SECTION: 
ns1.service-provider-here.net.  7200 IN  A  192.168.100.1 
ns2.service-provider-here.net.  7200 IN  A  192.168.100.2 

;; Query time: 65 msec 
;; SERVER: 192.168.0.1#53(192.168.0.1) 
;; WHEN: Wed Mar 11 19:44:00 2009 
;; MSG SIZE rcvd: 118 

graben $ @ ns1.service-provider-here.net. the-domain-name-here.com

; <<>> DiG 9.4.2-P1 <<>> @ns1.service-provider-here.net the-domain-name-here.com 
; (1 server found) 
;; global options: printcmd 
;; Got answer: 
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48010 
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 
;; WARNING: recursion requested but not available 

;; QUESTION SECTION: 
;the-domain-name-here.com.   IN  A 

;; ANSWER SECTION: 
the-domain-name-here.com. 86400 IN  A  192.168.100.3 

;; AUTHORITY SECTION: 
the-domain-name-here.com. 86400 IN  NS  ns1.different-trade-name.net. 
the-domain-name-here.com. 86400 IN  NS  ns2.different-trade-name.net. 

;; Query time: 68 msec 
;; SERVER: 192.168.100.1#53(192.168.100.1) 
;; WHEN: Wed Mar 11 19:46:00 2009 
;; MSG SIZE rcvd: 100 

Die gTLD-Server der Nameserver sagen ist ns1.service-provider-here.net und wenn wir den Namen auf diesem Server-Lookup, gibt es eine verbindliche Antwort, aber gibt im Abschnitt "Authority" einen anderen NS-Namen aus (ns1.different-trade-name.net).

Auf diese Weise sind Tausende von Domänen konfiguriert. Es scheint keine Probleme zu verursachen, aber es scheint so falsch zu sein.

Ist das wirklich wichtig? Wird es jemals eine Situation geben, in der Resolver/Clients eine zusätzliche Suche durchführen oder den Namen aus diesem Grund nicht auflösen können?

Answer 1

Wenn das übergeordnete Element über gültige Datensätze für DNS-Server verfügt, die für die Zone autorisierend sind, sollte die Auflösung hauptsächlich funktionieren.

Ich kann mir mindestens einen Fall vorstellen, in dem sie ein Problem darstellen könnten, wenn Sie verschiedene Datensätze und einige andere Fehlkonfigurationen hätten.

Das Problem hängt damit zusammen, wie der Nameserver sendet, wenn die Zone aktualisiert wird. Wenn Sie z. B. bind auf dem primären DNS-Server verwenden, die Zone aktualisieren und dann neu laden, sendet bind Updatebenachrichtigungen an alle Server, die in der Zone aufgeführt sind. Wenn ihr ein anderer autoritativer Server war, der keinen NS-Eintrag in der primären Zone hatte, würde er die Benachrichtigung nicht erhalten und hätte ältere Daten. Wenn die Eltern auf diesen Server zeigen, der keine Updates erhält, könnten Probleme auftreten, da dieser Server keine Datenergebnisse liefert.

Denken Sie auch daran, dass es so etwas wie "Split-Horizon" DNS gibt. Manchmal müssen Sie Ihren internen Hosts, die sich in Ihrem Netzwerk befinden, eine andere Ansicht Ihrer Zone bieten, was Sie der Öffentlichkeit zeigen. Wenn Sie die Nameserver-Datensätze vergleichen, stellen Sie sicher, dass Sie die Zone aus derselben Perspektive betrachten.

Answer 2

Nun, die Antwort hängt von der Sichtweise ab.

Technisch besteht kein Zweifel, dass jede Diskrepanz zwischen dem Eltern und der Zone falsch ist. Es sollte nie passieren (einige Register verwenden automatische Tools, um das zu überprüfen, zum Beispiel Zonecheck in .fr).

Praktisch passiert es ziemlich oft. Die häufigste Ursache ist, dass Benutzer die NS-Datensätze in ihrer Zone ändern und vergessen, der Registrierung (oder dem Registrator, falls die Registrierung Sie zwingt, einen Zwischenhändler zu durchlaufen) die Änderung mitzuteilen.

Ist es wirklich wichtig? Nun, wie Sie gesagt haben, solange es eine nicht leere Kreuzung zwischen den beiden Mengen gibt, sollte es funktionieren.Aber es ist gefährlich sich darauf zu verlassen, da eine weitere Änderung und die zwei Sätze vollständig getrennt werden können. Es ist also keine gute Idee, eine Diskrepanz zu akzeptieren.

Rechtlich gesehen hat die untergeordnete Zone immer Recht, die NS-Datensätze im übergeordneten Element sind nicht autorisierend. Resolver müssen die Delegierung durch die Liste ersetzen, die sie in der untergeordneten Zone finden.