DNS: Les noms NS définis pour une zone doivent-ils correspondre aux noms NS signalés par les serveurs TLD amont?

Question

J'ai remarqué que plusieurs fournisseurs de services exploitent des services DNS pour les domaines de leurs clients avec des noms NS définis pour la zone et retournés par le serveur de noms faisant autorité (dans la section autorité/NS & enregistrements SOA) qui ne correspondent pas au NS les noms renvoyés par le serveur en amont (par exemple les serveurs TLD) et qui ont été utilisés pour la recherche.

Exemple:

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 

$ dig @ 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 

Les serveurs disent que le serveur TLD générique nom est ns1.service-provider-here.net et quand on recherche le nom à ce serveur, il donne une réponse faisant autorité mais fuit un nom de NS différent dans la section d'autorité (ns1.different-trade-name.net).

Des milliers de domaines sont configurés de cette manière. Cela ne semble pas causer de problèmes, mais cela semble si mauvais.

Est-ce que cela a vraiment de l'importance? Y aura-t-il une situation où les résolveurs/clients feront une recherche supplémentaire ou même échoueront à résoudre le nom à cause de cela?

Answer 1

Si le parent a des enregistrements valides se référant aux serveurs DNS qui font autorité pour la zone, alors la résolution devrait fonctionner principalement.

Je peux penser à au moins un cas où leur pourrait être un problème si vous aviez des enregistrements différents et quelques autres configurations manquées.

Le problème est lié à la manière dont le serveur de noms envoie des notifications lorsque la zone est mise à jour. Par exemple, lorsque vous utilisez bind sur le serveur DNS principal, vous mettez à jour la zone, puis reload, bind enverra des notifications de mise à jour à tous les serveurs répertoriés dans la zone. Si leur était un autre serveur faisant autorité n'a pas un enregistrement NS dans la zone principale alors il ne recevrait pas l'avis et aurait des données plus anciennes. Si les parents pointent sur ce serveur qui ne reçoit pas les mises à jour, alors vous pourriez avoir des problèmes car ce serveur fournirait des résultats de données.

De plus, gardez à l'esprit qu'il existe un DNS «split-horizon». Parfois, vous devez fournir une vue différente de votre zone à vos hôtes internes qui sont à l'intérieur de votre réseau en fonction de ce que vous affichez au public. Lorsque vous comparez les enregistrements du serveur de noms, assurez-vous de voir la zone dans la même perspective.

Answer 2

Eh bien, la réponse dépend du point de vue. Techniquement, il n'y a aucun doute que toute divergence entre le parent et la zone est fausse. Cela ne devrait jamais arriver (certains registres utilisent des outils automatiques pour vérifier cela, par exemple Zonecheck dans .fr).

Pratiquement, cela arrive assez souvent. La cause la plus fréquente est que les gens modifient les enregistrements NS dans leur zone et oublient de dire au registre (ou au bureau d'enregistrement, si le registre vous oblige à passer par un intermédiaire) sur le changement.

Est-ce vraiment important? Eh bien, comme vous l'avez dit, tant qu'il y a une intersection non vide entre les deux ensembles, cela devrait fonctionner.Mais il est dangereux de s'en remettre à un autre changement et les deux ensembles peuvent être complètement séparés. Donc, ce n'est pas une bonne idée d'accepter une divergence. Légalement parlant, la zone enfant a toujours raison, les enregistrements NS dans le parent ne font pas autorité. Les résolveurs doivent remplacer la délégation par la liste qu'ils trouvent dans la zone enfant.