<?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="en">
    <body>
      <trans-unit xml:space="preserve" approved="no" id="80be3b4a05c88cbd" weblate-flags="read-only">
        <source>The Domain Name System</source>
        <target state="translated">The Domain Name System</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="49d4aef5d794857f" weblate-flags="read-only">
        <source>We have already explained the main principles that underlie the utilization of names on the Internet and their mapping to addresses in section :ref:`naming`.</source>
        <target state="translated">We have already explained the main principles that underlie the utilization of names on the Internet and their mapping to addresses in section :ref:`naming`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">9</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2f290599c9ea3a4f" weblate-flags="read-only">
        <source>The last component of the Domain Name System is the DNS protocol. The original DNS protocol runs above both the datagram and the bytestream services. In practice, the datagram service is used when short queries and responses are exchanged, and the bytestream service is used when longer responses are expected. In this section, we first focus on the utilization of the DNS protocol above the datagram service. We will discuss later other recently proposed protocols to carry DNS information.</source>
        <target state="translated">The last component of the Domain Name System is the DNS protocol. The original DNS protocol runs above both the datagram and the bytestream services. In practice, the datagram service is used when short queries and responses are exchanged, and the bytestream service is used when longer responses are expected. In this section, we first focus on the utilization of the DNS protocol above the datagram service. We will discuss later other recently proposed protocols to carry DNS information.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">12</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a296a7ea768515cf" weblate-flags="read-only">
        <source>DNS messages are composed of five parts that are named sections in :rfc:`1035`. The first three sections are mandatory and the last two sections are optional. The first section of a DNS message is its `Header`. It contains information about the message type and the content of the other sections. The second section contains the `Question` sent to the nameserver or resolver. The third section contains the `Answer` to the `Question`. When a client sends a DNS query, the `Answer` section is empty. The fourth section, named `Authority`, contains information about the servers that can provide an authoritative answer if required. The last section contains additional information that is supplied by the resolver or nameserver but was not requested in the question.</source>
        <target state="translated">DNS messages are composed of five parts that are named sections in :rfc:`1035`. The first three sections are mandatory and the last two sections are optional. The first section of a DNS message is its `Header`. It contains information about the message type and the content of the other sections. The second section contains the `Question` sent to the nameserver or resolver. The third section contains the `Answer` to the `Question`. When a client sends a DNS query, the `Answer` section is empty. The fourth section, named `Authority`, contains information about the servers that can provide an authoritative answer if required. The last section contains additional information that is supplied by the resolver or nameserver but was not requested in the question.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">16</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a47cf16b053aedb0" weblate-flags="read-only">
        <source>The header of DNS messages is composed of 12 bytes. The figure below presents its structure.</source>
        <target state="translated">The header of DNS messages is composed of 12 bytes. The figure below presents its structure.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">18</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c635a4366de3a2e4" weblate-flags="read-only">
        <source>The DNS header</source>
        <target state="translated">The DNS header</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">24</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="754dd851a23179fb" weblate-flags="read-only">
        <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">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.</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="c9cf8dc6f50cb3f2" weblate-flags="read-only">
        <source>The DNS header contains a series of flags. The `QR` flag is used to distinguish between queries and responses. It is set to `0` in DNS queries and `1` in DNS answers. The `Opcode` is used to specify the query type. For instance, a :term:`standard query` is used when a client sends a `name` and the server returns the corresponding `data`. An update request is used when the client sends a `name` and new `data` and the server then updates its database.</source>
        <target state="translated">The DNS header contains a series of flags. The `QR` flag is used to distinguish between queries and responses. It is set to `0` in DNS queries and `1` in DNS answers. The `Opcode` is used to specify the query type. For instance, a :term:`standard query` is used when a client sends a `name` and the server returns the corresponding `data`. An update request is used when the client sends a `name` and new `data` and the server then updates its database.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">33</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6ec07815b51e3598" weblate-flags="read-only">
        <source>The `AA` bit is set when the server that sent the response has `authority` for the domain name found in the question section. In the original DNS deployments, two types of servers were considered : `authoritative` servers and `non-authoritative` servers. The `authoritative` servers are managed by the system administrators responsible for a given domain. They always store the most recent information about a domain. `Non-authoritative` servers are servers or resolvers that store DNS information about external domains without being managed by the owners of a domain. They may thus provide answers that are out of date. From a security point of view, the `authoritative` bit is not an absolute indication about the validity of an answer. Securing the Domain Name System is a complex problem that was only addressed satisfactorily recently by the utilization of cryptographic signatures in the DNSSEC extensions to DNS described in :rfc:`4033`.</source>
        <target state="translated">The `AA` bit is set when the server that sent the response has `authority` for the domain name found in the question section. In the original DNS deployments, two types of servers were considered : `authoritative` servers and `non-authoritative` servers. The `authoritative` servers are managed by the system administrators responsible for a given domain. They always store the most recent information about a domain. `Non-authoritative` servers are servers or resolvers that store DNS information about external domains without being managed by the owners of a domain. They may thus provide answers that are out of date. From a security point of view, the `authoritative` bit is not an absolute indication about the validity of an answer. Securing the Domain Name System is a complex problem that was only addressed satisfactorily recently by the utilization of cryptographic signatures in the DNSSEC extensions to DNS described in :rfc:`4033`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">35</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4904479a036bf97f" weblate-flags="read-only">
        <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">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">39</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b72c729ca56ba3f8" weblate-flags="read-only">
        <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">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">41</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="76a6d68e5aba06ca" weblate-flags="read-only">
        <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">47</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1534a6eb5387477d" weblate-flags="read-only">
        <source>In a `Resource Record` (`RR`), the `Name` indicates the name of the node to which this resource record pertains. The two-)bytes `Type` field indicates the type of resource record. The `Class` field was used to support the utilization of the DNS in other environments than the Internet. The `IN` `Class` refers to Internet names.</source>
        <target state="translated">In a `Resource Record` (`RR`), the `Name` indicates the name of the node to which this resource record pertains. The two-)bytes `Type` field indicates the type of resource record. The `Class` field was used to support the utilization of the DNS in other environments than the Internet. The `IN` `Class` refers to Internet names.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">49</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="42275bd85e624992" weblate-flags="read-only">
        <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">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">51</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="76c071671aafc97e" weblate-flags="read-only">
        <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">The `RDLength` field is the length of the `RData` field that contains the information of the type specified in the `Type` field.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">53</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e82a732fbabbd3ca" weblate-flags="read-only">
        <source>Several types of DNS RR are used in practice. The `A` type encodes the IPv4 address that corresponds to the specified name. The `AAAA` type encodes the IPv6 address that corresponds to the specified name. A `NS` record contains the name of the DNS server that is responsible for a given domain. For example, a query for the `AAAA` record associated to the `www.ietf.org` name returned the following answer.</source>
        <target state="translated">Several types of DNS RR are used in practice. The `A` type encodes the IPv4 address that corresponds to the specified name. The `AAAA` type encodes the IPv6 address that corresponds to the specified name. A `NS` record contains the name of the DNS server that is responsible for a given domain. For example, a query for the `AAAA` record associated to the `www.ietf.org` name returned the following answer.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">55</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="15d8bd3a0ef7b344" weblate-flags="read-only">
        <source>Query for the `AAAA` record of `www.ietf.org`</source>
        <target state="translated">Query for the `AAAA` record of `www.ietf.org`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">60</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="58aea075f96d4d18" weblate-flags="read-only">
        <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">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">62</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6437b28603ae9a12" weblate-flags="read-only">
        <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">`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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">64</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="799b36e36b03f425" weblate-flags="read-only">
        <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">66</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d1d0094c27a653d2" weblate-flags="read-only">
        <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">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">68</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2c7cfb4f4e284c63" weblate-flags="read-only">
        <source>An important point to note regarding the Domain Name System it that it is extensible. Thanks to the `Type` and `RDLength` fields, the format of the Resource Records can easily be extended. Furthermore, a DNS implementation that receives a new Resource Record that it does not understand can ignore the record while still being able to process the other parts of the message. This allows, for example, a DNS server that only supports IPv6 to safely ignore the IPv4 addresses listed in the DNS reply for `www.ietf.org` while still being able to correctly parse the Resource Records that it understands. This allowed the Domain Name System to evolve over the years while still preserving the backward compatibility with already deployed DNS implementations.</source>
        <target state="translated">An important point to note regarding the Domain Name System it that it is extensible. Thanks to the `Type` and `RDLength` fields, the format of the Resource Records can easily be extended. Furthermore, a DNS implementation that receives a new Resource Record that it does not understand can ignore the record while still being able to process the other parts of the message. This allows, for example, a DNS server that only supports IPv6 to safely ignore the IPv4 addresses listed in the DNS reply for `www.ietf.org` while still being able to correctly parse the Resource Records that it understands. This allowed the Domain Name System to evolve over the years while still preserving the backward compatibility with already deployed DNS implementations.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">71</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c463aea6549199a2" weblate-flags="read-only">
        <source>Footnotes</source>
        <target state="translated">Footnotes</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">79</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7a314648abced33e" weblate-flags="read-only">
        <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">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/dns.rst</context>
          <context context-type="linenumber">80</context>
        </context-group>
      </trans-unit>
    </body>
  </file>
</xliff>
