WEBVTT 00:00.290 --> 00:01.920 Jason: In deze les gaan we het 00:01.920 --> 00:04.920 hebben over het domeinnaamsysteem, of DNS. 00:04.920 --> 00:08.070 Het DNS-protocol wordt gebruikt om uw netwerkclients te helpen een website 00:08.070 --> 00:10.410 te vinden met behulp van menselijk leesbare hostnamen 00:10.410 --> 00:12.720 in plaats van numerieke IP-adressen. 00:12.720 --> 00:15.360 Als ik je bijvoorbeeld zeg dat je mijn website moet bezoeken, kan ik gewoon 00:15.360 --> 00:18.750 zeggen: "Hé, ga naar diontraining. com," en dat is veel gemakkelijker 00:18.750 --> 00:20.910 te onthouden dan te moeten onthouden dat het 00:20.910 --> 00:23.310 66 is. 123. 45. 237, of wat 00:26.280 --> 00:29.670 het IP-adres van mijn webserver ook mag zijn. 00:29.670 --> 00:32.010 Het zeggen van al die nummers als onderdeel van een tv-commercial 00:32.010 --> 00:34.590 is immers niet zo pakkend of memorabel als vertellen dat je consument 00:34.590 --> 00:39.420 diontraining moet bezoeken. 00:39.420 --> 00:39.420 com, of coca-cola. com 00:39.420 --> 00:41.760 of microsoft. com, toch? 00:41.760 --> 00:43.680 Dus hoe weet de computer hoe hij het IP-adres 00:43.680 --> 00:45.240 van de webserver moet vinden aan de hand 00:45.240 --> 00:47.220 van deze verschillende domeinnamen? 00:47.220 --> 00:51.720 Dat is het doel van DNS, het domeinnaamsysteem. 00:51.720 --> 00:54.990 De manier waarop DNS werkt is dat de computer van de gebruiker de opdracht krijgt om naar 00:54.990 --> 00:57.660 een plek als diontraining te gaan. com, dus het bereikt 00:57.660 --> 00:59.797 een DNS-server en zegt, "Hé, wie is 00:59.797 --> 01:02.139 diontraining. com? En de DNS-server antwoordt 01:02.139 --> 01:07.140 dan terug en zegt: "Oh, ik ken diontraining. 01:07.140 --> 01:07.140 com. 01:07.140 --> 01:09.900 Het IP-adres is 66 punt iets, punt 01:09.900 --> 01:11.610 iets, punt iets. Vervolgens wordt de client omgeleid 01:11.610 --> 01:14.490 naar een webserver met behulp van hun router en hun weg 01:14.490 --> 01:17.370 naar de verbinding, omdat ze nu het juiste IP-adres weten 01:17.370 --> 01:19.170 om te gebruiken als hun bestemming, 01:19.170 --> 01:21.930 en dit gebeurt allemaal op de achtergrond voor jouw 01:21.930 --> 01:24.360 gebruikers en jouw computer zonder dat iemand 01:24.360 --> 01:26.730 er echt om hoeft te vragen, omdat DNS zo'n ingebed 01:26.730 --> 01:30.660 onderdeel is van onze netwerken en systemen. 01:30.660 --> 01:33.360 Nu zullen de meesten van ons als thuisgebruikers geen 01:33.360 --> 01:35.550 eigen DNS-servers draaien, maar vertrouwen 01:35.550 --> 01:38.820 we op onze internetproviders om dit voor ons te doen. 01:38.820 --> 01:40.770 Maar als je je eigen websites of ons grote 01:40.770 --> 01:43.110 bedrijfsnetwerk beheert, heb je misschien ook 01:43.110 --> 01:45.690 je eigen DNS-server in je netwerk en ben je verantwoordelijk 01:45.690 --> 01:47.160 voor het instellen van je eigen 01:47.160 --> 01:49.050 DNS-records die bepalen welke servers 01:49.050 --> 01:53.303 zich op welke IP-adressen bevinden en voor welke doeleinden. 01:53.303 --> 01:55.620 Hiermee kun je je eigen domeinnaam- en 01:55.620 --> 01:58.620 hostresolutie uitvoeren, die deze domeinnamen omzet 01:58.620 --> 02:00.120 naar IP-adressen. 02:00.120 --> 02:01.380 Als je het zo wilt zien, is het 02:01.380 --> 02:04.440 vergelijkbaar met een lijst met contactpersonen op je telefoon. 02:04.440 --> 02:07.380 Hoeveel telefoonnummers ken jij tegenwoordig uit je hoofd? 02:07.380 --> 02:09.120 Waarschijnlijk niet veel, toch? 02:09.120 --> 02:11.490 Want normaal gesproken haal je je smartphone tevoorschijn, 02:11.490 --> 02:13.800 scrol je naar de naam van de persoon en druk je met je vinger 02:13.800 --> 02:16.350 op zijn naam, waarna de telefoon hem belt. 02:16.350 --> 02:19.500 Als ik bijvoorbeeld mijn vrouw wil bellen, scroll ik naar haar naam, 02:19.500 --> 02:21.480 druk ik een foto van haar gezicht op mijn telefoon 02:21.480 --> 02:24.600 en belt mijn telefoon onmiddellijk haar nummer. 02:24.600 --> 02:27.390 Ik hoef niet alle 10 cijfers van haar telefoonnummer te onthouden, 02:27.390 --> 02:29.400 want dat doet mijn telefoon voor me. 02:29.400 --> 02:31.020 Dat komt omdat we het als mensen moeilijker 02:31.020 --> 02:34.200 hebben om nummers te onthouden dan namen, en dus doen we deze gezichts- 02:34.200 --> 02:39.000 of naam-naar-nummer conversie met behulp van onze contactpersonenlijst. 02:39.000 --> 02:40.800 Het is hetzelfde voor computers, behalve 02:40.800 --> 02:42.808 dat computers eigenlijk veel meer van getallen 02:42.808 --> 02:45.840 houden dan van namen, dus we willen de domeinnamen die makkelijker 02:45.840 --> 02:49.410 voor ons zijn omzetten in IP-adressen die makkelijker zijn voor computers 02:49.410 --> 02:52.260 om hun routering mee te doen, en dat is eigenlijk alles wat 02:52.260 --> 02:54.330 DNS voor ons doet. 02:54.330 --> 02:57.510 Het converteert namen naar nummers en nummers naar namen. 02:57.510 --> 02:59.280 Een van de concepten van DNS waar 02:59.280 --> 03:00.810 we het over moeten hebben is 03:00.810 --> 03:04.590 de zogenaamde volledig gekwalificeerde domeinnaam, of FQDN. 03:04.590 --> 03:08.040 Dit is wanneer een domeinnaam onder een toplevelprovider valt. 03:08.040 --> 03:11.670 De meest voorkomende top level provider is bijvoorbeeld . com, maar we hebben ook dingen 03:11.670 --> 03:16.200 zoals . molen, . edu, . org, . net. 03:16.200 --> 03:18.360 Laten we het voorbeeld van Dion Training gebruiken. 03:18.360 --> 03:21.210 Bij Dion Training hebben we veel verschillende servers. 03:21.210 --> 03:23.220 Een van onze servers is onze webserver 03:23.220 --> 03:27.750 en deze bevindt zich op www. diontraining. com. 03:27.750 --> 03:30.660 Het topleveldomein is hier . com. 03:30.660 --> 03:33.420 De domeinnaam die ik gebruik is Dion Training. 03:33.420 --> 03:37.650 Om volledig gekwalificeerd te zijn, moet ik er WWW voor zetten. 03:37.650 --> 03:41.910 Dit maakt het www. diontraining. com. 03:41.910 --> 03:43.770 Als je naar mijn webserver 03:43.770 --> 03:45.840 wilt gaan, typ je www. in je 03:45.840 --> 03:49.890 browser. diontraining. com, en nu word je doorgestuurd 03:49.890 --> 03:53.160 naar mijn webserver, omdat DNS weet hoe het IP-adres van mijn 03:53.160 --> 03:55.350 webserver moet draaien met die volledig 03:55.350 --> 03:57.900 gekwalificeerde domeinnaam. 03:57.900 --> 04:00.300 Als je in plaats daarvan naar mijn bestandsserver wilt gaan, 04:00.300 --> 04:03.660 moet je ftp intypen. diontraining. com, omdat dat de 04:03.660 --> 04:05.820 server is die ik daar draai. 04:05.820 --> 04:07.290 Als je naar mijn mailserver wilt 04:07.290 --> 04:10.140 gaan, typ je mail. diontraining. com. 04:10.140 --> 04:11.610 Dit zijn alle drie voorbeelden 04:11.610 --> 04:14.910 van volledig gekwalificeerde domeinnamen of FQDN's. 04:14.910 --> 04:17.790 In wezen is er een service, een punt, een domeinnaam, 04:17.790 --> 04:21.240 een punt en een topleveldomein en dit werkt op dezelfde 04:21.240 --> 04:22.830 manier, ongeacht naar welk 04:22.830 --> 04:25.680 domein je op internet kijkt. 04:25.680 --> 04:28.830 DNS wordt nu ingesteld als een hiërarchie. 04:28.830 --> 04:31.050 Dit gebeurt op vijf verschillende niveaus. 04:31.050 --> 04:33.750 We hebben het routeniveau, het topleveldomein, 04:33.750 --> 04:37.260 de domeinen op het tweede niveau, subdomeinen en de host. 04:37.260 --> 04:39.060 Het routeniveau is het hoogste niveau 04:39.060 --> 04:40.800 in de DNS-hiërarchieboom en de routenameserver 04:40.800 --> 04:44.550 gaat verzoeken in de routezone beantwoorden. 04:44.550 --> 04:46.320 Deze servers bevatten de globale lijst 04:46.320 --> 04:49.867 van alle topleveldomeinen, zoals. com,. net, . org, . molen en anderen. 04:49.867 --> 04:53.190 Het tweede niveau naar beneden zijn de topleveldomeinen. 04:53.190 --> 04:56.700 Deze zijn onderverdeeld in twee categorieën, organisatorische 04:56.700 --> 04:59.100 hiërarchieën zoals . com, . net, . org, en anderen, en dan de 04:59.100 --> 05:03.300 geografische 05:03.300 --> 05:06.000 hiërarchie zoals . uk voor het Verenigd Koninkrijk, . fr voor Frankrijk,. voor Italië en andere landen. 05:06.000 --> 05:10.447 Het derde niveau lager staat bekend als second level domains. 05:10.447 --> 05:13.620 Deze domeinen staan direct onder het topleveldomein. 05:13.620 --> 05:16.710 Mijn domein Dion Training is bijvoorbeeld 05:16.710 --> 05:20.160 een domein op het tweede niveau onder de . com topleveldomein. 05:20.160 --> 05:23.130 De . com zit onder het routedomein. 05:23.130 --> 05:27.510 Dit is de manier waarop deze dingen samen opklimmen 05:27.510 --> 05:30.900 als onderdeel van de hiërarchie. 05:30.900 --> 05:33.270 Het vierde niveau naar beneden staat bekend als het subdomein, 05:33.270 --> 05:34.950 dus als ik een nieuwe server zou willen maken 05:34.950 --> 05:37.830 onder mijn domein van het tweede niveau, diontraining. com, kan ik dat doen met een 05:37.830 --> 05:39.720 subdomein. 05:39.720 --> 05:43.170 In mijn geval heb ik veel verschillende 05:43.170 --> 05:45.330 subdomeinen voor verschillende doeleinden. 05:45.330 --> 05:47.580 Ik heb mijn hoofdwebsite gehost op het www-subdomein, 05:47.580 --> 05:48.870 dus je typt www in. diontraining. com, en dat brengt 05:48.870 --> 05:52.590 je naar mijn webserver, maar ik heb er ook een die support 05:52.590 --> 05:56.070 heet. 05:56.070 --> 05:57.840 Nu bevindt het support-subdomein 05:57.840 --> 05:59.910 zich op support. diontraining. com. 05:59.910 --> 06:01.740 Ik heb er nog een voor mail, mail. diontraining. com. 06:01.740 --> 06:04.320 Dit zijn allemaal verschillende subdomeinen. 06:04.320 --> 06:07.620 Het vijfde en laatste niveau naar beneden is het hostniveau. 06:07.620 --> 06:09.660 Dit is het laagste en meest gedetailleerde 06:09.660 --> 06:12.750 niveau binnen de DNS-hiërarchie en verwijst naar een specifieke 06:12.750 --> 06:14.760 machine of server op het netwerk. 06:14.760 --> 06:17.070 Als we echter aan DNS denken, denken 06:17.070 --> 06:19.887 de meesten van ons aan zoiets als een volledig 06:19.887 --> 06:21.870 gekwalificeerde domeinnaam, 06:21.870 --> 06:23.640 iets als www. diontraining. com, dat een subdomein, een domein op 06:23.640 --> 06:25.620 het tweede niveau en een domein op het hoogste 06:25.620 --> 06:28.710 niveau bevat. 06:28.710 --> 06:31.170 Als ik nog een stapje verder wil gaan, kan ik het bekijken vanuit 06:31.170 --> 06:32.940 het perspectief van een URL, die bekend staat 06:32.940 --> 06:34.920 als een uniform resource locator. 06:34.920 --> 06:37.170 Nogmaals, laten we mijn webserver 06:37.170 --> 06:40.110 als voorbeeld nemen, www. diontraining. com. 06:40.110 --> 06:41.700 Dat is mijn volledig gekwalificeerde domeinnaam, maar het 06:41.700 --> 06:45.540 vertelt je niet hoe je er toegang toe krijgt. 06:45.540 --> 06:47.700 Wil je dit veilig of onveilig doen? 06:47.700 --> 06:50.460 Nou, dat zul je moeten zien door de URL te doen. 06:50.460 --> 06:53.100 Als je me je gebruikersnaam en wachtwoord 06:53.100 --> 06:56.610 wilt geven, moet je dit veilig doen. 06:56.610 --> 06:58.950 Dus je voegt HTTPS:// 06:58.950 --> 07:00.720 toe voor www. diontraining. com, en dat wordt een URL, een 07:00.720 --> 07:05.190 uniform resource locator, omdat het je vertelt hoe je toegang krijgt 07:05.190 --> 07:09.660 tot diontraining. com's webserver. 07:09.660 --> 07:12.450 Daarom hebben we die HTTPS aan het begin. 07:12.450 --> 07:16.200 Het is het hyper text transfer protocol 07:16.200 --> 07:19.170 secure, en dat is de methode om er toegang toe te krijgen. 07:19.170 --> 07:22.020 Als je nu mijn website wilt bezoeken en dat op een onveilige manier 07:22.020 --> 07:24.180 wilt doen, kun je dat doen door HTTP:// toe te voegen 07:24.180 --> 07:25.650 aan het begin van het webadres. 07:25.650 --> 07:28.110 Als je nu verbinding wilt 07:28.110 --> 07:32.430 maken via FTP, gebruik je FTP://FTP. diontraining. com als je URL, en zo zijn er veel verschillende manieren om dit te doen als 07:32.430 --> 07:34.320 je het systeem vertelt wat het moet 07:34.320 --> 07:39.320 doen, en dat zal een URL en een 07:40.230 --> 07:42.000 volledig gekwalificeerde domeinnaam 07:42.000 --> 07:43.860 creëren. 07:43.860 --> 07:45.450 Vervolgens moeten we het hebben over de verschillende 07:45.450 --> 07:47.670 soorten DNS-records die bestaan binnen een DNS-server. 07:47.670 --> 07:49.470 Binnen je DNS-server ga je verschillende 07:49.470 --> 07:53.100 records aanmaken die verschillende soorten informatie bevatten op 07:53.100 --> 07:55.200 basis van je gebruikssituatie. 07:55.200 --> 07:58.170 Deze staan bekend als A-records, AAAA-records, CNAME-records, MX-records, 07:58.170 --> 07:59.760 TXT-records en NS-records. 07:59.760 --> 08:04.470 Laten we eens kort kijken naar elk van deze 08:04.470 --> 08:08.520 verschillende recordtypes. 08:08.520 --> 08:09.600 Ten eerste hebben we een 08:09.600 --> 08:11.610 A-record, wat staat voor een adresrecord. 08:11.610 --> 08:13.170 Een A-record wordt gebruikt om een 08:13.170 --> 08:15.210 hostnaam aan een IPv4-adres te koppelen. 08:15.210 --> 08:17.370 Er is bijvoorbeeld een A-record voor www. diontraining. com en koppelt dit aan het 08:17.370 --> 08:19.350 IP-adres van 45. 79. 184. 180. 08:19.350 --> 08:24.000 Daarnaast kun je ook een A-record instellen voor de 08:24.000 --> 08:27.450 @ host, en dit geeft een record 08:30.720 --> 08:31.650 voor het routedomein aan. 08:31.650 --> 08:34.350 In het voorbeeld van Dion Training betekent 08:34.350 --> 08:36.930 ons @ record dat diontraining. com, de route van ons domein, wordt 08:36.930 --> 08:38.400 weergegeven op een bepaald 08:38.400 --> 08:41.430 IP-adres. 08:41.430 --> 08:43.980 Op deze manier kunnen onze gebruikers onze website vinden 08:43.980 --> 08:45.510 door naar het subdomein www. diontraining. com, of gewoon door 08:45.510 --> 08:51.180 naar diontraining te gaan. com door dat A @ record te gebruiken. 08:51.180 --> 08:54.060 Nu werken A-records alleen voor IPv4-adressen, 08:54.060 --> 08:56.820 maar veel moderne websites ondersteunen ook IPv6. 08:56.820 --> 09:00.210 Om een domeinnaam aan een IPv6-adres 09:00.210 --> 09:04.410 te koppelen, gebruik je een AAAA-record. 09:04.410 --> 09:06.804 Dus met de site van Dion Training als voorbeeld, 09:06.804 --> 09:09.870 zou ik het AAAA record kunnen instellen op 2400:cb00:2049:1::a29f:1804 09:09.870 --> 09:12.930 als dat het IPv6 adres voor mijn webserver was. 09:12.930 --> 09:17.930 Zoals je kunt zien, zijn IPv6-adressen veel ingewikkelder 09:26.400 --> 09:29.730 dan IPv4 en heel moeilijk te onthouden voor 09:29.730 --> 09:30.563 ons mensen. 09:30.563 --> 09:34.110 Daarom gebruiken we graag deze AAAA-records 09:34.110 --> 09:36.300 of 4A-records. 09:36.300 --> 09:39.630 Het volgende type record dat we kunnen gebruiken staat bekend als een CNAME-record, 09:39.630 --> 09:41.580 oftewel een canoniek naamrecord. 09:41.580 --> 09:43.650 Nu wordt een CNAME-record gebruikt in plaats 09:43.650 --> 09:46.620 van een A-record voor een AAAA-record als je een domein naar een andere 09:46.620 --> 09:49.200 domeinnaam of een subdomeinnaam wilt verwijzen. 09:49.200 --> 09:52.230 Ik bezit bijvoorbeeld veel verschillende 09:52.230 --> 09:55.050 domeinnamen naast diontraining. com. 09:55.050 --> 09:58.020 Sommige hiervan zijn voor voormalige bedrijven die ik had of projecten 09:58.020 --> 10:00.120 die ik runde, en andere 10:00.120 --> 10:02.220 ben ik van plan ooit in de toekomst te gebruiken, 10:02.220 --> 10:05.220 maar in de tussentijd heb ik ze ingesteld met een CNAME-record 10:05.220 --> 10:07.890 dat terugverwijst naar diontraining. com. 10:07.890 --> 10:09.780 Ik had bijvoorbeeld een website genaamd itil4exam. com, maar sindsdien gebruik ik 10:09.780 --> 10:12.300 die domeinnaam niet meer 10:12.300 --> 10:15.960 en heb ik al die cursussen samengevoegd 10:15.960 --> 10:18.570 in mijn eigen diontraining. com website. 10:18.570 --> 10:20.430 Dus toen ik die oude webserver uitschakelde, wilde ik mensen nog 10:20.430 --> 10:23.160 steeds toestaan om itil4exam in te typen. com en iets bereiken in 10:23.160 --> 10:25.380 plaats van alleen een foutpagina. 10:25.380 --> 10:28.770 Dus heb ik een CNAME record gebruikt 10:28.770 --> 10:31.650 om het direct naar diontraining te laten verwijzen. com. 10:31.650 --> 10:33.510 Waarom zou ik dat willen doen? 10:33.510 --> 10:36.180 Nou, we waren een paar jaar op de andere 10:36.180 --> 10:37.542 site, parallel aan diontraining. com, en veel van de links die 10:37.542 --> 10:40.200 daar staan, staan overal op het internet met aanbevelingen 10:40.200 --> 10:42.390 voor onze cursussen die 10:42.390 --> 10:45.060 op dat itil4examen werden gehost. com website. 10:45.060 --> 10:47.400 Een van onze populairste cursussen van die site 10:47.400 --> 10:50.100 was onze ITIL 4 Foundation-cursus, 10:50.100 --> 10:52.260 die te vinden was op itil4exam. com/itil-4-stichting. 10:52.260 --> 10:54.000 Als je dat in je webbrowser typt, 10:54.000 --> 10:59.000 wordt het itil4examen opgelost. com naar diontraining. com en brengt je rechtstreeks 10:59.430 --> 11:01.680 naar diontraining. com/itil-4-stichting. 11:01.680 --> 11:06.000 Dit betekent dat zelfs als je een 11:06.000 --> 11:11.000 link gebruikt die je hebt gevonden op Reddit en die onze cursus 11:11.550 --> 11:13.500 van een paar jaar geleden aanbeveelt, deze nog 11:13.500 --> 11:15.510 steeds werkt en je naar onze verkooppagina brengt, 11:15.510 --> 11:17.790 ook al is het originele itil4exam. com server is zelfs niet meer in 11:17.790 --> 11:20.070 gebruik en is offline gehaald. 11:20.070 --> 11:23.370 Een andere toepassing voor het gebruik 11:23.370 --> 11:25.950 van een CNAME-record is wanneer je een software-as-a-service 11:25.950 --> 11:28.380 gebruikt die je een subdomein op hun server geeft. 11:28.380 --> 11:30.630 Ik gebruik bijvoorbeeld een service desk 11:30.630 --> 11:33.240 ticket tracking software die Freshdesk heet. com, en ze gaven ons een nogal 11:33.240 --> 11:36.360 moeilijk te onthouden subdomein voor 11:36.360 --> 11:39.780 hun service, zoiets 11:39.780 --> 11:42.060 als FDUS-143-D15. freshdesk. com. 11:42.060 --> 11:42.960 Dus om het voor mijn medewerkers 11:42.960 --> 11:47.160 makkelijker te maken om onze supportdesk te vinden, 11:49.050 --> 11:52.170 maken we een CNAME-record aan met de naam Support en verwijzen dat naar dit moeilijk te onthouden subdomein. 11:52.170 --> 11:54.840 Dus als mijn personeel ondersteuning invoert. diontraining. com, brengt ze rechtstreeks naar ons ondersteuningssysteem, 11:54.840 --> 11:57.780 dat ons eigenlijk doorverwijst naar deze cloud-instantie die wordt 11:57.780 --> 12:01.230 geleverd door het subdomein 12:01.230 --> 12:03.330 dat door Freshdesk is uitgegeven. 12:03.330 --> 12:06.180 Onthoud dat CNAME-records niet kunnen worden 12:06.180 --> 12:09.480 gebruikt om naar een IP-adres te verwijzen. 12:09.480 --> 12:12.180 Het kan alleen worden gebruikt om naar een andere domeinnaam 12:12.180 --> 12:13.710 of subdomeinnaam te verwijzen. 12:13.710 --> 12:15.030 Vervolgens hebben we een 12:15.030 --> 12:17.940 MX-record, wat staat voor mail exchange record, en het 12:17.940 --> 12:19.890 doet wat je denkt dat het zou doen. 12:19.890 --> 12:21.930 Het helpt je uit te zoeken waar een e-mailserver zich bevindt. 12:21.930 --> 12:23.670 Een MX-record wordt gebruikt om e-mails naar uw mailserver te leiden. 12:23.670 --> 12:26.370 MX-records kunnen net als CNAME-records alleen worden 12:26.370 --> 12:30.360 gebruikt om naar een ander domein te verwijzen en niet naar een IP-adres. 12:30.360 --> 12:33.750 Wanneer je je MX-records aanmaakt, kun je 12:33.750 --> 12:36.780 ook de prioriteit voor elk van deze records 12:36.780 --> 12:38.340 opgeven. 12:38.340 --> 12:39.863 Hiermee kun je je voorkeur aangeven voor 12:39.863 --> 12:42.030 welke server de e-mail eerst moet proberen te gebruiken. 12:42.030 --> 12:43.770 Bij het instellen van de prioriteit 12:43.770 --> 12:47.220 geldt: hoe lager het getal dat je invoert, hoe hoger de 12:47.220 --> 12:48.900 prioriteit. 12:48.900 --> 12:50.490 Het zijn in wezen golfregels. 12:50.490 --> 12:52.140 Dus als we mail1. diontraininf. com ingesteld 12:52.140 --> 12:54.270 op 10 en mail2. diontraining. com ingesteld op 20 voor hun prioriteiten, proberen de e-mails 12:54.270 --> 12:57.720 eerst mail één te gebruiken. 12:57.720 --> 13:01.140 Als het niet lukt om mail 13:01.140 --> 13:04.200 één te bereiken, dan zal het proberen mail twee te bereiken. 13:04.200 --> 13:05.700 Als je nu je e-mail wilt verdelen over 13:05.700 --> 13:07.860 meerdere servers, hoef je alleen maar hun prioriteiten 13:07.860 --> 13:09.960 op dezelfde waarde in te stellen. 13:09.960 --> 13:11.640 Dus als ik records heb aangemaakt voor 13:11.640 --> 13:14.760 mail één en mail twee, en ze hebben allebei prioriteit 10, dan zullen 13:14.760 --> 13:17.730 alle inkomende e-mails elkaar afwisselen en gelijkmatig worden 13:17.730 --> 13:19.770 verdeeld over deze servers. 13:19.770 --> 13:21.990 De eerste gaat naar één, de tweede gaat 13:21.990 --> 13:24.240 naar twee, de derde gaat naar één, de 13:24.240 --> 13:26.820 vierde gaat naar twee, enzovoort. 13:26.820 --> 13:28.050 Vervolgens hebben we TXT-records, of tekstrecords. 13:28.050 --> 13:30.600 Nu wordt een tekstrecord gebruikt door domeinbeheerders 13:30.600 --> 13:33.720 om tekst toe te voegen aan het domeinnaamsysteem, of DNS. 13:33.720 --> 13:36.120 Oorspronkelijk werden tekstrecords ontworpen 13:36.120 --> 13:39.810 als een manier voor ons om menselijk leesbare notities toe te voegen 13:39.810 --> 13:42.420 aan onze DNS-records, en na verloop van tijd werden 13:42.420 --> 13:45.450 er steeds meer dingen toegevoegd aan deze tekstrecords, 13:45.450 --> 13:48.000 en uiteindelijk begonnen we ook machineleesbare 13:48.000 --> 13:50.850 gegevens toe te voegen aan deze tekstrecords, en dat 13:50.850 --> 13:53.970 is wat je tegenwoordig meestal zult zien. 13:53.970 --> 13:55.770 Je domein kan ook veel verschillende 13:55.770 --> 13:57.990 tekstrecords hebben. 13:57.990 --> 13:59.160 Je bent niet beperkt tot slechts één van hen. 13:59.160 --> 14:00.720 Meestal worden tekstrecords gebruikt 14:00.720 --> 14:02.640 om domeineigendom aan te tonen door machine-leesbare 14:02.640 --> 14:05.100 code toe te voegen ter verificatie en om e-mailspam te voorkomen, 14:05.100 --> 14:06.990 ook weer door specifieke machine-leesbare code 14:06.990 --> 14:09.420 toe te voegen aan een TXT-record. 14:09.420 --> 14:12.540 Bijvoorbeeld bij diontraining. com hebben we een tekstrecord 14:12.540 --> 14:15.990 met de naam fdkey. ondersteuning en een structuur van 32 hexadecimale 14:15.990 --> 14:18.330 cijfers in onze 14:18.330 --> 14:21.820 DNS-records. 14:21.820 --> 14:24.870 Hierdoor kan ons supportsysteem Freshdesk verifiëren dat wij de eigenaar 14:24.870 --> 14:26.970 zijn van de domeinnaam diontraining. com, dus zij zijn gemachtigd om namens 14:26.970 --> 14:30.000 ons e-mails te versturen naar onze studenten wanneer 14:30.000 --> 14:32.670 ons team in hun systeem antwoordt 14:32.670 --> 14:34.712 op een supportticket. 14:34.712 --> 14:37.140 Dit is een vorm van verificatie van domeineigendom, 14:37.140 --> 14:39.870 omdat hun systeem onze DNS-records kan opvragen en kan 14:39.870 --> 14:42.660 zien dat we deze unieke reeks van 32 hexadecimale cijfers 14:42.660 --> 14:45.240 hebben ingevoerd in ons DNS TXT-record. 14:45.240 --> 14:47.130 In wezen werkt het als een wachtwoord 14:47.130 --> 14:51.360 om te zeggen: "Hé, ik ben de eigenaar van dit domein. In je TXT-records kun je ook informatie opnemen zoals SPF-, DKIM- of 14:51.360 --> 14:53.407 DMARC-berichten om je e-mailservices 14:53.407 --> 14:55.348 te helpen verifiëren en de verzending 14:55.348 --> 14:57.932 van gespoofde of ongewenste berichten, bekend 14:57.932 --> 15:04.950 als spam, naar andere mensen die je domein en e-mailadressen gebruiken, te blokkeren. 15:04.950 --> 15:06.535 SPF, of het sender policy 15:06.535 --> 15:10.068 framework, is een DNS record dat de host identificeert 15:10.068 --> 15:13.170 die geautoriseerd is om mail te versturen voor 15:13.170 --> 15:15.300 het domein, en er is er maar één 15:15.300 --> 15:18.300 toegestaan voor elk domein. 15:18.300 --> 15:19.920 Als je ze bekijkt, zul je iets hebben dat er 15:19.920 --> 15:21.780 zo uitziet, en dit is een DNS-record dat een tekstrecord 15:21.780 --> 15:22.800 wordt genoemd. 15:22.800 --> 15:24.480 Je zult zien dat het het @ teken heeft 15:24.480 --> 15:27.240 en dan V=SPF1, wat sender policy framework one is. 15:27.240 --> 15:31.350 Het is de eerste. 15:31.350 --> 15:33.600 Dan staat er MX, wat het mailserverrecord is, en 15:33.600 --> 15:37.830 dan staat er include:_SPF. google. com, en vermeld:e-mail. 15:37.830 --> 15:37.830 freshdesk. com-all. 15:37.830 --> 15:41.520 Wat vertelt dit jou? 15:41.520 --> 15:46.200 Nou, dit is eigenlijk het SPF-record voor mijn e-mailserver. 15:46.200 --> 15:47.700 Waarom hebben we google? com daar? 15:47.700 --> 15:51.390 Nou, dat komt omdat we G Suite van Google gebruiken en Google dus onze 15:51.390 --> 15:53.640 e-mailprovider is. 15:53.640 --> 15:55.620 We hebben geen eigen e-mailserver. 15:55.620 --> 15:57.600 In plaats daarvan laten we ze dat doen en hebben we ze toestemming 15:57.600 --> 15:58.920 gegeven om dat te doen, dat ze gemachtigd 15:58.920 --> 16:00.330 zijn om namens ons e-mail te versturen door 16:00.330 --> 16:02.100 die SPF-verklaring op te nemen. 16:02.100 --> 16:04.052 De tweede daar vraag je je misschien 16:04.052 --> 16:06.510 af: "Waar is dat voor? 16:06.510 --> 16:07.343 Ik dacht dat je er maar één kon hebben. Nou, je kunt maar één 16:07.343 --> 16:08.970 SPF-verklaring hebben, maar dit hele 16:08.970 --> 16:10.440 ding is één regel als het in DNS wordt 16:10.440 --> 16:12.960 geschreven, en dit hele ding van tekst helemaal naar alles 16:12.960 --> 16:16.560 is één enkele regel, en dat is één enkele SPF-verklaring. 16:16.560 --> 16:19.230 Ik kan meerdere servers machtigen om namens mij te verzenden, 16:19.230 --> 16:22.050 maar ik kan het alleen doen in één DNS-regel zoals je hier ziet, 16:22.050 --> 16:24.930 en wat Freshdesk is, is ons trouble ticket-systeem. 16:24.930 --> 16:28.710 Als u een e-mail stuurt naar de supportafdeling van Dion Training, 16:28.710 --> 16:31.170 gaat deze naar Freshdesk, maar als u een e-mail 16:31.170 --> 16:33.060 stuurt naar mijn persoonlijke e-mail 16:33.060 --> 16:34.770 bij Dion Training, gaat deze naar 16:34.770 --> 16:37.980 Google, omdat dat onze persoonlijke e-mails voor ons bedrijf 16:37.980 --> 16:39.300 zijn, en dus moet u beide 16:39.300 --> 16:42.540 e-mailadressen opnemen in alles wat namens u wordt verzonden 16:42.540 --> 16:44.940 in deze verklaring. 16:44.940 --> 16:46.592 Het volgende waar we het over moeten hebben is DKIM, of dkim. 16:46.592 --> 16:48.660 Dit is domein sleutels geïdentificeerde mail. 16:48.660 --> 16:52.500 Dit biedt een cryptografisch authenticatiemechanisme voor mail met behulp van een openbare 16:52.500 --> 16:55.020 sleutel die wordt gepubliceerd als een DNS-record. 16:55.020 --> 16:57.660 Als je nu een SPF of DKIM opzoekt, 16:57.660 --> 17:01.252 zie je zoiets als dit. 17:01.252 --> 17:03.960 Hier is een voorbeeld van de mail voor adobe. com. 17:03.960 --> 17:05.339 Je ziet DMARC bovenaan, waar 17:05.339 --> 17:08.910 we het zo over zullen hebben, je ziet 17:08.910 --> 17:10.290 SPF, waar we het net over hebben 17:10.290 --> 17:11.520 gehad, en dan zie je DKIM, 17:11.520 --> 17:13.800 waar we het nu over hebben. 17:13.800 --> 17:14.700 Het is eigenlijk een hele lange cryptografische 17:14.700 --> 17:16.200 authenticatiesleutel, die je op het scherm kunt zien. 17:16.200 --> 17:19.440 DKIM kan nu SPF vervangen of samen met SPF worden gebruikt. 17:19.440 --> 17:21.510 De volgende waar we het over gaan 17:21.510 --> 17:25.740 hebben is DMARC, en DMARC is de domain-based message authentication 17:25.740 --> 17:28.410 reporting and conformance. 17:28.410 --> 17:31.230 Dit is in feite een raamwerk, en dit raamwerk wordt gebruikt 17:31.230 --> 17:32.430 om de juiste toepassing van 17:32.430 --> 17:33.870 SPF en DKIM te garanderen met behulp 17:33.870 --> 17:36.510 van een beleid dat wordt gepubliceerd als een DNS-record, 17:36.510 --> 17:39.240 en ik heb je dat heel kort laten zien in de laatste afbeelding 17:39.240 --> 17:41.370 op je scherm toen ik je de DMARC liet zien op de bovenste 17:41.370 --> 17:43.860 regel van die afbeelding. 17:43.860 --> 17:45.630 Als je terug wilt gaan en daarnaar wilt 17:45.630 --> 17:47.190 kijken, dan kan dat op dit moment. 17:47.190 --> 17:48.690 Als je te maken hebt met DMARC, 17:48.690 --> 17:50.340 kun je dit gebruiken met SPF, 17:50.340 --> 17:51.720 met DKIM of met beide, want 17:51.720 --> 17:55.890 vergeet niet dat SPF en DKIM niet samen hoeven te worden gebruikt. 17:55.890 --> 17:56.723 Je kunt het een of het ander gebruiken, 17:56.723 --> 17:58.830 of je kunt beide gebruiken en DMARC wordt gebruikt met een van de twee of met beide. 17:58.830 --> 18:01.020 Als je nu met MARC werkt, 18:01.020 --> 18:03.867 ziet het er zo uit. 18:03.867 --> 18:05.670 Hoe werkt dit allemaal samen? 18:05.670 --> 18:07.050 Eerst moet je ervoor zorgen dat SPF, DKIM 18:07.050 --> 18:08.842 en DMARC allemaal op de DNS-server staan. 18:08.842 --> 18:12.180 Zodra je al die gegevens hebt, 18:12.180 --> 18:15.720 begint het hele proces. 18:15.720 --> 18:17.160 Als je dat eenmaal hebt gedaan, 18:17.160 --> 18:19.260 volgt al het andere elke keer dat je een bericht 18:19.260 --> 18:20.321 wilt sturen. 18:20.321 --> 18:22.320 In dit voorbeeld worden er twee berichten 18:22.320 --> 18:24.540 verzonden, één van de SMTP server, die geautoriseerd 18:24.540 --> 18:27.270 is en groen wordt weergegeven, en één van een tegenstander 18:27.270 --> 18:28.740 die je domein probeert te spoofen, 18:28.740 --> 18:30.960 die rood wordt weergegeven. 18:30.960 --> 18:33.690 Laten we beginnen met degene die geautoriseerd is. 18:33.690 --> 18:35.280 Hier staat het vermeld als 2A. 18:35.280 --> 18:37.350 Je verzender stuurt dat bericht naar de MTA. 18:37.350 --> 18:39.030 Het gaat naar de MTA, wat je 18:39.030 --> 18:42.510 message transfer agent is, en die neemt uiteindelijk 18:42.510 --> 18:45.630 dat bericht aan met de SPF of DKIM header erin. 18:45.630 --> 18:47.340 Laten we even bij deze boodschap blijven 18:47.340 --> 18:49.700 en dan terugkomen op de tegenstander. 18:49.700 --> 18:51.810 Zodra de MTA dat bericht heeft, gaat 18:51.810 --> 18:53.640 het verder en bekijkt het dat 18:53.640 --> 18:55.455 bericht en verwerkt het. 18:55.455 --> 18:57.840 Wanneer het dat doet, zal een deel daarvan het 18:57.840 --> 18:59.400 DMARC-beleid van de afzender 18:59.400 --> 19:02.100 en de SPF- en DKIM-records opzoeken via DNS, net zoals 19:02.100 --> 19:05.430 we in de laatste drie of vier minuten hebben besproken. 19:05.430 --> 19:07.380 Als de MTA dat eenmaal heeft gedaan en het is legitiem, 19:07.380 --> 19:09.330 dan kan dat bericht in de mailbox van de ontvanger 19:09.330 --> 19:12.570 op de IMAP server worden geplaatst en wachten tot de persoon het bericht kan 19:12.570 --> 19:15.360 lezen met behulp van zijn mail user agent. 19:15.360 --> 19:17.790 Dat is allemaal goed, want ze weten dat dit bericht authentiek 19:17.790 --> 19:20.310 was, omdat het die waarden vergeleek met SPF, DKIM of DMARC, 19:20.310 --> 19:21.143 gebaseerd op het beleid 19:21.143 --> 19:22.740 dat was ingesteld. 19:22.740 --> 19:25.897 Als we nu kijken naar de tegenstander aan de andere kant, dan gaat 19:25.897 --> 19:29.370 het bericht nog steeds naar de MTA, omdat het naar de MTA moet om bij de 19:29.370 --> 19:31.020 eindgebruiker te komen. 19:31.020 --> 19:33.205 Maar zodra het daar aankomt, controleert de MTA 19:33.205 --> 19:36.450 het aan de hand van het DMARC-beleid en kijkt daarbij naar de SPF- of 19:36.450 --> 19:37.350 DKIM-records. 19:37.350 --> 19:40.110 Als dat gebeurt en ze komen niet overeen, dan wordt 19:40.110 --> 19:42.600 het bericht geweigerd, verwijderd of in quarantaine 19:42.600 --> 19:44.268 geplaatst en weggegooid, zoals 19:44.268 --> 19:45.990 je kunt zien in 5B. 19:45.990 --> 19:48.210 Nogmaals, dit is de manier waarop deze dingen werken en door 19:48.210 --> 19:50.010 DKIM, DMARC en SPF samen te gebruiken, kunnen we 19:50.010 --> 19:52.110 wat beveiliging toevoegen aan onze organisaties. 19:52.110 --> 19:55.740 Tot slot hebben we een NS-record, wat 19:55.740 --> 19:58.910 staat voor nameserverrecord. 19:58.910 --> 20:01.320 Nu wordt een nameserverrecord gebruikt om aan 20:01.320 --> 20:03.600 te geven welke DNS-naamserver in de wereld de 20:03.600 --> 20:05.730 gezaghebbende wordt voor dat domein. 20:05.730 --> 20:08.550 Dit is belangrijk omdat DNS dat hiërarchische model 20:08.550 --> 20:11.220 gebruikt waar we het over hadden, en alle servers 20:11.220 --> 20:14.160 moeten weten wie de eigenaar van dat record is en gemachtigd 20:14.160 --> 20:16.620 is om wijzigingen aan te brengen. 20:16.620 --> 20:18.900 Een nameserver is een type DNS-server die alle DNS-records 20:18.900 --> 20:20.550 voor een bepaald domein opslaat, inclusief 20:20.550 --> 20:22.855 alle types die we al hebben besproken, zoals A-records, 20:22.855 --> 20:26.460 AAAA-records, canonieke naamrecords, MX-records voor mailuitwisseling en 20:26.460 --> 20:28.800 TXT-tekstrecords. 20:28.800 --> 20:32.940 Er zijn vaak ook meer dan één nameserver voor een domein, dus 20:32.940 --> 20:36.780 je kunt een primaire en een back-up nameserver hebben. 20:36.780 --> 20:39.360 Bovendien hoeft u niet altijd 20:39.360 --> 20:42.960 uw eigen nameservers te hosten. 20:42.960 --> 20:44.421 In het geval van diontraintraining. com, we hosten onze eigen 20:44.421 --> 20:45.930 nameservers niet. 20:45.930 --> 20:47.670 In plaats daarvan vertrouwen we 20:47.670 --> 20:49.410 op Cloudflare, een cloudserviceprovider die dit voor ons doet. 20:49.410 --> 20:51.540 Dus als je de DNS-records voor diontraining. com, de gezaghebbende bron 20:51.540 --> 20:54.510 daarvoor zijn twee van Cloudflare's 20:54.510 --> 20:57.870 nameservers. 20:57.870 --> 20:59.880 Tot nu toe heb ik het gehad over DNS vanuit het perspectief 20:59.880 --> 21:01.593 van het hosten van een publiek beschikbare 21:02.490 --> 21:04.950 DNS server waar iedereen ter wereld toegang toe heeft, maar 21:04.950 --> 21:06.330 DNS kan eigenlijk intern of extern 21:06.330 --> 21:08.250 gebruikt worden. 21:08.250 --> 21:10.230 Alles waar ik het tot nu toe 21:10.230 --> 21:14.100 over heb gehad, gaat over extern, maar laten we het 21:14.100 --> 21:16.380 eens over intern hebben. 21:16.380 --> 21:18.900 Tegenwoordig is het bij cloud computing heel gebruikelijk 21:18.900 --> 21:20.460 om ook een interne DNS-service op 21:20.460 --> 21:22.140 te zetten waarmee je cloudinstanties 21:22.140 --> 21:25.590 binnen hetzelfde netwerk of private cloud elkaar kunnen bereiken via interne 21:25.590 --> 21:28.350 DNS-namen in plaats van via hun IP-adressen. 21:28.350 --> 21:32.250 Om dit te doen, worden interne A-records aangemaakt en worden 21:32.250 --> 21:34.950 er ook interne pointerrecords aangemaakt 21:34.950 --> 21:36.960 in de omgekeerde zone. 21:36.960 --> 21:39.150 Gelukkig zullen de meeste cloudaanbieders deze interne 21:39.150 --> 21:40.740 DNS-records automatisch voor je aanmaken, 21:40.740 --> 21:43.980 bijwerken en verwijderen wanneer je verschillende virtuele machines en andere 21:43.980 --> 21:46.800 instanties in je private cloud aanmaakt en verwijdert. 21:46.800 --> 21:49.200 De meesten van ons zullen echter 21:49.200 --> 21:51.930 meer bekend zijn met extern DNS. 21:51.930 --> 21:54.240 Dit zijn de records die worden aangemaakt rond de domeinnamen 21:54.240 --> 21:55.710 die we kopen van een centrale autoriteit 21:55.710 --> 21:56.940 en die we gebruiken op het openbare 21:56.940 --> 21:58.830 internet. 21:58.830 --> 21:59.970 Voor elk DNS-record hebben we ook 21:59.970 --> 22:02.130 een zogenaamde TTL, of time to live, die eraan gekoppeld is. 22:02.130 --> 22:04.890 De time to live is een instelling die de DNS-oplosser vertelt 22:04.890 --> 22:09.060 hoe lang hij een query kan cachen voordat hij een nieuwe query aanvraagt. 22:09.060 --> 22:12.060 Dus als mijn DNS-records zijn ingesteld met 22:12.060 --> 22:15.540 een time to live van 86.400 seconden, wat meestal de 22:15.540 --> 22:18.390 standaard is, betekent dit dat mijn computer 22:18.390 --> 22:22.380 dat DNS-record omzet en het 24 uur lang onthoudt voordat het 22:22.380 --> 22:25.410 opnieuw naar de DNS-server moet gaan om die informatie 22:25.410 --> 22:27.720 op te vragen. 22:27.720 --> 22:30.090 Deze DNS-resolver, ook wel DNS-cache genoemd, 22:30.090 --> 22:32.160 bevindt zich op je eigen host. 22:32.160 --> 22:35.820 Dus als je bijvoorbeeld Windows 10 gebruikt, maakt je computer een lokale 22:35.820 --> 22:37.410 kopie van elke DNS-vermelding die 22:37.410 --> 22:39.870 wordt omgezet wanneer je verbinding maakt met websites 22:39.870 --> 22:41.610 over het hele internet. 22:41.610 --> 22:43.409 Deze tijdelijke database onthoudt 22:43.409 --> 22:46.680 de antwoorden die het van de DNS-server heeft ontvangen. 22:46.680 --> 22:49.410 Dus als je naar diontraining gaat. com, de eerste keer dat je dat vandaag doet, moet je 22:49.410 --> 22:50.940 computer de DNS-server om dat 22:50.940 --> 22:52.980 IP-adres vragen, 22:52.980 --> 22:54.630 maar nu weet hij waar het is en onthoudt 22:54.630 --> 22:57.720 hij dat IP-adres voor de komende 24 uur. 22:57.720 --> 22:59.550 Als je mijn website vandaag vijf keer bezoekt, 22:59.550 --> 23:02.370 hoefde je dat IP-adres maar één keer op te zoeken. 23:02.370 --> 23:04.620 Dit helpt het hele proces voor ons te versnellen. 23:04.620 --> 23:07.110 Als je het morgen opnieuw probeert, zal je computer 23:07.110 --> 23:09.660 eerst de DNS-cache controleren en zien dat er 23:09.660 --> 23:11.010 een record is. 23:11.010 --> 23:13.590 Maar als die tijd om te leven al voorbij is, 23:13.590 --> 23:15.270 wordt die record ongeldig gemaakt 23:15.270 --> 23:17.520 en wordt er opnieuw gezocht. 23:17.520 --> 23:19.050 Het laatste dat we moeten behandelen 23:19.050 --> 23:20.910 is het concept van een recursieve lookup. 23:20.910 --> 23:23.100 Als uw computer een bepaalde website 23:23.100 --> 23:24.690 zoals diontraining. com, moet het eerst zijn DNS-server 23:24.690 --> 23:26.400 vragen waar het zich bevindt. 23:26.400 --> 23:28.560 Dus als je thuis zit 23:28.560 --> 23:31.830 en bijvoorbeeld een Verizon Fios-verbinding gebruikt, 23:31.830 --> 23:33.210 vraag je hun DNS-server: 23:33.210 --> 23:35.790 "Who's diontraining. com? De DNS van Verizon kent al dan niet het IP-adres 23:35.790 --> 23:39.510 voor diontraining. 23:39.510 --> 23:39.510 com. 23:39.510 --> 23:41.940 Er zijn immers miljoenen en miljoenen websites en als ze onze records 23:41.940 --> 23:44.220 elke 24 uur opnieuw zouden moeten 23:44.220 --> 23:46.200 synchroniseren, zou dat lang duren. 23:46.200 --> 23:48.240 In plaats daarvan gebruikt DNS deze 23:48.240 --> 23:51.900 recursieve strategie om het opzoeken uit te voeren. 23:51.900 --> 23:55.350 Dus je vraagt het aan Verizon en als zij het antwoord niet weten, gaan ze een niveau hoger en vragen 23:55.350 --> 23:56.610 ze het aan de volgende DNS-server. 23:56.610 --> 23:59.850 Als die server het antwoord niet weet, gaat hij een niveau 23:59.850 --> 24:02.820 hoger en gaat hij door tot hij iemand vindt die het 24:02.820 --> 24:04.230 IP-adres van diontraining 24:04.230 --> 24:05.520 kent. com. 24:05.520 --> 24:07.654 Als het tijdens deze recursie 24:07.654 --> 24:11.370 helemaal tot aan de . com of het routedomein voor diontraining. com, dan kan 24:11.370 --> 24:13.740 het de . com routeserver welke DNS-server gezaghebbend 24:13.740 --> 24:16.950 is voor diontrain. com en krijg direct van hen 24:16.950 --> 24:19.170 het juiste antwoord. 24:19.170 --> 24:22.530 Met een recursieve lookup zegt 24:22.530 --> 24:25.320 je DNS-resolver eigenlijk: "Ik weet niet wat het 24:25.320 --> 24:27.090 IP van dit domein is, maar ik ga het 24:27.090 --> 24:28.777 aan mijn DNS-server vragen en 24:28.777 --> 24:30.870 die server zoekt het op totdat hij het 24:30.870 --> 24:32.910 vindt en vertelt me dan dat IP. Er is nog een andere methode die gebruikt 24:32.910 --> 24:35.310 kan worden, die bekend staat als een iteratieve 24:35.310 --> 24:37.140 lookup. 24:37.140 --> 24:38.760 Met een iteratieve lookup is het vergelijkbaar 24:38.760 --> 24:40.620 met een recursieve lookup, behalve dat de DNS-server 24:40.620 --> 24:43.530 de informatie niet voor je blijft opzoeken en je het resultaat stuurt. 24:43.530 --> 24:45.929 In plaats daarvan zal je DNS-oplosser bij een iteratieve 24:45.929 --> 24:48.840 opzoeking aan de DNS-server vragen wat het IP-adres voor het 24:48.840 --> 24:50.730 domein is en als de DNS-server het niet 24:50.730 --> 24:53.550 weet, zal hij je oplosser vertellen om het aan de volgende 24:53.550 --> 24:55.320 DNS-server te vragen en die server zal 24:55.320 --> 24:57.390 het IP-adres leveren. 24:57.390 --> 25:00.390 Bij een recursieve zoekopdracht zal de DNS-server 25:00.390 --> 25:02.820 het opsporen en rapporteren aan de 25:02.820 --> 25:04.800 resolver, maar bij een iteratieve 25:04.800 --> 25:06.510 zoekopdracht zal je DNS-resolver 25:06.510 --> 25:09.390 deze zoekopdracht blijven uitvoeren, helemaal 25:09.390 --> 25:17.310 tot aan de recursie, totdat hij degene vindt met het IP voor dat domein. 25:17.310 --> 25:19.770 Oké, we hebben veel informatie behandeld in deze 25:19.770 --> 25:20.909 les, dus een korte samenvatting: 25:20.909 --> 25:23.670 wat moet je weten voor het examen? 25:23.670 --> 25:26.220 Je moet begrijpen hoe DNS werkt door de verschillende recordtypes 25:26.220 --> 25:28.260 te gebruiken om domeinnamen om te zetten naar IP-adressen 25:28.260 --> 25:30.463 en IP-adressen naar domeinnamen. 25:30.463 --> 25:33.690 Je moet onthouden dat A-records worden gebruikt voor domeinnamen 25:33.690 --> 25:36.840 met IPv4-adressen, terwijl AAAA-records worden gebruikt 25:36.840 --> 25:39.213 voor domeinnamen met IPV6-adressen. 25:39.213 --> 25:42.990 CNAME-records worden gebruikt om domeinnamen aan 25:42.990 --> 25:45.840 andere domeinnamen te koppelen. 25:45.840 --> 25:48.030 MX records worden gebruikt voor e-mail en NS records 25:48.030 --> 25:49.530 worden gebruikt voor nameservers. 25:49.530 --> 25:51.450 TXT-records slaan tekst op als menselijk 25:51.450 --> 25:53.910 leesbare of machinaal leesbare gegevens. 25:53.910 --> 25:56.700 Als je deze samenvatting onthoudt, zou je in staat moeten zijn om vrijwel 25:56.700 --> 25:58.410 alle DNS-vragen te beantwoorden die je op 25:58.410 --> 25:59.850 het examen zult tegenkomen.