MOOC:Devoir Seq3-quiz - Revision history

Jlandru2: /* Session 3 */

2017-04-18T18:35:14Z

‎Session 3

Jlandru: /* Session 3 */

2017-04-14T08:58:24Z

‎Session 3

Jlandru: /* Session 3 */

2017-04-14T08:56:48Z

‎Session 3

Jlandru: /* Session 3 */

2017-04-14T08:33:50Z

‎Session 3

Jlandru: /* Session 3 */

2017-04-14T08:22:00Z

‎Session 3

Jlandru: /* Session 3 */

2017-04-04T08:47:56Z

‎Session 3

Jlandru at 07:58, 4 April 2017

2017-04-04T07:58:10Z

Panelli at 01:49, 19 March 2017

2017-03-19T01:49:27Z

Ptournoux at 14:53, 13 May 2016

2016-05-13T14:53:22Z

Panelli at 12:51, 2 May 2016

2016-05-02T12:51:42Z

@@ Line 83: / Line 83: @@
 >>S3Q08. <<
->>Complétez la phrase en utilisant des chiffres et/ou des lettres minuscules : <<
+>>Compléter la phrase en utilisant des chiffres et/ou des lettres minuscules : <<
->>Le RFC<<
+>>Le RFC <<
 = 3315
->>décrit le protocole DHCPv6 et définit notamment <b>le format des messages échangés</b>. Les messages contenant les requêtes des clients et les réponses des serveurs débutent par un champ<<
+>>décrit le protocole DHCPv6 et définit notamment le format des messages échangés. Les messages contenant les requêtes des clients et les réponses des serveurs débutent par un champ<<
 = type
 or= msg-type
 or= type-msg
->>qui indique la nature du message, suivi d'un champ identificateur de <<
+>> qui indique la nature du message, suivi d'un champ identificateur de <<
 = transaction
->>qui permet d'associer les requêtes et les réponses.<<
+>> qui permet d'associer les requêtes et réponses.<<
 [explanation]

@@ Line 108: / Line 108: @@
 Le RFC 3315 spécifie que lorsqu'aucun serveur DHCPv6 n'est présent sur le réseau local d'un client, un relais permet de transférer la requête d'allocation d'une adresse IPv6, ou d'un préfixe IPv6 dans le cas de la délégation de préfixe, dans un autre segment réseau qui contient un serveur DHCPv6 ou un autre agent de relais. Le premier agent de relais encapsule, sans le modifier, le message SOLICIT envoyé par le client, dans le champ <i>option-list</i> d'un message RELAY-FORWARD, envoyé en unicast ou en multicast (selon configuration). Le champ <i>hop-limit</i> est initialisé à zéro par le premier relais puis incrémenté d'une unité à chaque relais traversé. Un agent de relais qui reçoit un mesage RELAY-FORWARD avec une valeur de <i>hop-limit</i> égale à une valeur HOP-COUNT-LIMIT ignore ce message.
 [explanation]
 >>S3Q10.<<

@@ Line 86: / Line 86: @@
 >>Le RFC<<
 = 3315
->>décrit le protocole DHCPv6 et définit notamment le format des messages échangés. Les messages contenant les requêtes des clients et les réponses des serveurs débutent par un champ<<
+>>décrit le protocole DHCPv6 et définit notamment <b>le format des messages échangés</b>. Les messages contenant les requêtes des clients et les réponses des serveurs débutent par un champ<<
 = type
 or= msg-type
@@ Line 99: / Line 99: @@
 >>S3Q09. <<
