<?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="00c5aa054b0e8cd4" weblate-flags="read-only">
        <source>Naming and addressing</source>
        <target state="translated">Naming and addressing</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">9</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3bfc6c9bb6571b23" weblate-flags="read-only">
        <source>The network and the transport layers rely on addresses that are encoded as fixed size bit strings. A network layer address uniquely identifies a host. Several transport layer entities can use the service of the same network layer. For example, a reliable transport protocol and a connectionless transport protocol can coexist on the same host. In this case, the network layer multiplexes the segments produced by these two protocols. This multiplexing is usually achieved by placing in the network packet header a field that indicates which transport protocol should process the segment. Given that there are few different transport protocols, this field does not need to be long. The port numbers play a similar role in the transport layer since they enable it to multiplex data from several application processes.</source>
        <target state="translated">The network and the transport layers rely on addresses that are encoded as fixed size bit strings. A network layer address uniquely identifies a host. Several transport layer entities can use the service of the same network layer. For example, a reliable transport protocol and a connectionless transport protocol can coexist on the same host. In this case, the network layer multiplexes the segments produced by these two protocols. This multiplexing is usually achieved by placing in the network packet header a field that indicates which transport protocol should process the segment. Given that there are few different transport protocols, this field does not need to be long. The port numbers play a similar role in the transport layer since they enable it to multiplex data from several application processes.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">11</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="efa7c5aa9d1488b0" weblate-flags="read-only">
        <source>While addresses are natural for the network and transport layer entities, humans prefer to use names when interacting with network services. Names can be encoded as a character string and a mapping services allows applications to map a name into the corresponding address. Using names is friendlier for humans, but it also provides a level of indirection which is very useful in many situations.</source>
        <target state="translated">While addresses are natural for the network and transport layer entities, humans prefer to use names when interacting with network services. Names can be encoded as a character string and a mapping services allows applications to map a name into the corresponding address. Using names is friendlier for humans, but it also provides a level of indirection which is very useful in many situations.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">13</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6dd65c5815660f27" weblate-flags="read-only">
        <source>In the early days of the Internet, only a few hosts (mainly minicomputers) were connected to the network. The most popular applications were :term:`remote login` and file transfer. By 1983, there were already five hundred hosts attached to the Internet [Zakon]_. Each of these hosts were identified by a unique address. Forcing human users to remember the addresses of the hosts that they wanted to use was not user-friendly. Humans prefer to remember names, and use them when needed. Using names as aliases for addresses is a common technique in Computer Science. It simplifies the development of applications and allows the developer to ignore the low level details. For example, by using a programming language instead of writing machine code, a developer can write software without knowing whether the variables that it uses are stored in memory or inside registers.</source>
        <target state="translated">In the early days of the Internet, only a few hosts (mainly minicomputers) were connected to the network. The most popular applications were :term:`remote login` and file transfer. By 1983, there were already five hundred hosts attached to the Internet [Zakon]_. Each of these hosts were identified by a unique address. Forcing human users to remember the addresses of the hosts that they wanted to use was not user-friendly. Humans prefer to remember names, and use them when needed. Using names as aliases for addresses is a common technique in Computer Science. It simplifies the development of applications and allows the developer to ignore the low level details. For example, by using a programming language instead of writing machine code, a developer can write software without knowing whether the variables that it uses are stored in memory or inside registers.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">15</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a32953c8c5bb1ab0" weblate-flags="read-only">
        <source>Because names are at a higher level than addresses, they allow (both in the example of programming above, and on the Internet) to treat addresses as mere technical identifiers, which can change at will. Only the names are stable.</source>
        <target state="translated">Because names are at a higher level than addresses, they allow (both in the example of programming above, and on the Internet) to treat addresses as mere technical identifiers, which can change at will. Only the names are stable.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">17</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b8bceb831d61d647" weblate-flags="read-only">
        <source>The first solution that allowed applications to use names was the :term:`hosts.txt` file. This file is similar to the symbol table found in compiled code. It contains the mapping between the name of each Internet host and its associated address [#fhosts]_. It was maintained by SRI International that coordinated the Network Information Center (NIC). When a new host was connected to the network, the system administrator had to register its name and address at the NIC. The NIC updated the :term:`hosts.txt` file on its server. All Internet hosts regularly retrieved the updated :term:`hosts.txt` file from the SRI_ server. This file was stored at a well-known location on each Internet host (see :rfc:`952`) and networked applications could use it to find the address corresponding to a name.</source>
        <target state="translated">The first solution that allowed applications to use names was the :term:`hosts.txt` file. This file is similar to the symbol table found in compiled code. It contains the mapping between the name of each Internet host and its associated address [#fhosts]_. It was maintained by SRI International that coordinated the Network Information Center (NIC). When a new host was connected to the network, the system administrator had to register its name and address at the NIC. The NIC updated the :term:`hosts.txt` file on its server. All Internet hosts regularly retrieved the updated :term:`hosts.txt` file from the SRI_ server. This file was stored at a well-known location on each Internet host (see :rfc:`952`) and networked applications could use it to find the address corresponding to a name.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">21</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="effe903cc6973241" weblate-flags="read-only">
        <source>A :term:`hosts.txt` file can be used when there are up to a few hundred hosts on the network. However, it is clearly not suitable for a network containing thousands or millions of hosts. A key issue in a large network is to define a suitable naming scheme. The ARPANet initially used a flat naming space, i.e. each host was assigned a unique name. To limit collisions between names, these names usually contained the name of the institution and a suffix to identify the host inside the institution (a kind of poor man's hierarchical naming scheme). On the ARPANet few institutions had several hosts connected to the network.</source>
        <target state="translated">A :term:`hosts.txt` file can be used when there are up to a few hundred hosts on the network. However, it is clearly not suitable for a network containing thousands or millions of hosts. A key issue in a large network is to define a suitable naming scheme. The ARPANet initially used a flat naming space, i.e. each host was assigned a unique name. To limit collisions between names, these names usually contained the name of the institution and a suffix to identify the host inside the institution (a kind of poor man's hierarchical naming scheme). On the ARPANet few institutions had several hosts connected to the network.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">23</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="48d6037348c168bd" weblate-flags="read-only">
        <source>However, the limitations of a flat naming scheme became clear before the end of the ARPANet and :rfc:`819` proposed a hierarchical naming scheme. While :rfc:`819` discussed the possibility of organizing the names as a directed graph, the Internet opted for a tree structure capable of containing all names. In this tree, the top-level domains are those that are directly attached to the root. The first top-level domain was `.arpa` [#fdnstimeline]_. This top-level name was initially added as a suffix to the names of the hosts attached to the ARPANet and listed in the `hosts.txt` file. In 1984, the `.gov`, `.edu`, `.com`, `.mil` and `.org` generic top-level domain names were added. :rfc:`1032` proposed the utilization of the two letter :term:`ISO-3166` country codes as top-level domain names. Since :term:`ISO-3166` defines a two letter code for each country recognized by the United Nations, this allowed all countries to automatically have a top-level domain. These domains include `.be` for Belgium, `.fr` for France, `.us` for the USA, `.ie` for Ireland or `.tv` for Tuvalu, a group of small islands in the Pacific or `.tm` for Turkmenistan. The set of top-level domain-names is managed by the Internet Corporation for Assigned Names and Numbers (:term:`ICANN`). :term:`ICANN` adds generic top-level domains that are not related to a country and the `.cat` top-level domain has been registered for the Catalan language. There are ongoing discussions within :term:`ICANN` to increase the number of top-level domains.</source>
        <target state="translated">However, the limitations of a flat naming scheme became clear before the end of the ARPANet and :rfc:`819` proposed a hierarchical naming scheme. While :rfc:`819` discussed the possibility of organizing the names as a directed graph, the Internet opted for a tree structure capable of containing all names. In this tree, the top-level domains are those that are directly attached to the root. The first top-level domain was `.arpa` [#fdnstimeline]_. This top-level name was initially added as a suffix to the names of the hosts attached to the ARPANet and listed in the `hosts.txt` file. In 1984, the `.gov`, `.edu`, `.com`, `.mil` and `.org` generic top-level domain names were added. :rfc:`1032` proposed the utilization of the two letter :term:`ISO-3166` country codes as top-level domain names. Since :term:`ISO-3166` defines a two letter code for each country recognized by the United Nations, this allowed all countries to automatically have a top-level domain. These domains include `.be` for Belgium, `.fr` for France, `.us` for the USA, `.ie` for Ireland or `.tv` for Tuvalu, a group of small islands in the Pacific or `.tm` for Turkmenistan. The set of top-level domain-names is managed by the Internet Corporation for Assigned Names and Numbers (:term:`ICANN`). :term:`ICANN` adds generic top-level domains that are not related to a country and the `.cat` top-level domain has been registered for the Catalan language. There are ongoing discussions within :term:`ICANN` to increase the number of top-level domains.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">25</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8fc11168c0fddfe6" weblate-flags="read-only">
        <source>Each top-level domain is managed by an organization that decides how sub-domain names can be registered. Most top-level domain names use a first-come first served system, and allow anyone to register domain names, but there are some exceptions. For example, `.gov` is reserved for the US government, `.int` is reserved for international organizations and names in the `.ca` are mainly `reserved &lt;http://en.wikipedia.org/wiki/.ca&gt;`_ for companies or users that are present in Canada.</source>
        <target state="translated">Each top-level domain is managed by an organization that decides how sub-domain names can be registered. Most top-level domain names use a first-come first served system, and allow anyone to register domain names, but there are some exceptions. For example, `.gov` is reserved for the US government, `.int` is reserved for international organizations and names in the `.ca` are mainly `reserved &lt;http://en.wikipedia.org/wiki/.ca&gt;`_ for companies or users that are present in Canada.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">27</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0378fef03977965b" weblate-flags="read-only">
        <source>The syntax of the domain names has been defined more precisely in :rfc:`1035`. This document recommends the following :term:`BNF` for fully qualified domain names (the domain names themselves have a much richer syntax).</source>
        <target state="translated">The syntax of the domain names has been defined more precisely in :rfc:`1035`. This document recommends the following :term:`BNF` for fully qualified domain names (the domain names themselves have a much richer syntax).</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">56</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2df3e871368ee9aa" weblate-flags="read-only">
        <source>BNF of the fully qualified host names</source>
        <target state="translated">BNF of the fully qualified host names</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">61</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f78795129bc81688" weblate-flags="read-only">
        <source>This grammar specifies that a host name is an ordered list of labels separated by the dot (`.`) character. Each label can contain letters, numbers and the hyphen character (`-`) [#fidn]_. Fully qualified domain names are read from left to right. The first label is a hostname or a domain name followed by the hierarchy of domains and ending with the root implicitly at the right. The top-level domain name must be one of the registered TLDs [#ftld]_. For example, in the above figure, `www.computer-networking.info` corresponds to a host named `www` inside the `computer-networking` domain that belongs to the `info` top-level domain.</source>
        <target state="translated">This grammar specifies that a host name is an ordered list of labels separated by the dot (`.`) character. Each label can contain letters, numbers and the hyphen character (`-`) [#fidn]_. Fully qualified domain names are read from left to right. The first label is a hostname or a domain name followed by the hierarchy of domains and ending with the root implicitly at the right. The top-level domain name must be one of the registered TLDs [#ftld]_. For example, in the above figure, `www.computer-networking.info` corresponds to a host named `www` inside the `computer-networking` domain that belongs to the `info` top-level domain.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">75</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="431733fd78109415" weblate-flags="read-only">
        <source>Some visually similar characters have different character codes</source>
        <target state="translated">Some visually similar characters have different character codes</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">77</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5dd050aa1bea0e71" weblate-flags="read-only">
        <source>The Domain Name System was created at a time when the Internet was mainly used in North America. The initial design assumed that all domain names would be composed of letters and digits :rfc:`1035`. As Internet usage grew in other parts of the world, it became important to support non-ASCII characters. For this, extensions have been proposed to the Domain Name System :rfc:`3490`. In a nutshell, the solution that is used to support Internationalized Domain Names works as follows. First, it is possible to use most of the Unicode characters to encode domain names and hostnames, with a few exceptions (for example, the dot character cannot be part of a name since it is used as a separator). Once a domain name has been encoded as a series of Unicode characters, it is then converted into a string that contains the ``xn--`` prefix and a sequence of ASCII characters. More details on these algorithms can be found in :rfc:`3490` and :rfc:`3492`.</source>
        <target state="translated">The Domain Name System was created at a time when the Internet was mainly used in North America. The initial design assumed that all domain names would be composed of letters and digits :rfc:`1035`. As Internet usage grew in other parts of the world, it became important to support non-ASCII characters. For this, extensions have been proposed to the Domain Name System :rfc:`3490`. In a nutshell, the solution that is used to support Internationalized Domain Names works as follows. First, it is possible to use most of the Unicode characters to encode domain names and hostnames, with a few exceptions (for example, the dot character cannot be part of a name since it is used as a separator). Once a domain name has been encoded as a series of Unicode characters, it is then converted into a string that contains the ``xn--`` prefix and a sequence of ASCII characters. More details on these algorithms can be found in :rfc:`3490` and :rfc:`3492`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">79</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9523d68acc2e9500" weblate-flags="read-only">
        <source>The possibility of using all Unicode characters to create domain names opened a new form of attack called the `homograph attack &lt;https://en.wikipedia.org/wiki/IDN_homograph_attack&gt;`_. This attack occurs when two character strings or domain names are visually similar but do not correspond to the same server. A simple example is https://G00GLE.COM and https://GOOGLE.COM. These two URLs are visually close but they correspond to different names (the first one does not point to a valid server [#fg00gle]_). With other Unicode characters, it is possible to construct domain names are visually equivalent to existing ones. See [Zhe2017]_ for additional details on this attack.</source>
        <target state="translated">The possibility of using all Unicode characters to create domain names opened a new form of attack called the `homograph attack &lt;https://en.wikipedia.org/wiki/IDN_homograph_attack&gt;`_. This attack occurs when two character strings or domain names are visually similar but do not correspond to the same server. A simple example is https://G00GLE.COM and https://GOOGLE.COM. These two URLs are visually close but they correspond to different names (the first one does not point to a valid server [#fg00gle]_). With other Unicode characters, it is possible to construct domain names are visually equivalent to existing ones. See [Zhe2017]_ for additional details on this attack.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">81</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="69388d03ea669123" weblate-flags="read-only">
        <source>This hierarchical naming scheme is a key component of the Domain Name System (DNS). The DNS is a distributed database that contains mappings between fully qualified domain names and addresses. The DNS uses the client-server model. The clients are hosts or applications that need to retrieve the mapping for a given name. Each :term:`nameserver` stores part of the distributed database and answers the queries sent by clients. There is at least one :term:`nameserver` that is responsible for each domain. In the figure below, domains are represented by circles and there are three hosts inside domain `dom` (`h1`, `h2` and `h3`) and three hosts inside domain `a.sdom1.dom`. As shown in the figure below, a sub-domain may contain both host names and sub-domains.</source>
        <target state="translated">This hierarchical naming scheme is a key component of the Domain Name System (DNS). The DNS is a distributed database that contains mappings between fully qualified domain names and addresses. The DNS uses the client-server model. The clients are hosts or applications that need to retrieve the mapping for a given name. Each :term:`nameserver` stores part of the distributed database and answers the queries sent by clients. There is at least one :term:`nameserver` that is responsible for each domain. In the figure below, domains are represented by circles and there are three hosts inside domain `dom` (`h1`, `h2` and `h3`) and three hosts inside domain `a.sdom1.dom`. As shown in the figure below, a sub-domain may contain both host names and sub-domains.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">84</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2fe7ebc3f58dacbe" weblate-flags="read-only">
        <source>A :term:`nameserver` that is responsible for domain `dom` can directly answer the following queries :</source>
        <target state="translated">A :term:`nameserver` that is responsible for domain `dom` can directly answer the following queries :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">109</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="20694affaefa28fc" weblate-flags="read-only">
        <source>the address of any host residing directly inside domain `dom` (e.g. `h2.dom` in the figure above)</source>
        <target state="translated">the address of any host residing directly inside domain `dom` (e.g. `h2.dom` in the figure above)</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">111</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3088f26c21ca9535" weblate-flags="read-only">
        <source>the nameserver(s) that are responsible for any direct sub-domain of domain `dom` (i.e. `sdom1.dom` and `sdom2.dom` in the figure above, but not `z.sdom1.dom`)</source>
        <target state="translated">the nameserver(s) that are responsible for any direct sub-domain of domain `dom` (i.e. `sdom1.dom` and `sdom2.dom` in the figure above, but not `z.sdom1.dom`)</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">112</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f310bfb0c8b21499" weblate-flags="read-only">
        <source>To retrieve the mapping for host `h2.dom`, a client sends its query to the name server that is responsible for domain `.dom`. The name server directly answers the query. To retrieve a mapping for `h3.a.sdom1.dom` a DNS client first sends a query to the name server that is responsible for the `.dom` domain. This nameserver returns the nameserver that is responsible for the `sdom1.dom` domain. This nameserver can now be contacted to obtain the nameserver that is responsible for the `a.sdom1.dom` domain. This nameserver can be contacted to retrieve the mapping for the `h3.a.sdom1.dom` name. Thanks to this structure, it is possible for a DNS client to obtain the mapping of any host inside the `.dom` domain or any of its subdomains. To ensure that any DNS client will be able to resolve any fully qualified domain name, there are special nameservers that are responsible for the root of the domain name hierarchy. These nameservers are called :term:`root nameserver`.</source>
        <target state="translated">To retrieve the mapping for host `h2.dom`, a client sends its query to the name server that is responsible for domain `.dom`. The name server directly answers the query. To retrieve a mapping for `h3.a.sdom1.dom` a DNS client first sends a query to the name server that is responsible for the `.dom` domain. This nameserver returns the nameserver that is responsible for the `sdom1.dom` domain. This nameserver can now be contacted to obtain the nameserver that is responsible for the `a.sdom1.dom` domain. This nameserver can be contacted to retrieve the mapping for the `h3.a.sdom1.dom` name. Thanks to this structure, it is possible for a DNS client to obtain the mapping of any host inside the `.dom` domain or any of its subdomains. To ensure that any DNS client will be able to resolve any fully qualified domain name, there are special nameservers that are responsible for the root of the domain name hierarchy. These nameservers are called :term:`root nameserver`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">114</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b361f465ae3c9fed" weblate-flags="read-only">
        <source>Each root nameserver maintains the list [#froot]_ of all the nameservers that are responsible for each of the top-level domain names and their addresses [#frootv6]_. All root nameservers cooperate and provide the same answers. By querying any of the root nameservers, a DNS client can obtain the nameserver that is responsible for any top-level-domain name. From this nameserver, it is possible to resolve any domain name.</source>
        <target state="translated">Each root nameserver maintains the list [#froot]_ of all the nameservers that are responsible for each of the top-level domain names and their addresses [#frootv6]_. All root nameservers cooperate and provide the same answers. By querying any of the root nameservers, a DNS client can obtain the nameserver that is responsible for any top-level-domain name. From this nameserver, it is possible to resolve any domain name.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">116</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="71fd6bbd1379d4f8" weblate-flags="read-only">
        <source>To be able to contact the root nameservers, each DNS client must know their addresses. This implies, that DNS clients must maintain an up-to-date list of the addresses of the root nameservers. Without this list, it is impossible to contact the root nameservers. Forcing all Internet hosts to maintain the most recent version of this list would be difficult from an operational point of view. To solve this problem, the designers of the DNS introduced a special type of DNS server : the DNS resolvers. A :term:`resolver` is a server that provides the name resolution service for a set of clients. A network usually contains a few resolvers. Each host in these networks is configured to send all its DNS queries via one of its local resolvers. These queries are called `recursive queries` as the :term:`resolver` must recursively send requests through the hierarchy of nameservers to obtain the `answer`.</source>
        <target state="translated">To be able to contact the root nameservers, each DNS client must know their addresses. This implies, that DNS clients must maintain an up-to-date list of the addresses of the root nameservers. Without this list, it is impossible to contact the root nameservers. Forcing all Internet hosts to maintain the most recent version of this list would be difficult from an operational point of view. To solve this problem, the designers of the DNS introduced a special type of DNS server : the DNS resolvers. A :term:`resolver` is a server that provides the name resolution service for a set of clients. A network usually contains a few resolvers. Each host in these networks is configured to send all its DNS queries via one of its local resolvers. These queries are called `recursive queries` as the :term:`resolver` must recursively send requests through the hierarchy of nameservers to obtain the `answer`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">119</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="594a19c5982c8246" weblate-flags="read-only">
        <source>DNS resolvers have several advantages over letting each Internet host query directly nameservers. Firstly, regular Internet hosts do not need to maintain the up-to-date list of the addresses of the root servers. Secondly, regular Internet hosts do not need to send queries to nameservers all over the Internet. Furthermore, as a DNS resolver serves a large number of hosts, it can cache the received answers. This allows the resolver to quickly return answers for popular DNS queries and reduces the load on all DNS servers [JSBM2002]_.</source>
        <target state="translated">DNS resolvers have several advantages over letting each Internet host query directly nameservers. Firstly, regular Internet hosts do not need to maintain the up-to-date list of the addresses of the root servers. Secondly, regular Internet hosts do not need to send queries to nameservers all over the Internet. Furthermore, as a DNS resolver serves a large number of hosts, it can cache the received answers. This allows the resolver to quickly return answers for popular DNS queries and reduces the load on all DNS servers [JSBM2002]_.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">121</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b74f55e998ef7616" weblate-flags="read-only">
        <source>Benefits of names</source>
        <target state="translated">Benefits of names</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">125</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3c74aa8b7d05b0b2" weblate-flags="read-only">
        <source>In addition to being more human friendly, using names instead of addresses inside applications has several important benefits. To understand them, let us consider a popular application that provides information stored on servers. This application involves clients and servers. The server provides information upon requests from client processes. A first deployment of this application would be to rely only on addresses. In this case, the server process would be installed on one host and the clients would connect to this server to retrieve information. Such a deployment has several drawbacks :</source>
        <target state="translated">In addition to being more human friendly, using names instead of addresses inside applications has several important benefits. To understand them, let us consider a popular application that provides information stored on servers. This application involves clients and servers. The server provides information upon requests from client processes. A first deployment of this application would be to rely only on addresses. In this case, the server process would be installed on one host and the clients would connect to this server to retrieve information. Such a deployment has several drawbacks :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">127</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="fb1ae6110d694fc3" weblate-flags="read-only">
        <source>if the server process moves to another physical server, all clients must be informed about the new server address</source>
        <target state="translated">if the server process moves to another physical server, all clients must be informed about the new server address</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">129</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b13d8c25d680c054" weblate-flags="read-only">
        <source>if there are many concurrent clients, the load of the server will increase without any possibility of adding another server without changing the server addresses used by the clients</source>
        <target state="translated">if there are many concurrent clients, the load of the server will increase without any possibility of adding another server without changing the server addresses used by the clients</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">130</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="bedde4f763ab0dca" weblate-flags="read-only">
        <source>Using names solves these problems and provides additional benefits. If the clients are configured with the name of the server, they will query the name service before contacting the server. The name service will resolve the name into the corresponding address. If a server process needs to move from one physical server to another, it suffices to update the name to address mapping on the name service to allow all clients to connect to the new server. The name service also enables the servers to better sustain the load. Assume a very popular server which is accessed by millions of users. This service cannot be provided by a single physical server due to performance limitations. Thanks to the utilization of names, it is possible to scale this service by mapping a given name to a set of addresses. When a client queries the name service for the server's name, the name service returns one of the addresses in the set. Various strategies can be used to select one particular address inside the set of addresses. A first strategy is to select a random address in the set. A second strategy is to maintain information about the load on the servers and return the address of the less loaded server. Note that the list of server addresses does not need to remain fixed. It is possible to add and remove addresses from the list to cope with load fluctuations. Another strategy is to infer the location of the client from the name request and return the address of the closest server.</source>
        <target state="translated">Using names solves these problems and provides additional benefits. If the clients are configured with the name of the server, they will query the name service before contacting the server. The name service will resolve the name into the corresponding address. If a server process needs to move from one physical server to another, it suffices to update the name to address mapping on the name service to allow all clients to connect to the new server. The name service also enables the servers to better sustain the load. Assume a very popular server which is accessed by millions of users. This service cannot be provided by a single physical server due to performance limitations. Thanks to the utilization of names, it is possible to scale this service by mapping a given name to a set of addresses. When a client queries the name service for the server's name, the name service returns one of the addresses in the set. Various strategies can be used to select one particular address inside the set of addresses. A first strategy is to select a random address in the set. A second strategy is to maintain information about the load on the servers and return the address of the less loaded server. Note that the list of server addresses does not need to remain fixed. It is possible to add and remove addresses from the list to cope with load fluctuations. Another strategy is to infer the location of the client from the name request and return the address of the closest server.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">133</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="15cefee2c36b2c33" weblate-flags="read-only">
        <source>Mapping a single name onto a set of addresses allows popular servers to dynamically scale. There are also benefits in mapping multiple names, possibly a large number of them, onto a single address. Consider the case of information servers run by individuals or SMEs. Some of these servers attract only a few clients per day. Using a single physical server for each of these services would be a waste of resources. A better approach is to use a single server for a set of services that are all identified by different names. This enables service providers to support a large number of servers processes, identified by different names, onto a single physical server. If one of these server processes becomes very popular, it will be possible to map its name onto a set of addresses to be able to sustain the load. There are some deployments where this mapping is done dynamically in function of the load.</source>
        <target state="translated">Mapping a single name onto a set of addresses allows popular servers to dynamically scale. There are also benefits in mapping multiple names, possibly a large number of them, onto a single address. Consider the case of information servers run by individuals or SMEs. Some of these servers attract only a few clients per day. Using a single physical server for each of these services would be a waste of resources. A better approach is to use a single server for a set of services that are all identified by different names. This enables service providers to support a large number of servers processes, identified by different names, onto a single physical server. If one of these server processes becomes very popular, it will be possible to map its name onto a set of addresses to be able to sustain the load. There are some deployments where this mapping is done dynamically in function of the load.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">135</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4d2d4d019670172b" weblate-flags="read-only">
        <source>Names provide a lot of flexibility compared to addresses. For the network, they play a similar role as variables in programming languages. No programmer using a high-level programming language would consider using hardcoded values instead of variables. For the same reasons, all networked applications should depend on names and avoid dealing with addresses as much as possible.</source>
        <target state="translated">Names provide a lot of flexibility compared to addresses. For the network, they play a similar role as variables in programming languages. No programmer using a high-level programming language would consider using hardcoded values instead of variables. For the same reasons, all networked applications should depend on names and avoid dealing with addresses as much as possible.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">137</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">../../principles/naming.rst</context>
          <context context-type="linenumber">141</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="864eda330b022b7a" weblate-flags="read-only">
        <source>The :term:`hosts.txt` file is not maintained anymore. A historical snapshot from April 1984 is available from http://ftp.univie.ac.at/netinfo/netinfo/hosts.txt</source>
        <target state="translated">The :term:`hosts.txt` file is not maintained anymore. A historical snapshot from April 1984 is available from http://ftp.univie.ac.at/netinfo/netinfo/hosts.txt</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">142</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="66bae9b11ff83ff0" weblate-flags="read-only">
        <source>See http://www.donelan.com/dnstimeline.html for a time line of DNS related developments.</source>
        <target state="translated">See http://www.donelan.com/dnstimeline.html for a time line of DNS related developments.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">144</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="96494d62470f7fc4" weblate-flags="read-only">
        <source>This specification evolved later to support domain names written by using other character sets than us-ASCII :rfc:`5890`. This extension is important to support languages other than English, but a detailed discussion is outside the scope of this document.</source>
        <target state="translated">This specification evolved later to support domain names written by using other character sets than us-ASCII :rfc:`5890`. This extension is important to support languages other than English, but a detailed discussion is outside the scope of this document.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">146</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4ef1238b633e22c3" weblate-flags="read-only">
        <source>The official list of top-level domain names is maintained by :term:`IANA` at http://data.iana.org/TLD/tlds-alpha-by-domain.txt Additional information about these domains may be found at http://en.wikipedia.org/wiki/List_of_Internet_top-level_domains</source>
        <target state="translated">The official list of top-level domain names is maintained by :term:`IANA` at http://data.iana.org/TLD/tlds-alpha-by-domain.txt Additional information about these domains may be found at http://en.wikipedia.org/wiki/List_of_Internet_top-level_domains</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">148</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4265ba1d7bb7e3e5" weblate-flags="read-only">
        <source>It is interesting to note that to prevent any homograph attack, Google Inc. registered the `g00gle.com` domain name but does not apparently use it.</source>
        <target state="translated">It is interesting to note that to prevent any homograph attack, Google Inc. registered the `g00gle.com` domain name but does not apparently use it.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">150</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="944419b2058c66e6" weblate-flags="read-only">
        <source>A copy of the information maintained by each root nameserver is available at http://www.internic.net/zones/root.zone</source>
        <target state="translated">A copy of the information maintained by each root nameserver is available at http://www.internic.net/zones/root.zone</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">152</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2eeb25c9c2701649" weblate-flags="read-only">
        <source>Until February 2008, the root DNS servers only had IPv4 addresses. IPv6 addresses were slowly added to the root DNS servers to avoid creating problems as discussed in http://www.icann.org/en/committees/security/sac018.pdf As of February 2021, there remain a few DNS root servers that are still not reachable using IPv6. The full list is available at http://www.root-servers.org/</source>
        <target state="translated">Until February 2008, the root DNS servers only had IPv4 addresses. IPv6 addresses were slowly added to the root DNS servers to avoid creating problems as discussed in http://www.icann.org/en/committees/security/sac018.pdf As of February 2021, there remain a few DNS root servers that are still not reachable using IPv6. The full list is available at http://www.root-servers.org/</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/naming.rst</context>
          <context context-type="linenumber">154</context>
        </context-group>
      </trans-unit>
    </body>
  </file>
</xliff>
