Difference between revisions of "MOOC:Auto-eval Act34-doc"

From Livre IPv6
Line 6: Line 6:
 
|| Explication : Les champs PTR sont utilisé dans les zones de résolution inverse tandis que les champs AAAA sont utilisés dans les zones de résolution directe. Les zones de résolution inverses et directes ne peuvent être contenues dans le même fichier. Par conséquent, les entrées AAAA et PTR ne peuvent se rencontrer dans un même fichier.
 
|| Explication : Les champs PTR sont utilisé dans les zones de résolution inverse tandis que les champs AAAA sont utilisés dans les zones de résolution directe. Les zones de résolution inverses et directes ne peuvent être contenues dans le même fichier. Par conséquent, les entrées AAAA et PTR ne peuvent se rencontrer dans un même fichier.
 
   
 
   
−
{Les entrées PTR relatives à une adresse IPv4 et une adresse IPv6 peuvent elles se incluses dans un même fichier de zone ?
+
{Dans quel fichier de zone sont incluses les entrées PTR relatives aux adresses IPv6 ?
−
|type="[]"}
+
|type="()"}
−
- Oui
+
- in-addr.arpa
−
+ Non
+
+ ip6.arpa
−
|| Explication : Elles n'appartiennent pas à la même zone de résolution inverse (in-addr.arpa. et ip6.arpa.).
+
- in6-addr.arpa
 +
- ipv6.arpa
 +
|| Explication : Elles appartiennent à la zone de résolution inverse ip6.arpa.
  
−
{Si un résolveur souhaite récupérer les adresses IPv6 associées à un FQDN, est-ce indispensable qu'il transmette sa requête via IPv6 ?
+
{Si un résolveur souhaite récupérer les adresses IPv6 associées à un FQDN, qued doit il faire ?  
 
|type="[]"}
 
|type="[]"}
−
- Oui
+
- Il est indispensable qu'il transmette sa requête via IPv6
−
+ Non
+
- Il est indispensable qu'il transmette sa requête via IPv4
−
|| Explication : Non, le document compagnon indique à plusieurs reprise que le serveur DNS doit répondre à la requête sans se soucier de la version d'IP qui a été utilisée dans les paquets.
+
+ La version du protocole IP pour l'émission de la requête est sans importance
 +
- il faut envoyer la requête à la fois en IPv4 et en IPv6
 +
|| Explication : Le document compagnon indique à plusieurs reprise que le serveur DNS doit répondre à la requête sans se soucier de la version d'IP qui a été utilisée dans les paquets.
  
  

Revision as of 21:10, 27 April 2016

1. Un même fichier de zone peut il contenir une entrée de type AAAA et une entrée de type PTR ?

Oui
Non
→ Explication : Les champs PTR sont utilisé dans les zones de résolution inverse tandis que les champs AAAA sont utilisés dans les zones de résolution directe. Les zones de résolution inverses et directes ne peuvent être contenues dans le même fichier. Par conséquent, les entrées AAAA et PTR ne peuvent se rencontrer dans un même fichier.

2. Dans quel fichier de zone sont incluses les entrées PTR relatives aux adresses IPv6 ?

in-addr.arpa
ip6.arpa
in6-addr.arpa
ipv6.arpa
→ Explication : Elles appartiennent à la zone de résolution inverse ip6.arpa.

3. Si un résolveur souhaite récupérer les adresses IPv6 associées à un FQDN, qued doit il faire ?

Il est indispensable qu'il transmette sa requête via IPv6
Il est indispensable qu'il transmette sa requête via IPv4
La version du protocole IP pour l'émission de la requête est sans importance
il faut envoyer la requête à la fois en IPv4 et en IPv6
→ Explication : Le document compagnon indique à plusieurs reprise que le serveur DNS doit répondre à la requête sans se soucier de la version d'IP qui a été utilisée dans les paquets.

4. La taille d'une réponse à une requête DNS en UDP/IPv6 peut dépasser la valeur maximale de 512 octets prévu par la RFC1035. Quelles sont les solutions envisageable ?

Faire la requête en plusieurs fois.
Faire la requête via UDP/IPv4.
Faire la requête via TCP/IPv6.
Utiliser l'extension EDNS.0.
→ Explication : Il n'est pas toujours possible de réduire le scope d'une requête afin de réduire la taille de la réponse. Utiliser IPv4 pour router les paquets de la requête n'aura aucun impact sur le contenu de la payload. Par conséquent la taille de la réponse ne sera pas impacté et sera toujours au dessus de la valeur maximale autorisée. La DNS autorise l'utilisation de TCP sans limite de taille. L'utilisation de EDNS.0 (RFC 6891) permet d'autoriser jusqu'à 4096 octets de payload avec UDP.

