WEBVTT 00:00.000 --> 00:04.080 Hello! Let's take a look at how the DNS system works. 00:04.080 --> 00:05.760 When you are on the Internet, 00:05.760 --> 00:10.400 you use domain names such as "wikipedia.org" or "radiofrance.fr", 00:10.400 --> 00:13.880 but the server you are contacting is only identified by an IP address. 00:13.880 --> 00:16.440 How do I associate a domain name with an IP address? 00:16.440 --> 00:18.520 The DNS system answers this question. 00:18.520 --> 00:20.520 Before the advent of the DNS system, 00:20.520 --> 00:23.560 domain name resolution was done using the hosts file, 00:23.560 --> 00:27.080 still present today in the operating systems of our devices. 00:27.080 --> 00:29.760 It takes precedence over the DNS system. 00:29.760 --> 00:31.960 Here is the syntax of the hosts file. 00:31.960 --> 00:36.000 We can see that each line associates an IP address with one or more domain names. 00:36.000 --> 00:41.680 This system worked when there were only a small number of devices on the network because updating is fastidious. 00:41.680 --> 00:43.440 When you want to modify the file, 00:43.440 --> 00:48.240 you must ensure that every client on the network has the latest, up-to-date version of the file. 00:48.240 --> 00:53.360 Furthermore, managing this file becomes impossible with several million domains to manage. 00:53.360 --> 01:01.160 The need for a decentralized and hierarchical system led to the creation of the DNS system in 1983. 01:01.160 --> 01:05.239 In a URL, this is where the domain is located. 01:05.239 --> 01:09.240 It is preceded by the protocol, in this case “https”. 01:09.240 --> 01:12.640 The protocol is separated from the domain by “//”. 01:12.640 --> 01:14.800 The domain is followed by the resource. 01:14.800 --> 01:17.000 The resource begins with a “/”. 01:17.000 --> 01:20.120 The resource and protocol are not part of the domain. 01:20.120 --> 01:25.120 Since the DNS system is hierarchical, each level of the domain is separated from the next by a dot. 01:25.120 --> 01:27.880 A domain is divided from right to left. 01:27.880 --> 01:33.360 On the far right is the top-level domain, or TLD. 01:33.360 --> 01:35.040 Then, the second-level domain. 01:35.040 --> 01:36.440 And so on … 01:36.440 --> 01:41.240 For an email address, the domain is located after the “@” sign. 01:41.240 --> 01:46.680 Before the domain name, there is the username and the “@” sign, which means “at.” 01:46.680 --> 01:49.320 The domain is divided up in the same way. 01:49.320 --> 01:54.720 We will see a tree representation of the hierarchy of the different domain levels. 01:54.720 --> 01:58.200 At the very top, we find the root represented by a “.” 01:58.200 --> 02:00.560 There are two sections on our tree: 02:00.560 --> 02:04.720 on the right, the panel that allows you to obtain an IP address from a domain name 02:04.720 --> 02:10.600 and on the left, the panel that allows you to find the associated domain names from an IP address. 02:10.600 --> 02:15.000 The association of the IP address to the domain works in a specific way, 02:15.000 --> 02:17.520 we will look at how it works in detail later on. 02:17.520 --> 02:21.200 The top-level domains are located directly under the root. 02:21.200 --> 02:25.160 They are managed by ICANN and are grouped into two types: 02:25.160 --> 02:29.160 National domains associated with a country or territory 02:29.160 --> 02:30.520 ".fr" for France 02:30.520 --> 02:32.520 ".be" for Belgium, etc. 02:32.960 --> 02:34.160 Generic domains, 02:34.160 --> 02:37.680 ".com" was originally intended for for-profit organizations, 02:37.680 --> 02:40.440 ".museum" pour museums, etc. 02:40.440 --> 02:47.640 Each TLD is managed by a registry, which may be an association, a state, or any other organization 02:47.640 --> 02:51.160 and imposes its own conditions and rates for assigning a domain name. 02:51.160 --> 02:53.640 Then we come to the second level. 02:53.640 --> 02:58.640 In our example, this is where we find the domain "afnic.fr" 02:58.640 --> 03:01.440 Let's continue one level below. 03:01.440 --> 03:06.920 In our example, this is where we find the domain "cloud.example.com" 03:06.920 --> 03:08.480 And so on. 03:08.480 --> 03:18.840 On the sixth level, we find the association between IP 193.52.232.67 and the domain "iutdijon.u-bourgogne.fr". 03:18.840 --> 03:23.160 Here's how recursive resolution works with a DNS server. 03:23.160 --> 03:28.280 In our example, we will assume that neither the client nor the DNS server has a cache. 03:28.280 --> 03:33.040 The client is looking to resolve the domain "mail.example.test". 03:33.040 --> 03:38.040 The client sends its request to the DNS server specified in its network settings. 03:38.040 --> 03:41.320 The DNS service listens on UDP port 53 03:41.320 --> 03:45.360 The recursive DNS server forwards the query to a root server. 03:45.360 --> 03:49.280 Root servers are responsible for top-level domains. 03:49.280 --> 03:55.720 Root servers only know the IP address of the DNS server managing the "test" TLD. 03:55.720 --> 04:02.360 The recursive DNS server then contacts the DNS server managing the test TLD and forwards the request to it. 04:02.360 --> 04:09.000 The server managing the test TLD only knows the DNS server managing the subdomains of "example.test". 04:09.000 --> 04:14.400 The recursive DNS server forwards the query to the DNS server for the domain "example.test". 04:14.400 --> 04:17.680 This server knows the requested domain and sends the response. 04:17.680 --> 04:20.920 The recursive DNS server caches the response. 04:20.920 --> 04:26.080 The recursive DNS server sends the response to the client, which also caches the response. 04:26.080 --> 04:31.720 The root servers are 13 clusters of servers controlled by 12 different authorities. 04:31.720 --> 04:38.240 IP addresses are published and allow DNS servers to resolve top-level domains. 04:38.240 --> 04:42.200 Here are the most common types of DNS records. 04:42.200 --> 04:44.480 We'll go into them in detail in a moment. 04:44.480 --> 04:49.320 All configurations we will look at will be for the domain "example.com". 04:49.320 --> 04:54.320 DNS records can only contain letters, numbers, and hyphens. 04:54.320 --> 05:00.880 Punycode syntax allows Unicode characters to be encoded so that they are compatible with the DNS system. 05:00.880 --> 05:06.720 An A record allows you to associate a domain name with an IPv4 address. 05:06.720 --> 05:09.760 Here's the associated configuration. 05:09.760 --> 05:12.400 Both lines provide the same information. 05:12.400 --> 05:16.080 The first relates to the current configuration domain. 05:16.080 --> 05:21.480 The second refers to the domain in absolute terms, as evidenced by the point at the end of the domain. 05:21.480 --> 05:24.840 This point represents the root of the DNS hierarchy. 05:24.840 --> 05:31.160 Please note that if this point is missing, the system will consider your domain to be relative to the configuration domain. 05:31.160 --> 05:38.960 In our example, if the final dot were missing, the domain would be "cloud.example.com.example.com" 05:38.920 --> 05:43.360 It is possible to associate multiple IP addresses with a domain. 05:43.360 --> 05:47.720 To do this, simply create multiple records for the same domain. 05:47.720 --> 05:54.000 This makes it easy to distribute traffic across multiple IP addresses, particularly in the case of high-demand services. 05:54.000 --> 06:01.720 Since the records are returned randomly, this allows a client to choose randomly from among the different IPs offered. 06:01.720 --> 06:08.000 An AAAA record allows you to associate a domain name with an IPv6 address. 06:08.000 --> 06:13.960 The configuration is similar to record A, where the IPv6 address replaces the IPv4 address. 06:13.960 --> 06:18.960 An NS record designates the DNS servers that manage a domain. 06:18.960 --> 06:23.720 Here is the configuration where two DNS servers are designated for the domain. 06:23.720 --> 06:33.200 Please note that each NS record must be accompanied by an A, AAAA, and/or CNAME record to provide the server's IP address. 06:33.200 --> 06:38.200 An SOA record allows you to enter information about the DNS zone. 06:38.200 --> 06:41.840 This recording must be at the beginning of the configuration. 06:41.840 --> 06:43.760 In order, we find: 06:43.760 --> 06:46.680 The primary DNS server for the domain 06:46.680 --> 06:52.480 A technical contact email address where the “@” is replaced by a “.” 06:52.480 --> 06:56.120 A serial number for the zone configuration. 06:56.120 --> 07:01.960 The refresh time between the primary server and the secondary servers, expressed in seconds. 07:01.960 --> 07:09.920 The wait time, expressed in seconds, after an unsuccessful refresh attempt from the secondary servers to the main server. 07:09.920 --> 07:16.000 The timeout period, expressed in seconds, if the secondary servers cannot reach the primary server. 07:16.000 --> 07:20.480 The TTL of records in DNS caches, expressed in seconds. 07:20.480 --> 07:25.160 A CNAME record allows you to create an alias to another domain. 07:25.160 --> 07:27.800 Aliases can be chained together. 07:27.800 --> 07:34.480 Please note that, in the end, the CNAME must point to a domain with an A and/or AAAA record. 07:34.480 --> 07:39.480 When an SMTP server wants to send a message to your domain, 07:39.480 --> 07:44.160 the MX record allows you to designate the SMTP server(s) for the domain. 07:44.160 --> 07:49.160 Here is the configuration for designating three SMTP servers for our domain. 07:49.160 --> 07:53.600 A small twist here: an additional field is added. 07:53.600 --> 07:56.960 This field allows you to classify your servers by priority. 07:56.960 --> 08:00.640 The lower the number, the higher the server priority. 08:00.640 --> 08:06.000 If the priority field is identical between several servers, load balancing will be applied. 08:06.000 --> 08:14.920 Please note that each MX record must be accompanied by an A, AAAA, and/or CNAME record to provide the server's IP address. 08:14.920 --> 08:19.920 A PTR record allows an IP address to be associated with a domain. 08:19.920 --> 08:23.760 The DNS system is designed to resolve domains. 08:23.760 --> 08:30.480 As the largest part of an IP address is on the left (the first octet of an IPv4 address), 08:30.480 --> 08:32.760 and not on the right for the domain name (TLD), 08:32.760 --> 08:41.320 we are trying to resolve the domain consisting of the reverse IP concatenated with "in-addr.arpa". 08:41.320 --> 08:54.320 Thus, for IPv4 10.104.12.31, the domain 31.12.104.10.in-addr.arpa is resolved. 08:54.320 --> 08:58.760 Here is the configuration for a PTR record with an IPv4 address. 08:58.760 --> 09:03.760 A PTR record also allows an IPv6 address to be associated with a domain. 09:03.760 --> 09:08.440 To convert an IPv6 address into a domain that can be resolved by the DNS system, 09:08.440 --> 09:12.080 we use the uncondensed address format, then 09:12.080 --> 09:17.760 we reverse the order of each byte and concatenate "ip6.arpa" to it. 09:17.760 --> 09:22.440 Here is the configuration for a PTR record with IPv6. 09:22.440 --> 09:26.480 It is possible to query a DNS server manually. 09:26.480 --> 09:32.320 On Linux systems, the "dig" command displays the information returned by the DNS server. 09:32.320 --> 09:38.720 On Windows, the "nslookup" command in the command prompt can be used to perform a DNS query. 09:38.720 --> 09:41.800 The response to the query appears here. 09:41.800 --> 09:48.160 The DNS system is not encrypted. Therefore, in addition to denial-of-service attacks, DNS is vulnerable to 09:48.160 --> 09:50.360 interception… 09:53.920 --> 09:55.720 and modification. 09:55.720 --> 09:59.640 An attacker can read or modify the request or response. 09:59.640 --> 10:03.320 The purpose of this is to obtain information and send back false information. 10:03.320 --> 10:08.720 For example, returning the IP address of a malicious server instead of the legitimate record. 10:08.720 --> 10:13.400 This is particularly problematic when a DNS server receives an incorrect response. 10:13.400 --> 10:17.160 Once its cache is poisoned, it propagates the error to all its clients. 10:17.160 --> 10:19.960 DNSSEC solves these problems: 10:19.960 --> 10:24.960 a cryptographic signature is associated with each record on a server equipped with this protocol. 10:24.960 --> 10:32.680 This allows the client to verify with the server's public key that the returned record is valid and has not been altered. 10:32.680 --> 10:36.320 This protocol also allows signatures to be delegated. 10:36.320 --> 10:42.160 A domain can declare that a subdomain is signed, thereby establishing a chain of trust back to the root. 10:42.160 --> 10:47.160 There you have it, we've seen how DNS works and the main records. 10:47.160 --> 10:49.280 To go further, you can 10:49.280 --> 10:51.520 view the course in text format (french only) and 10:51.520 --> 10:53.840 practice with corrected exercises. 10:53.840 --> 10:56.240 Thank you for your attention, and see you soon.