->>Parmi les propositions suivantes concernant les relais DHCPv6, indiquez celles qui sont vraies. <<
+>>Parmi les propositions suivantes concernant les relais DHCPv6, indiquez laquelle est vraie. <<
-[ ] Le champ <i>hop-count</i>, initialisé à une valeur non nulle dans l'en-tête du message RELAY-FORWARD par le premier relais atteint par un message SOLICIT, est décrémenté à chaque relais traversé. Lorsque ce champ atteint la valeur zéro, le datagramme est détruit.
+( ) Le champ <i>hop-count</i>, initialisé à une valeur non nulle dans l'en-tête du message RELAY-FORWARD par le premier relais atteint par un message SOLICIT, est décrémenté à chaque relais traversé. Lorsque ce champ atteint la valeur zéro, le datagramme est détruit.
-[x] Le champ <i>hop-count</i>, initialisé à zéro dans l'en-tête du message RELAY-FORWARD par le premier relais atteint par un message SOLICIT, est incrémenté à chaque relais traversé, jusqu'au serveur DHCPv6.
+(x) Le champ <i>hop-count</i>, initialisé à zéro dans l'en-tête du message RELAY-FORWARD par le premier relais atteint par un message SOLICIT, est incrémenté à chaque relais traversé, jusqu'au serveur DHCPv6.
-[x] Un agent de relais DHCPv6 peut envoyer un message RELAY-FORWARD en unicast.
+( ) Un relais qui reçoit un message SOLICIT d'un client DHCPv6 met cette requête en attente dans une mémoire tampon et génère une demande spécifique dans le champ <i>option-list</i> du message RELAY-FORWARD.
-[x] Un relais qui reçoit un message SOLICIT d'un client DHCPv6 encapsule sans la modifier cette requête dans un message RELAY-FORWARD.
+( ) Un agent de relais DHCPv6 ne peut pas relayer de requête d'allocation de préfixe.
-[ ] Un relais qui reçoit un message SOLICIT d'un client DHCPv6 met cette requête en attente dans une mémoire tampon et génère une demande spécifique dans le champ <i>option-list</i> du message RELAY-FORWARD.
+Note : une seule réponse valide
-[ ] Un agent de relais DHCPv6 ne peut pas relayer de requête d'allocation de préfixe.
-Note : 3 réponses valides
 [explanation]
 Le RFC 3315 spécifie que lorsqu'aucun serveur DHCPv6 n'est présent sur le réseau local d'un client, un relais permet de transférer la requête d'allocation d'une adresse IPv6, ou d'un préfixe IPv6 dans le cas de la délégation de préfixe, dans un autre segment réseau qui contient un serveur DHCPv6 ou un autre agent de relais. Le premier agent de relais encapsule, sans le modifier, le message SOLICIT envoyé par le client, dans le champ <i>option-list</i> d'un message RELAY-FORWARD, envoyé en unicast ou en multicast (selon configuration). Le champ <i>hop-limit</i> est initialisé à zéro par le premier relais puis incrémenté d'une unité à chaque relais traversé. Un agent de relais qui reçoit un mesage RELAY-FORWARD avec une valeur de <i>hop-limit</i> égale à une valeur HOP-COUNT-LIMIT ignore ce message.
@@ Line 136: / Line 134: @@
 >>S3Q12.<<
->>Afin d'assurer la robustesse et le passage à l’échelle, les fichiers de zones d'un nom de domaine peuvent être consultables sur plusieurs serveurs. Parmi les propositions suivantes, lesquelles sont correctes ?  <<
+>>Afin d'assurer la robustesse et le passage à l’échelle, les fichiers de zones d'un nom de domaine peuvent être consultables sur plusieurs serveurs. Pour le mise à jour de la zone ...? Parmi les propositions suivantes, laquelle est correcte ?  <<
-[ ] Il est possible de modifier les entrées sur n'importe lequel des 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 secondaires.
+( ) Il faut d'abord faire la modification sur le serveur primaire puis sur les serveurs secondaires.
-[x] La modification ne peut se faire que sur le serveur primaire.
+( ) Il faut d'abord faire la modification sur les serveurs secondaires puis sur le serveurs primaire.
-[x] Il est indispensable d'incrémenter le numéro de série lors de la modification des entrées d'une zone.
+(x) La modification ne peut se faire que sur le serveur primaire. Il est alors indispensable d'incrémenter le numéro de série de la zone.
-Note : deux réponses valides
+Note : une seule réponse valide
 [explanation]
-Il n'est possible de modifier les entrées que sur le serveur maitre.
+Il n'est possible de modifier les entrées que sur le serveur maitre, les secondaires se synchronisent sur la base du numéro de série.
 [explanation]
 </pre>

@@ Line 50: / Line 50: @@
 >>S3Q05. <<
->>Un message ICMPv6 RA contient une option d'information sur le préfixe. Le champ longueur indique une valeur de 4. À combien d'octets cela correspond-il ?  <<
+>>Un message ICMPv6 RA contient une option d'information sur le préfixe. Le champ longueur de cette option indique une valeur de 4. À combien d'octets cela correspond-il ?  <<
 ( ) 4 octets
 ( ) 16 octets