5. Afin d'assurer la robustesse et le passage à l’échelle, les fichiers de zones d'un nom de domaine peuvent être consultable sur plusieurs serveurs :

Il est possible de modifier les entrées sur n'importe lequel des serveurs.
Il faut d'abord faire la modification sur le serveur primaire puis sur les serveurs secondaire.
La modification ne peut se faire que sur le serveur primaire.
Il est indispensable d'incrémenter le numéro de série lors de la modification des entrées d'une zone.
→ Explication : Il n'est possible de modifier les entrées que sur le serveur maitre..

6. Découverte de serveurs DNS IPv6 :

Lors de l'auto-configuration IPv6 (via RA ou DHCPv6), un hôte n'a pas reçu d'information relative au serveur DNS. Il pourra néanmoins utiliser celui qu'il a appris avec l'auto-configuration IPv4, y compris pour obtenir les adresses IPv6 associées à un nom de domaine.
Si un serveur DNS est appris via RA ou DHCPv6, il doit appartenir au même réseau que ses clients.
Les serveurs DNS appris via DHCPv4 et DHCPv6 (ou via RA) sont nécessairement disjoints. Ils appartiennent à des instances différentes, hébergées ou non sur la même machine.
Un serveur DNS peut accepter les requêtes via IPv4 et IPv6.
→ Explication : Un hôte peut utiliser le serveur DNS accessible en IPv4 pour faire des requêtes AAAA. Lorsque le RA ou DHCPv6 indique un serveur DNS, rien n'oblige celui ci à être dans le même réseau que ses clients. Les serveurs répondant aux requête IPv6 et IPv4 ne sont pas necessairement disjoint. En effet, une instance de bind va écouter les requêtes sur l'ensemble des interfaces listées dans listen-on et listen-on-v6 .

7. Les règles de sécurité de l'université UniX sont strictes et bloquent par défaut tous les ports à l'exception des ports 80 et 443. Un serveur DNS présent dans la DMZ n'est pas soumis à ces règles et il accepte les requêtes provenant du réseau de l'université. Un utilisateur User1 installe un routeur WiFi branché en ethernet au réseau de l'université. Il se connecte au réseau via l’intermédiaire de ce routeur. Le serveur DNS qu'il apprend via DHCP est celui de son routeur WiFI. Un utilisateur User2 est branché directement au réseau de l'université via une prise ethernet. Le serveur DNS qu'il apprend via DHCP est celui présent dans la DMZ.

User1 peut effectuer des requêtes DNS itératives (i.e. en contactant lui même les serveurs de l'arborescence DNS).
User2 peut effectuer des requêtes DNS itératives (i.e. en contactant lui même les serveurs de l'arborescence DNS).
Le routeur WiFi peut effectuer des requêtes DNS itératives (i.e. en contactant lui même les serveurs de l'arborescence DNS).
Le serveur DNS du routeur WiFi est de type récursif (caching name server).
Le serveur DNS du routeur WiFi est de type relais DNS (forwarder).
Pour les requêtes formulées par User1, le serveur DNS présent dans la DMZ est de type récursif (caching name server).
Pour les requêtes formulées par User1, le serveur DNS présent dans la DMZ est de type relais DNS (forwarder).
Le temps de résolution des noms de domaines sera en moyenne légèrement plus long pour User1 que pour User2.
→ Explication : Le port 53 est verrouillé. Ni User1, ni User2, ni le routeur WiFi ne pourront effectuer de requête récursive. Le DNS du routeur WiFi ne peut faire de requête iterative, il ne peut donc jouer que le rôle de caching serveur. Le serveur présent dans la DMZ pourra effectuer ce type de requêtes, il sera donc considéré comme server recursif. Dans l'architecture que nous avons décrit, il n'y a pas de serveur à qui il pourrait envoyer ses requêtes.

8. Une entreprise déploie un routeur WiFi connecté à l'internet via une connection 3G. Le réseau de l'opérateur, le routeur WiFi et ses clients utilisent tous IPv6. L'entreprise souhaite réduire autant que possible le temps de chargement des pages internet pour ses clients. Que doit elle faire (une seule réponse possible) :

Laisser les utilisateurs résoudre les noms de domaines via des requètes itératives.
Deployer un serveur recursif colocalisé avec le routeur WiFi. Les requètes des utilisateurs seront prises en charge par ce serveur.
Deployer un serveur recursif ailleurs l'internet. Les requètes des utilisateurs seront prises en charge par ce serveur.
Deployer un serveur relais colocalisé avec le routeur WiFi. Ce serveur transmettra ses requètes à un serveur recursif deployé sur l'internet. Les requètes des utilisateurs seront prises en charge par le serveur relais.
→ Explication : .

Your score is 0 / 0
Retrieved from "http://livre.g6.asso.fr/index.php?title=MOOC:Auto-eval_Act34-doc&oldid=12899"
Personal tools