Pourquoi envoyer un serveur de noms faisant autorité dans DNS?

Par curiosité, je vérifie les paquets DNS Wireshark. Je peux voir qu'il y a une requête DNS de l'hôte, puis une réponse DNS du serveur DNS. Tout est exactement comme prévu.

Cependant, si vous archivez davantage la requête, vous pouvez voir que le serveur envoie également le NS (serveur de noms faisant autorité). Ma question est: pourquoi?

En tant qu'hôte, je ne me soucie que de l'IP. C'est le point principal du DNS , pour résoudre un nom en une adresse IP .

Pourquoi, en tant qu'hôte, aurais-je besoin des informations NS?

domain-name-system dns-zone wireshark dns-hosting dns-server AhmedWas
la source

@downvoter, veuillez commenter. Et si vous pensez que ma question est si facile, alors répondez-y au moins puis dévalorisez.

Ahmed était

Par voix de philosophie et de conception sont anonymes et ne vote up ni vote vers le bas nécessite aucune explication obligatoire . L'info-bulle qui apparaît lorsque le pointeur de votre souris passe sur le bouton bas indique: "cette question ne montre aucun effort de recherche; elle n'est pas claire ou n'est pas utile" . Les questions peuvent également attirer un vote négatif lorsqu'elles ne sont pas bien écrites , pas tout à fait sur le sujet ou manquent de détails.

HBruijn

Réponses:

Traditionnellement, les serveurs de noms n'envoient pas de réponse courte à une requête, mais une réponse complète conforme à la RFC 1034 - 1035 qui inclut la section d'autorité qui contient les enregistrements de ressources qui pointent vers le ou les serveurs de noms faisant autorité.

Le pourquoi est probablement dû à la nature distribuée et déléguée du DNS, il semblait à l'époque une bonne idée d'inclure la "source de vérité" dans les réponses.

Modifier: Soit dit en passant: l'envoi de la section d'autorisation est conforme à la RFC mais pas obligatoire pour toutes les réponses aux requêtes.

Dans BIND, ce comportement peut être réglé avec la minimal-responses yes | no;directive, où la valeur par défaut est noet les sections Authority et Additional de la réponse à la requête seront toujours entièrement renseignées.
D'autres serveurs de noms CloudFlare, AWS Route 53, Infoblocks et probablement d'autres enverront déjà toujours de telles réponses minimales par défaut. Les résolveurs publics de Google renverront une section Autorité lorsqu'elle sera disponible, Cloudflare.

Je pense que l'origine de cette tradition d'inclure à la fois la section d'autorité et la réponse à la requête réelle trouve sa racine dans le (pseudo) code de la désormais obsolète RFC882 page 15-16

If the name server is not authoritative, the code copies 
the RRs for a closer name server into the response.  

The last section of the code copies all relevant RRs into the response.

HBruijn
la source

merci pour la modification et les informations supplémentaires. J'aimerais pouvoir vous donner plus d'un vote UP :)

Ahmed était

Cela ne répond pas vraiment à la question. Nous savons déjà qu'une réponse complète est reçue. La question était, quel est l'avantage de cela? Pourquoi la norme est-elle conçue de cette façon? Quelle est la valeur des informations "supplémentaires" dans cette forme de réponse?

Courses de légèreté en orbite

@LightnessRacesinOrbit pour moi, la réponse est évidente: le serveur DNS ne me dit pas seulement que example.com est abcd; ça me dit qui l'a dit. C'est épistémologiquement valable, parce que je ne peux pas vous dire avec précision que je sais que quelque chose est un fait alors que je sais seulement qu'un tiers a affirmé que c'était un fait. Je trouve qu'il est plus difficile de résoudre les problèmes lorsque les gens présentent du ouï-dire comme s'il s'agissait d'une observation, ou de leurs conclusions comme s'il s'agissait d'une preuve principale, etc. La différence entre énoncer X pour être vrai et me dire Y dit que c'est vrai est énorme.

Monty Harder

@MontyHarder Oui, cela a du sens, mais ce que je dis, c'est que cela devrait être dans la réponse.

Courses de légèreté en orbite

Les RFC @LightnessRacesinOrbit n'incluent pas toujours les motivations de conception. Pour clarifier "cela semblait une bonne idée à l'époque" - je pense que c'est une raison pour laquelle il est traditionnel d'inclure la section d'autorité en plus de la réponse à la requête, même si les RFC actuels ne mandatent pas qui trouve son origine dans le (pseudo ) code de la RFC882 désormais obsolète page 15-16 "... Si le serveur de noms ne fait pas autorité, le code copie les RR pour un serveur de noms plus proche dans la réponse. La dernière section du code copie tous les RR pertinents dans la réponse ... "

HBruijn

Le serveur ne sait pas si la demande provient d'un client final ou s'il s'agit d'une demande récursive d'un autre serveur de noms. S'il s'agit d'un autre serveur de noms, il peut mettre en cache la section Autorité et interroger ces serveurs de noms directement à l'avenir.

Je pense que c'était la justification originale du protocole, mais cela a des implications en termes de sécurité. Une réponse peut inclure une section Autorité qui répertorie les faux serveurs de noms, ce qui a été utilisé dans les attaques d'empoisonnement du cache. Par conséquent, les serveurs de noms ne mettent généralement pas en cache les enregistrements NS sauf s'ils sont des enregistrements de délégation pour un sous-domaine du domaine que vous interrogez.

Barmar
la source

Le serveur peut réellement faire la différence entre de telles demandes. Il y a un peu dans les drapeaux pour demander la récursivité.

kasperd

Les serveurs peuvent envoyer des requêtes récursives, par exemple lorsque la forwardersfonctionnalité est utilisée.

Barmar

Mais si vous faites cela, il ne se souciera pas des serveurs faisant autorité de toute façon.

kasperd