@@ Line 17: / Line 17: @@
 >>S3Q02. <<
 >>La procédure de détection d'adresse dupliquée donne une réponse négative (pas de duplication d'adresse) quand :  <<
 ( ) un routeur local répond par un message ICMPv6 "router advertisement".
@@ Line 36: / Line 25: @@
 [explanation]
 Si personne ne répond, c'est que personne n'a reconnu l'adresse cible dans le message <i>neighbor sollicitation</i>. L'adresse IPv6 unicast est donc bien unique sur le lien.
 [explanation]
 >>S3Q04. <<
->>Quelles sont les différences dans l'envoi d'un message ICMPv6 NS lorsqu'il est utilisé dans une procédure DAD par rapport à une résolution d'adresse IPv6 ? <<
+>>Quelle est la différence sur les champs d'adresse de l'en-tête IPv6 lors de l'envoi d'un message ICMPv6 NS utilisé dans le cadre de la procédure DAD par rapport à une résolution d'adresse IPv6 ? <<
-[x] Il n'y a pas d'option "adresse physique de la source".
+(x) Il n'y a pas d'adresse source d'indiquée dans l'en-tête du paquet IPv6.
-[x] Il n'y a pas d'adresse source d'indiquée dans l'en-tête du paquet IPv6.
+( ) L'adresse de destination du paquet IPv6 n'est pas une adresse multicast.
-[ ] L'adresse de destination du paquet IPv6 n'est pas une adresse multicast.
+( ) L'adresse de la cible est une adresse multicast sollicitée.
-[ ] L'adresse de la cible est une adresse multicast sollicitée.
+( ) Il n'y a pas de différence au niveau de l'en-tête IPv6
-Note : deux réponses valides
+Note : une seule réponses valide.
 [explanation]
-L'adresse de la source est dans un état provisoire et ne peut être utilisée. Elle ne peut pas encore être utilisée pour la résolution d'adresse. Normalement, le message NS ne doit être reçu par aucun noeud. Et, s'il est reçu par un noeud, ce dernier répond avec l'adresse <i>multicast all-node</i> comme destination. Comme la réponse n'est pas émise en unicast, l'adresse physique ne sert donc pas.
+L'adresse de la source est dans un état provisoire et ne peut être utilisée. Elle ne peut pas encore être utilisée pour la résolution d'adresse. L'adresse source de l'en-tête IPv6 est positionné à la valeur indéfinie ::. Normalement, le message NS ne doit être reçu par aucun noeud. Et, s'il est reçu par un noeud, ce dernier répond avec l'adresse <i>multicast all-node</i> comme destination.
 [explanation]

