<?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="cs">
    <body>
      <trans-unit xml:space="preserve" id="80be3b4a05c88cbd">
        <source>The Domain Name System</source>
        <target></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" id="c635a4366de3a2e4">
        <source>The DNS header</source>
        <target></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" 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></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" 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></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" 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></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" id="76a6d68e5aba06ca">
        <source>DNS Resource Records</source>
        <target></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" 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></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" 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></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" id="15d8bd3a0ef7b344">
        <source>Query for the `AAAA` record of `www.ietf.org`</source>
        <target></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" 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></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" 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></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" id="799b36e36b03f425">
        <source>Reverse DNS</source>
        <target></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" 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></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" id="c463aea6549199a2">
        <source>Footnotes</source>
        <target></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" 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></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>
