<?xml version="1.0" encoding="UTF-8"?>
<xliff xmlns="urn:oasis:names:tc:xliff:document:1.1" version="1.1">
  <file original="NoName" source-language="en" datatype="plaintext" target-language="fr">
    <body>
      <trans-unit xml:space="preserve" approved="no" id="80be3b4a05c88cbd">
        <source>The Domain Name System</source>
        <target state="translated">Le système de nom de domaine (DNS)</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">7</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c635a4366de3a2e4">
        <source>The DNS header</source>
        <target state="translated">L'en-tête DNS</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">26</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="754dd851a23179fb">
        <source>The `Transaction ID` (transaction identifier) is a 16-bits random value chosen by the client. When a client sends a question to a DNS server, it remembers the question and its identifier. When a server returns an answer, it returns in the `Transaction ID` field the identifier chosen by the client. Thanks to this identifier, the client can match the received answer with the question that it sent.</source>
        <target state="translated">Le `Transaction ID` (identifiant de transaction) est une valeur aléatoire de 16 bits choisie par le client. Lorsqu'un client envoie une question à un serveur DNS, celui-ci se souvient de la question et de son identifiant. Lorsqu'un serveur retourne une réponse, il renvoie dans le champ `Transaction ID` l'identifiant choisi par le client. Grâce à cet identifiant, le client peut faire correspondre la réponse reçue avec la question qu'il a envoyée.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">28</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4904479a036bf97f">
        <source>The `RD` (recursion desired) bit is set by a client when it sends a query to a resolver. Such a query is said to be `recursive` because the resolver will recursively traverse the DNS hierarchy to retrieve the answer on behalf of the client. In the past, all resolvers were configured to perform recursive queries on behalf of any Internet host. However, this exposes the resolvers to several security risks. The simplest one is that the resolver could become overloaded by having too many recursive queries to process. Most resolvers [#f8888]_ only allow recursive queries from clients belonging to their company or network and discard all other recursive queries. The `RA` bit indicates whether the server supports recursion. The `RCODE` is used to distinguish between different types of errors. See :rfc:`1035` for additional details. The last four fields indicate the size of the `Question`, `Answer`, `Authority` and `Additional` sections of the DNS message.</source>
        <target state="translated">Le bit `RD` (recursion desired) est activé par un client lorsqu'il envoie une requête à un résolveur. Une telle requête est dite "récursive" parce que le résolveur va parcourir récursivement la hiérarchie DNS pour trouver la réponse au nom du client. Dans le passé, tous les résolveurs étaient configurés pour effectuer des requêtes récursives pour le compte de n'importe quel hôte Internet. Cependant, cela expose les résolveurs à plusieurs risques de sécurité. Le plus simple est que le résolveur peut être surchargé par un trop grand nombre de requêtes récursives à traiter. La plupart des résolveurs [#f8888]_ n'autorisent que les requêtes récursives des clients appartenant à leur société ou à leur réseau et rejettent toutes les autres requêtes récursives. Le bit `RA` indique si le serveur supporte la récursivité. Le `RCODE` est utilisé pour distinguer les différents types d'erreurs. Voir :rfc:`1035` pour plus de détails. Les quatre derniers champs indiquent la taille des sections `Question`, `Answer`, `Authority` et `Additional` du message DNS.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">40</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b72c729ca56ba3f8">
        <source>The last four sections of the DNS message contain `Resource Records` (RR).  All RRs have the same top level format shown in the figure below.</source>
        <target state="translated">Les quatre dernières sections du message DNS contiennent les `Resource Records` (RR).  Tous les RR ont le même format de haut niveau, comme le montre la figure ci-dessous.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">42</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="76a6d68e5aba06ca">
        <source>DNS Resource Records</source>
        <target state="translated">DNS Resource Records</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">48</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="42275bd85e624992">
        <source>The `TTL` field indicates the lifetime of the `Resource Record` in seconds. This field is set by the server that returns an answer and indicates for how long a client or a resolver can store the `Resource Record` inside its cache. A long `TTL` indicates a stable `RR`. Some companies use short `TTL` values for mobile hosts and also for popular servers. For example, a web hosting company that wants to spread the load over a pool of hundred servers can configure its nameservers to return different answers to different clients. If each answer has a small `TTL`, the clients will be forced to send DNS queries regularly. The nameserver will reply to these queries by supplying the address of the less loaded server.</source>
        <target state="translated">Le champ `TTL` indique la durée de vie de la `Resource Record` en secondes. Ce champ est défini par le serveur qui renvoie une réponse et indique pendant combien de temps un client ou un résolveur peut stocker le `Resource Record` dans son cache. Un `TTL` long indique un `RR` stable. Certaines entreprises utilisent des valeurs `TTL` courtes pour les hôtes mobiles et aussi pour les serveurs populaires. Par exemple, une société d'hébergement web qui veut répartir la charge sur un pool de cent serveurs peut configurer ses serveurs de noms pour qu'ils renvoient des réponses différentes à des clients différents. Si chaque réponse a une petite `TTL`, les clients seront obligés d'envoyer régulièrement des requêtes DNS. Le serveur de noms répondra à ces requêtes en fournissant l'adresse du serveur le moins chargé.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">52</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="76c071671aafc97e">
        <source>The `RDLength` field is the length of the `RData` field that contains the information of the type specified in the `Type` field.</source>
        <target state="translated">Le champ `RDLength` est la longueur du champ `RData` qui contient les informations du type spécifié dans le champ `Type`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">54</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="15d8bd3a0ef7b344">
        <source>Query for the `AAAA` record of `www.ietf.org`</source>
        <target state="translated">Requête pour l'enregistrement `AAAA` de `www.ietf.org`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">61</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="58aea075f96d4d18">
        <source>This answer contains several pieces of information. First, the name `www.ietf.org` is associated to IP address `2001:1890:123a::1:1e`. Second, the `ietf.org` domain is managed by six different nameservers. Five of these nameservers are reachable via IPv4 and IPv6.</source>
        <target state="translated">Cette réponse contient plusieurs informations. Premièrement, le nom `www.ietf.org` est associé à l'adresse IP `2001:1890:123a::1:1e`. Deuxièmement, le domaine `ietf.org` est géré par six serveurs de noms différents. Cinq de ces serveurs de noms sont joignables via IPv4 et IPv6.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">63</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6437b28603ae9a12">
        <source>`CNAME` (or canonical names) are used to define aliases. For example `www.example.com` could be a `CNAME` for `pc12.example.com` that is the actual name of the server on which the web server for `www.example.com` runs.</source>
        <target state="translated">Les `CNAME` (ou noms canoniques) sont utilisés pour définir des alias. Par exemple, `www.example.com` pourrait être un `CNAME` pour `pc12.example.com` qui est le nom réel du serveur sur lequel tourne le serveur web de `www.example.com`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">65</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="799b36e36b03f425">
        <source>Reverse DNS</source>
        <target state="translated">Reverse DNS</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">67</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d1d0094c27a653d2">
        <source>The DNS is mainly used to find the address that corresponds to a given name. However, it is sometimes useful to obtain the name that corresponds to an IP address. This done by using the `PTR` (`pointer`) `RR`. The `RData` part of a `PTR` `RR` contains the name while the `Name` part of the `RR` contains the IP address encoded in the `in-addr.arpa` domain. IPv4 addresses are encoded in the `in-addr.arpa` by reversing the four digits that compose the dotted decimal representation of the address. For example, consider IPv4 address `192.0.2.11`. The hostname associated to this address can be found by requesting the `PTR`  `RR` that corresponds to `11.2.0.192.in-addr.arpa`. A similar solution is used to support IPv6 addresses :rfc:`3596`, but slightly more complex given the length of the IPv6 addresses. For example, consider IPv6 address `2001:1890:123a::1:1e`. To obtain the name that corresponds to this address, we need first to convert it in a reverse dotted decimal notation : `e.1.0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.3.2.1.0.9.8.1.1.0.0.2`. In this notation, each character between dots corresponds to one nibble, i.e. four bits. The low-order byte (`e`) appears first and the high order (`2`) last. To obtain the name that corresponds to this address, one needs to append the `ip6.arpa` domain name and query for `e.1.0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.3.2.1.0.9.8.1.1.0.0.2.ip6.arpa`. In practice, tools and libraries do the conversion automatically and the user does not need to worry about it.</source>
        <target state="translated">Le DNS est principalement utilisé pour trouver l'adresse qui correspond à un nom donné. Cependant, il est parfois utile d'obtenir le nom qui correspond à une adresse IP. Pour ce faire, on utilise le `PTR` (`pointer`) `RR`. La partie `RData` d'un `PTR` `RR` contient le nom tandis que la partie `Name` du `RR` contient l'adresse IP encodée dans le domaine `in-addr.arpa`. Les adresses IPv4 sont codées dans le domaine `in-addr.arpa` en inversant les quatre chiffres qui composent la représentation décimale en pointillés de l'adresse. Par exemple, prenons l'adresse IPv4 `192.0.2.11`. Le nom d'hôte associé à cette adresse peut être trouvé en demandant le `PTR` `RR` qui correspond à `11.2.0.192.in-addr.arpa`. Une solution similaire est utilisée pour supporter les adresses IPv6 :rfc:`3596`, mais légèrement plus complexe étant donné la longueur des adresses IPv6. Par exemple, considérons l'adresse IPv6 `2001:1890:123a::1:1e`. Pour obtenir le nom qui correspond à cette adresse, il faut d'abord la convertir dans une notation décimale pointillée inverse : `e.1.0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.3.2.1.0.9.8.1.1.0.0.2`. Dans cette notation, chaque caractère entre les points correspond à un nibble, c'est-à-dire à quatre bits. L'octet de poids faible (`e`) apparaît en premier et celui de poids fort (`2`) en dernier. Pour obtenir le nom correspondant à cette adresse, il faut ajouter le nom de domaine `ip6.arpa` et rechercher `e.1.0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.a.3.2.1.0.9.8.1.1.1.0.0.2.ip6.arpa`. En pratique, les outils et les bibliothèques font la conversion automatiquement et l'utilisateur n'a pas à s'en soucier.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">69</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c463aea6549199a2">
        <source>Footnotes</source>
        <target state="translated">Notes de pied de page</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">80</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7a314648abced33e">
        <source>Some DNS resolvers allow any host to send queries. Google operates a `public DNS resolver &lt;https://developers.google.com/speed/public-dns/docs/using&gt;`_ at addresses `2001:4860:4860::8888` and `2001:4860:4860::8844`. Other companies provide similar services.</source>
        <target state="translated">Certains résolveurs DNS permettent à tout hôte d'envoyer des requêtes. Google exploite un `résolveur DNS public &lt;https://developers.google.com/speed/public-dns/docs/using&gt;`_ aux adresses `2001:4860:4860::8888` et `2001:4860:4860::8844`. D'autres sociétés fournissent des services similaires.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">81</context>
        </context-group>
      </trans-unit>
    </body>
  </file>
</xliff>