← Older revision		Revision as of 08:47, 4 April 2017
Line 4:		Line 4:

	= Session 3 =		= Session 3 =
		+	<pre>
		+	>>S3Q01. <<
		+	>>Comment distingue-t-on les messages ICMPv6 d'erreur des messages ICMPv6 d'information ? <<
		+	(x) Le champ type est inférieur à 128 pour les messages d'erreur.
		+	( ) Le champ type est supérieur ou égal à 128 pour les messages d'erreur.
		+	( ) Le champ code est différent de zéro.
		+	( ) Il n'y a pas de classement par les valeurs placées dans un champ quelconque d'un message ICMPv6.
		+	Note : une seule réponse valide
		+	[explanation]
		+	La valeur du champ type avec un bit de poids fort à 0 indique la catégorie des messages d'erreurs.
		+	[explanation]
		+
		+	>>S3Q02. <<
		+	>>Dans la procédure de détection d'adresse dupliquée, le message de sollicitation de voisin (NS) ne comporte pas d'adresse source. À quelle adresse un noeud qui reconnait son adresse dans le message NS doit-il envoyer le message d'annonce de voisin ? (indice, consulter la trace donnée en exemple dans le document compagnon) <<
		+	( ) À l'adresse de la cible du message NS.
		+	(x) À l'adresse "multicast all-node".
		+	( ) À l'adresse de source du message NS.
		+	( ) À l'adresse "multicast sollicité" associé à l'adresse cible.
		+	Note : une seule réponse valide
		+	[explanation]
		+	L'adresse FF02::1 est la seule adresse sur laquelle l'émetteur peut recevoir la réponse à sa requête. Son adresse unicast pour laquelle il effectue le test est dans un état provisoire et ne peut pas servir aux communications.
		+	[explanation]
		+
		+	>>S3Q03. <<
		+	>>La procédure de détection d'adresse dupliquée donne une réponse négative (pas de duplication d'adresse) quand : <<
		+	( ) un routeur local répond par un message ICMPv6 "router advertisement".
		+	( ) un noeud voisin répond par un message ICMPv6 "neighbor advertisement".
		+	(x) personne ne répond.
		+	( ) un noeud répond avec un message ICMPv6 "echo reply".
		+	Note : une seule réponse valide
		+	[explanation]
		+	Si personne ne répond, c'est que personne n'a reconnu l'adresse cible dans le message <i>neighbor sollicitation</i>. L'adresse IPv6 unicast est donc bien unique sur le lien.
		+	[explanation]
		+
		+	>>S3Q04. <<
		+	>>Quelles sont les différences dans l'envoi d'un message ICMPv6 NS lorsqu'il est utilisé dans une procédure DAD par rapport à une résolution d'adresse IPv6 ? <<
		+	[x] Il n'y a pas d'option "adresse physique de la source".
		+	[x] Il n'y a pas d'adresse source d'indiquée dans l'en-tête du paquet IPv6.
		+	[ ] L'adresse de destination du paquet IPv6 n'est pas une adresse multicast.
		+	[ ] L'adresse de la cible est une adresse multicast sollicitée.
		+	Note : deux réponses valides
		+	[explanation]
		+	L'adresse de la source est dans un état provisoire et ne peut être utilisée. Elle ne peut pas encore être utilisée pour la résolution d'adresse. Normalement, le message NS ne doit être reçu par aucun noeud. Et, s'il est reçu par un noeud, ce dernier répond avec l'adresse <i>multicast all-node</i> comme destination. Comme la réponse n'est pas émise en unicast, l'adresse physique ne sert donc pas.
		+	[explanation]
		+
		+	>>S3Q05. <<
		+	>>Un message ICMPv6 RA contient une option d'information sur le préfixe. Le champ longueur indique une valeur de 4. À combien d'octets cela correspond-il ? <<
		+	( ) 4 octets
		+	( ) 16 octets
		+	(x) 32 octets
		+	( ) 64 octets
		+	Note : une seule réponse valide
		+	[explanation]
		+	L'unité est le mot de 64 bits soit 8 octets. La longueur est donc de 8 * 4 = 32 octets.
		+	[explanation]
		+
		+	>>S3Q06.<<
		+	>> Pourquoi le <i>Hop Limit</i> mis dans l'en-tête d'un paquet IPv6 contenant un message ICMPv6 de découverte des voisins a-t-il une valeur de 255 ? <<
		+	( ) Car le paquet peut transiter sur l'immense Internet fourni par IPv6.
		+	( ) Car le paquet devient plus robuste. S'il passe par une boucle de routage, il aura une plus grande chance de survie.
		+	(x) Car si un noeud reçoit un paquet IPv6 avec une valeur plus petite, cela signifie que l'information provient d'un autre réseau : il doit être ignoré.
		+	( ) Car en cas de segmentation du paquet, le temps d'attente des fragments pour réassemblage sera plus important.
		+	Note : une seule réponse valide
		+	[explanation]
		+	Les messages NS, NA, RS et RA ne doivent pas transiter par un routeur. Ils ne sont utilisés qu'en communication directe. Le <i>Hop Limit</i> ne doit donc jamais être décrémenté. C'est un moyen simple de détection de messages intrus.
		+	[explanation]
		+
		+	>>S3Q07. <<
		+	>>Un administrateur réseau souhaite configurer les hôtes, de manière à ce qu'ils s'attribuent eux-mêmes leurs adresses IPv6 en utilisant des messages d'annonce de routeur, et de façon à ce qu'ils obtiennent les adresses des serveurs DNS depuis un serveur DHCPv6. Quelle méthode d'allocation d'adresse doit être configurée ? <<
		+	( ) DHCPv6 avec état
		+	(x) DHCPv6 sans état
		+	( ) SLAAC
		+	( ) RA / EUI-64 et relais DHCPv6
		+	Note : une seule réponse valide
		+	[explanation]
		+	La configuration DHCPv6 "sans état" autorise les clients à utiliser des messages d'annonce de routeur (RA) ICMPv6 pour s'attribuer automatiquement des adresses IPv6, tout en permettant à ces clients de contacter un serveur DHCPv6 pour obtenir des informations supplémentaires telles que le nom de domaine et l'adresse des serveurs DNS.
		+	[explanation]
		+
		+	>>S3Q08. <<
		+	>>Complétez la phrase en utilisant des chiffres et/ou des lettres minuscules : <<
		+	>>Le RFC<<
		+	= 3315
		+	>>décrit le protocole DHCPv6 et définit notamment le format des messages échangés. Les messages contenant les requêtes des clients et les réponses des serveurs débutent par un champ<<
		+	= type
		+	or= msg-type
		+	or= type-msg
		+	>>qui indique la nature du message, suivi d'un champ identificateur de <<
		+	= transaction
		+	>>qui permet d'associer les requêtes et les réponses.<<
		+
		+	[explanation]
		+	Le RFC 3315 décrit le protocole DHCPv6 et définit notamment le format des messages échangés. Les messages contenant les requêtes des clients et les réponses des serveurs débutent par un champ <i>type</i> qui indique la nature du message, suivi d'un champ identificateur de <i>transaction</i> qui permet d'associer les requêtes et les réponses.
		+	[explanation]
		+
		+	>>S3Q09. <<
		+	>>Parmi les propositions suivantes concernant les relais DHCPv6, indiquez celles qui sont vraies. <<
		+	[ ] Le champ <i>hop-count</i>, initialisé à une valeur non nulle dans l'en-tête du message RELAY-FORWARD par le premier relais atteint par un message SOLICIT, est décrémenté à chaque relais traversé. Lorsque ce champ atteint la valeur zéro, le datagramme est détruit.
		+	[x] Le champ <i>hop-count</i>, initialisé à zéro dans l'en-tête du message RELAY-FORWARD par le premier relais atteint par un message SOLICIT, est incrémenté à chaque relais traversé, jusqu'au serveur DHCPv6.
		+	[x] Un agent de relais DHCPv6 peut envoyer un message RELAY-FORWARD en unicast.
		+	[x] Un relais qui reçoit un message SOLICIT d'un client DHCPv6 encapsule sans la modifier cette requête dans un message RELAY-FORWARD.
		+	[ ] Un relais qui reçoit un message SOLICIT d'un client DHCPv6 met cette requête en attente dans une mémoire tampon et génère une demande spécifique dans le champ <i>option-list</i> du message RELAY-FORWARD.
		+	[ ] Un agent de relais DHCPv6 ne peut pas relayer de requête d'allocation de préfixe.
		+	Note : 3 réponses valides
		+	[explanation]
		+	Le RFC 3315 spécifie que lorsqu'aucun serveur DHCPv6 n'est présent sur le réseau local d'un client, un relais permet de transférer la requête d'allocation d'une adresse IPv6, ou d'un préfixe IPv6 dans le cas de la délégation de préfixe, dans un autre segment réseau qui contient un serveur DHCPv6 ou un autre agent de relais. Le premier agent de relais encapsule, sans le modifier, le message SOLICIT envoyé par le client, dans le champ <i>option-list</i> d'un message RELAY-FORWARD, envoyé en unicast ou en multicast (selon configuration). Le champ <i>hop-limit</i> est initialisé à zéro par le premier relais puis incrémenté d'une unité à chaque relais traversé. Un agent de relais qui reçoit un mesage RELAY-FORWARD avec une valeur de <i>hop-limit</i> égale à une valeur HOP-COUNT-LIMIT ignore ce message.
		+	[explanation]
		+
		+
		+	>>S3Q10.<<
		+	>>Parmi les types d'entrées DNS ci-dessous, lequel peut être inclus dans une zone de résolution inverse ? <<
		+	( ) AAAA
		+	( ) A
		+	(x) PTR
		+	( ) SRV
		+	( ) MX
		+	Note : une réponse valide
		+	[explanation]
		+	Les champs PTR sont utilisés dans les zones de résolution inverse tandis que les champs AAAA, A, MX et SRV ne sont utilisés que dans les zones de résolution directe. Les zones de résolution inverse et directe ne peuvent être contenues dans le même fichier. Par conséquent, une zone de résolution inverse ne pourra contenir que des RR de type PTR.
		+	[explanation]
		+
		+	>>S3Q11.<<
		+	>>Si un résolveur souhaite récupérer les adresses IPv6 associées à un FQDN, que 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.
		+	(x) 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.
		+	Note : une seule réponse valide
		+	[explanation]
		+	Le document compagnon indique à plusieurs reprises 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.
		+	[explanation]
		+
		+	>>S3Q12.<<
		+	>>Afin d'assurer la robustesse et le passage à l’échelle, les fichiers de zones d'un nom de domaine peuvent être consultables sur plusieurs serveurs. Parmi les propositions suivantes, lesquelles sont correctes ? <<
		+	[ ] 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 secondaires.
		+	[x] La modification ne peut se faire que sur le serveur primaire.
		+	[x] Il est indispensable d'incrémenter le numéro de série lors de la modification des entrées d'une zone.
		+	Note : deux réponses valides
		+	[explanation]
		+	Il n'est possible de modifier les entrées que sur le serveur maitre.
		+	[explanation]
		+	</pre>

	= Session 2 =		= Session 2 =

