# SOME DESCRIPTIVE TITLE. # Copyright (C) 2019 Olivier Bonaventure # This file is distributed under the same license as the Computer networking # : Principles, Protocols and Practice package. # FIRST AUTHOR , 2019. # #, fuzzy msgid "" msgstr "" "Project-Id-Version: Computer networking : Principles, Protocols and " "Practice 3\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2019-10-09 12:39+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=utf-8\n" "Content-Transfer-Encoding: 8bit\n" "Generated-By: Babel 2.7.0\n" #: ../../protocols/dns.rst:7 msgid "The Domain Name System" msgstr "" #: ../../protocols/dns.rst:9 msgid "" "We have already explained the main principles that underlie the " "utilization of names on the Internet and their mapping to addresses." msgstr "" #: ../../protocols/dns.rst:14 msgid "" "The last component of the Domain Name System is the DNS protocol. The 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 focus on the utilization of the DNS " "protocol above the datagram service." msgstr "" #: ../../protocols/dns.rst:18 msgid "" "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 type of message 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." msgstr "" #: ../../protocols/dns.rst:20 msgid "" "The header of DNS messages is composed of 12 bytes and its structure is " "shown in the figure below." msgstr "" #: ../../protocols/dns.rst:26 msgid "The DNS header" msgstr "" #: ../../protocols/dns.rst:28 msgid "" "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." msgstr "" #: ../../protocols/dns.rst:34 msgid "" "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 type " "of query. For instance, a :term:`standard query` is when a client sends a" " `name` and the server returns the corresponding `data`. An update " "request is when the client sends a `name` and new `data` and the server " "then updates its database." msgstr "" #: ../../protocols/dns.rst:36 msgid "" "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`. These extensions " "are discussed in chapter XX." msgstr "" #: ../../protocols/dns.rst:40 msgid "" "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." msgstr "" #: ../../protocols/dns.rst:42 msgid "" "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." msgstr "" #: ../../protocols/dns.rst:48 msgid "DNS Resource Records" msgstr "" #: ../../protocols/dns.rst:50 msgid "" "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." msgstr "" #: ../../protocols/dns.rst:52 msgid "" "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." msgstr "" #: ../../protocols/dns.rst:54 msgid "" "The `RDLength` field is the length of the `RData` field that contains the" " information of the type specified in the `Type` field." msgstr "" #: ../../protocols/dns.rst:56 msgid "" "Several types of DNS RR are used in practice. The `A` type is used to " "encode the IPv4 address that corresponds to the specified name. The " "`AAAA` type is used to encode 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 returns the following " "answer." msgstr "" #: ../../protocols/dns.rst:61 msgid "Query for the `AAAA` record of `www.ietf.org`" msgstr "" #: ../../protocols/dns.rst:63 msgid "" "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." msgstr "" #: ../../protocols/dns.rst:65 msgid "" "`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." msgstr "" #: ../../protocols/dns.rst:67 msgid "Reverse DNS" msgstr "" #: ../../protocols/dns.rst:69 msgid "" "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." msgstr "" #: ../../protocols/dns.rst:72 msgid "" "An important point to note regarding the Domain Name System 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 can 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." msgstr "" #: ../../protocols/dns.rst:80 msgid "Footnotes" msgstr "" #: ../../protocols/dns.rst:81 msgid "" "Some DNS resolvers allow any host to send queries. Google operates a " "`public DNS resolver `_ at addresses `2001:4860:4860::8888` and " "`2001:4860:4860::8844`. Other companies provide similar services." msgstr ""