@@ Line 2: / Line 2: @@
 ----
 __NOTOC__
 <pre>

← Older revision		Revision as of 01:49, 19 March 2017
Line 1:		Line 1:
		+	[[MOOC:Accueil\|MOOC]] >[[MOOC:Contenu\|Contenu]]>[[MOOC:Quizz\|Quizzs]]
		+	----
		+	__NOTOC__
	<pre>		<pre>

@@ Line 108: / Line 108: @@
->>A34Q10.<<
+>>SQ10.<<
->>Parmi les types d'entrées DNS ci-dessous, lesquels peuvent être inclus dans une zone de résolution inverse ? (deux réponses valides)<<
+>>Parmi les types d'entrées DNS ci-dessous, lesquels peuvent être inclus dans une zone de résolution inverse ? (une réponse valide)<<
-[ ] AAAA
+( ) AAAA
-[ ] A
+( ) A
-[x] PTR
+(+) PTR
-[x] NS
+( ) SRV
-[ ] SRV
+( ) MX
-[ ] MX
 [explanation]

@@ Line 23: / Line 23: @@
 >>S3Q03. <<
->>La procédure de détection d'adresse dupliquée donne une réponse négative (pas de duplication d'adresses) quand : (une réponse valide)
+>>La procédure de détection d'adresse dupliquée donne une réponse négative (pas de duplication d'adresses) quand : (une réponse valide)<<
 <<
 ( ) un routeur local répond par un message ICMPv6 router advertisement.
 ( ) un noeud voisin répond par un message  ICMPv6 neighbor advertisement.
@@ Line 82: / Line 81: @@
 >>Le RFC <<
 = 3315
->> décrit le protocole DHCPv6 et définit notamment le format des messages échangés. Les messages contenant les requêtes des clients et les réponses des serveurs débutent par un champ <<
+>>décrit le protocole DHCPv6 et définit notamment le format des messages échangés. Les messages contenant les requêtes des clients et les réponses des serveurs débutent par un champ<<
 = type
 or= msg-type
@@ Line 89: / Line 88: @@
 = transaction
 >> qui permet d'associer les requêtes et réponses.<<
 [explanation]
 Le RFC 3315 décrit le protocole DHCPv6 et définit notamment le format des messages échangés. Les messages contenant les requêtes des clients et les réponses des serveurs débutent par un champ <tt>type</tt> qui indique la nature du message, suivi d'un champ identificateur de <tt>transaction</tt> qui permet d'associer les requêtes et les réponses.
@@ Line 112: / Line 112: @@
 [ ] AAAA
 [ ] A
-[X] PTR
+[x] PTR
-[X] NS
+[x] NS
 [ ] SRV
 [ ] MX
@@ Line 125: / Line 125: @@
 [ ] Il est indispensable qu'il transmette sa requête via IPv6.
 [ ] Il est indispensable qu'il transmette sa requête via IPv4.
-[X] La version du protocole IP pour l'émission de la requête est sans importance.
+[x] 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.
@@ Line 136: / Line 136: @@
 [ ] 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 secondaires.
-[X] La modification ne peut se faire que sur le serveur primaire.
+[x] La modification ne peut se faire que sur le serveur primaire.
-[X] Il est indispensable d'incrémenter le numéro de série lors de la modification des entrées d'une zone.
+[x] Il est indispensable d'incrémenter le numéro de série lors de la modification des entrées d'une zone.
 [explanation]
 Il n'est possible de modifier les entrées que sur le serveur maitre.