WEBVTT 00:00.290 --> 00:01.920 Jason: W tej lekcji porozmawiamy 00:01.920 --> 00:04.920 o systemie nazw domen, czyli DNS. 00:04.920 --> 00:08.070 Protokół DNS jest używany, aby pomóc klientom sieci znaleźć stronę 00:08.070 --> 00:10.410 internetową przy użyciu czytelnych dla człowieka 00:10.410 --> 00:12.720 nazw hostów zamiast numerycznych adresów IP. 00:12.720 --> 00:15.360 Na przykład, gdybym polecił ci odwiedzić moją stronę internetową, mógłbym po prostu 00:15.360 --> 00:18.750 powiedzieć: "Hej, przejdź do diontraining. com", co jest o wiele łatwiejsze do zapamiętania niż konieczność 00:18.750 --> 00:23.310 pamiętania, że jest to 66. 00:23.310 --> 00:23.310 123. 45. 237 00:26.280 --> 00:29.670 lub jakikolwiek inny adres IP mojego serwera WWW. 00:29.670 --> 00:32.010 W końcu wypowiadanie tych wszystkich liczb w ramach reklamy 00:32.010 --> 00:34.590 telewizyjnej nie jest tak chwytliwe ani zapadające w pamięć, jak 00:34.590 --> 00:35.960 powiedzenie konsumentowi, aby odwiedził 00:35.960 --> 00:41.760 diontraining. com, czy coca-cola. com lub microsoft. 00:41.760 --> 00:41.760 com, prawda? 00:41.760 --> 00:43.680 Skąd więc komputer wie, jak znaleźć 00:43.680 --> 00:45.240 adres IP serwera WWW na podstawie 00:45.240 --> 00:47.220 tych różnych nazw domen? 00:47.220 --> 00:51.720 Cóż, taki jest cel DNS, systemu nazw domen. 00:51.720 --> 00:54.990 Sposób działania DNS polega na tym, że komputer użytkownika otrzymuje polecenie przejścia do 00:54.990 --> 00:57.660 miejsca takiego jak diontraining. com, więc dociera do 00:57.660 --> 00:59.797 serwera DNS i mówi: "Hej, kim jest 00:59.797 --> 01:02.139 diontraining. com? Serwer DNS odpowie 01:02.139 --> 01:07.140 "Oh, znam diontraining. 01:07.140 --> 01:07.140 com. 01:07.140 --> 01:09.900 Jego adres IP to 66 kropka coś, kropka 01:09.900 --> 01:11.610 coś, kropka coś. Następnie klient zostaje przekierowany 01:11.610 --> 01:14.490 do serwera WWW przy użyciu swojego routera i sposobu 01:14.490 --> 01:17.370 połączenia, ponieważ zna teraz właściwy adres 01:17.370 --> 01:19.170 IP do użycia jako miejsce docelowe, 01:19.170 --> 01:21.930 a wszystko to dzieje się w tle dla użytkowników 01:21.930 --> 01:24.360 i komputera, bez konieczności proszenia 01:24.360 --> 01:30.660 o to, ponieważ DNS jest tak wbudowaną częścią naszych sieci i systemów. 01:30.660 --> 01:33.360 Teraz większość z nas, jako użytkowników domowych, nie będzie uruchamiać 01:33.360 --> 01:35.550 własnych serwerów DNS, ale zamiast tego polegamy na 01:35.550 --> 01:38.820 naszych dostawcach usług internetowych, którzy robią to za nas. 01:38.820 --> 01:40.770 Ale jeśli prowadzisz własne strony internetowe 01:40.770 --> 01:43.110 lub naszą dużą sieć korporacyjną, możesz mieć również 01:43.110 --> 01:45.690 własny serwer DNS w swojej sieci i będziesz odpowiedzialny 01:45.690 --> 01:47.160 za skonfigurowanie własnych 01:47.160 --> 01:49.050 rekordów DNS, które dyktują, które serwery 01:49.050 --> 01:53.303 znajdują się pod jakimi adresami IP i do jakich celów. 01:53.303 --> 01:55.620 Pozwala to na uruchomienie własnego rozpoznawania 01:55.620 --> 01:58.620 nazw domen i hostów, które konwertuje te nazwy domen 01:58.620 --> 02:00.120 na adresy IP. 02:00.120 --> 02:01.380 Jeśli chcesz myśleć o tym w ten 02:01.380 --> 02:04.440 sposób, jest to podobne do posiadania listy kontaktów w telefonie. 02:04.440 --> 02:07.380 Ile numerów telefonów zapamiętałeś w dzisiejszych czasach? 02:07.380 --> 02:09.120 Prawdopodobnie nie jest ich dużo, prawda? 02:09.120 --> 02:11.490 Ponieważ normalnie wyciągasz smartfona, przewijasz 02:11.490 --> 02:13.800 do imienia danej osoby i uderzasz palcem w jej imię, 02:13.800 --> 02:16.350 a następnie telefon wybiera jej numer. 02:16.350 --> 02:19.500 Na przykład, jeśli chcę zadzwonić do mojej żony, przewijam do jej imienia, 02:19.500 --> 02:21.480 naciskam zdjęcie jej twarzy na moim telefonie, 02:21.480 --> 02:24.600 a następnie natychmiast mój telefon wybiera jej numer. 02:24.600 --> 02:27.390 Nie muszę zapamiętywać wszystkich 10 cyfr jej numeru telefonu, 02:27.390 --> 02:29.400 ponieważ mój telefon robi to za mnie. 02:29.400 --> 02:31.020 Dzieje się tak dlatego, że jako 02:31.020 --> 02:34.200 ludzie trudniej zapamiętujemy numery niż imiona, więc dokonujemy 02:34.200 --> 02:37.290 konwersji twarzy lub imienia na numer, korzystając z naszej 02:37.290 --> 02:39.000 listy kontaktów. 02:39.000 --> 02:40.800 To samo dotyczy komputerów, z wyjątkiem 02:40.800 --> 02:42.808 tego, że komputery lubią liczby o wiele 02:42.808 --> 02:45.840 bardziej niż nazwy, więc chcemy przekonwertować nazwy 02:45.840 --> 02:49.410 domen, które są dla nas łatwiejsze, na adresy IP, które są łatwiejsze 02:49.410 --> 02:52.260 dla komputerów do routingu, i to wszystko, co naprawdę 02:52.260 --> 02:54.330 robi dla nas DNS. 02:54.330 --> 02:57.510 Konwertuje nazwy na liczby i liczby na nazwy. 02:57.510 --> 02:59.280 Jedną z koncepcji DNS, o której 02:59.280 --> 03:00.810 musimy porozmawiać, jest 03:00.810 --> 03:04.590 tak zwana w pełni kwalifikowana nazwa domeny (FQDN). 03:04.590 --> 03:08.040 Dzieje się tak, gdy nazwa domeny znajduje się pod dostawcą najwyższego poziomu. 03:08.040 --> 03:11.670 Na przykład najpopularniejszym dostawcą najwyższego poziomu jest . com, ale mamy też takie rzeczy 03:11.670 --> 03:16.200 jak . młyn, . edu, . org, . netto. 03:16.200 --> 03:18.360 Posłużmy się przykładem Dion Training. 03:18.360 --> 03:21.210 W Dion Training mamy wiele różnych serwerów. 03:21.210 --> 03:23.220 Jednym z naszych serwerów jest nasz serwer WWW, 03:23.220 --> 03:27.750 który znajduje się pod adresem www. diontraining. com. 03:27.750 --> 03:30.660 Domena najwyższego poziomu to . com. 03:30.660 --> 03:33.420 Nazwa domeny, której używam to Dion Training. 03:33.420 --> 03:37.650 Aby być w pełni kwalifikowanym, muszę dodać WWW przed nim. 03:37.650 --> 03:41.910 To sprawia, że www. diontraining. com. 03:41.910 --> 03:43.770 Teraz, jeśli chcesz przejść do mojego 03:43.770 --> 03:45.840 serwera internetowego, to właśnie to wpiszesz 03:45.840 --> 03:49.890 w przeglądarce, www. diontraining. com, a teraz zostaniesz przekierowany 03:49.890 --> 03:53.160 na mój serwer internetowy, ponieważ DNS wie, jak powinien obrócić adres 03:53.160 --> 03:55.350 IP mojego serwera internetowego przy użyciu tej 03:55.350 --> 03:57.900 w pełni kwalifikowanej nazwy domeny. 03:57.900 --> 04:00.300 Teraz, jeśli zamiast tego chcesz przejść do mojego serwera plików, 04:00.300 --> 04:03.660 będziesz musiał wpisać ftp. diontraining. com, ponieważ jest 04:03.660 --> 04:05.820 to serwer, który tam uruchamiam. 04:05.820 --> 04:07.290 Jeśli chcesz przejść do mojego serwera pocztowego, 04:07.290 --> 04:10.140 możesz wpisać mail. diontraining. com. 04:10.140 --> 04:11.610 Wszystkie trzy są przykładami 04:11.610 --> 04:14.910 w pełni kwalifikowanych nazw domen lub FQDN. 04:14.910 --> 04:17.790 Zasadniczo istnieje usługa, kropka, nazwa domeny, 04:17.790 --> 04:21.240 kropka i domena najwyższego poziomu, a to działa w ten sam 04:21.240 --> 04:22.830 sposób bez względu na to, na 04:22.830 --> 04:25.680 którą domenę patrzysz w Internecie. 04:25.680 --> 04:28.830 Teraz DNS zostanie skonfigurowany jako hierarchia. 04:28.830 --> 04:31.050 Dzieje się to na pięciu różnych poziomach. 04:31.050 --> 04:33.750 Mamy poziom trasy, domenę najwyższego poziomu, 04:33.750 --> 04:37.260 domeny drugiego poziomu, subdomeny i hosta. 04:37.260 --> 04:39.060 Poziom trasy jest najwyższym poziomem 04:39.060 --> 04:40.800 w drzewie hierarchii DNS, a serwer 04:40.800 --> 04:42.930 nazw trasy będzie odpowiadał na żądania 04:42.930 --> 04:44.550 w strefie trasy. 04:44.550 --> 04:46.320 Serwery te zawierają globalną listę wszystkich 04:46.320 --> 04:49.867 domen najwyższego poziomu, np. com,. net, . org, . młyn i inne. 04:49.867 --> 04:53.190 Drugim poziomem w dół będą domeny najwyższego poziomu. 04:53.190 --> 04:56.700 Są one podzielone na dwie kategorie, hierarchie 04:56.700 --> 05:03.300 organizacyjne, takie jak . com, . net, . org i inne, a następnie 05:03.300 --> 05:06.000 hierarchię geograficzną, taką jak . uk dla Wielkiej Brytanii, . fr dla Francji. dla Włoch i innych podobnych krajów. 05:06.000 --> 05:10.447 Trzeci poziom w dół znany jest jako domeny drugiego poziomu. 05:10.447 --> 05:13.620 Domeny te znajdują się bezpośrednio pod domeną najwyższego poziomu. 05:13.620 --> 05:16.710 Na przykład, moja domena Dion Training 05:16.710 --> 05:20.160 jest domeną drugiego poziomu pod domeną . com. 05:20.160 --> 05:23.130 The . com znajduje się pod domeną trasy. 05:23.130 --> 05:27.510 Jest to sposób, w jaki te rzeczy rosną razem 05:27.510 --> 05:30.900 jako część hierarchii. 05:30.900 --> 05:33.270 Czwarty poziom w dół jest znany jako subdomena, 05:33.270 --> 05:34.950 więc gdybym chciał utworzyć nowy 05:34.950 --> 05:37.830 serwer pod moją domeną drugiego poziomu diontraining. com, mogę to zrobić za pomocą 05:37.830 --> 05:39.720 subdomeny. 05:39.720 --> 05:43.170 W moim przypadku mam wiele różnych 05:43.170 --> 05:45.330 subdomen do różnych celów. 05:45.330 --> 05:47.580 Moja główna strona jest hostowana w subdomenie 05:47.580 --> 05:48.870 www, więc wpisujesz www. diontraining. com, która prowadzi 05:48.870 --> 05:52.590 do mojego serwera internetowego, ale mam też jeden o nazwie 05:52.590 --> 05:56.070 support. 05:56.070 --> 05:57.840 Teraz subdomena wsparcia znajduje 05:57.840 --> 05:59.910 się pod adresem wsparcia. diontraining. com. 05:59.910 --> 06:01.740 Mam jeszcze jeden dla poczty, poczty. diontraining. com. 06:01.740 --> 06:04.320 Są to różne subdomeny. 06:04.320 --> 06:07.620 Piąty i ostatni poziom to poziom hosta. 06:07.620 --> 06:09.660 Jest to najniższy i najbardziej szczegółowy 06:09.660 --> 06:12.750 poziom w hierarchii DNS i odnosi się do konkretnej maszyny 06:12.750 --> 06:14.760 lub serwera w sieci. 06:14.760 --> 06:17.070 Kiedy jednak myślimy o DNS, większość 06:17.070 --> 06:19.887 z nas myśli o czymś takim jak w pełni kwalifikowana 06:19.887 --> 06:21.870 nazwa domeny, coś w rodzaju 06:21.870 --> 06:23.640 www. diontraining. com, która zawiera subdomenę, domenę 06:23.640 --> 06:25.620 drugiego poziomu i domenę najwyższego 06:25.620 --> 06:28.710 poziomu. 06:28.710 --> 06:31.170 Teraz, jeśli chciałbym pójść o krok dalej, mogę spojrzeć 06:31.170 --> 06:32.940 na to z perspektywy adresu URL, który jest 06:32.940 --> 06:34.920 znany jako jednolity lokalizator zasobów. 06:34.920 --> 06:37.170 Ponownie, weźmy jako przykład 06:37.170 --> 06:40.110 mój serwer WWW, www. diontraining. com. 06:40.110 --> 06:41.700 To moja w pełni kwalifikowana nazwa domeny, ale 06:41.700 --> 06:45.540 nie mówi, jak uzyskać do niej dostęp. 06:45.540 --> 06:47.700 Czy chcesz to zrobić bezpiecznie czy niepewnie? 06:47.700 --> 06:50.460 Cóż, będziesz musiał to stwierdzić, wykonując adres URL. 06:50.460 --> 06:53.100 Cóż, jeśli chcesz podać mi swoją nazwę użytkownika 06:53.100 --> 06:56.610 i hasło, powinieneś zrobić to bezpiecznie. 06:56.610 --> 06:58.950 Należy więc dodać HTTPS:// 06:58.950 --> 07:00.720 przed www. diontraining. com, który staje się adresem 07:00.720 --> 07:05.190 URL, jednolitym lokalizatorem zasobów, ponieważ mówi, jak uzyskać dostęp 07:05.190 --> 07:09.660 do diontraining. com. 07:09.660 --> 07:12.450 Dlatego właśnie mamy ten HTTPS na początku. 07:12.450 --> 07:16.200 Jest to bezpieczny protokół transferu 07:16.200 --> 07:19.170 hipertekstowego i jest to metoda dostępu do niego. 07:19.170 --> 07:22.020 Teraz, jeśli chcesz uzyskać dostęp do mojej witryny i zrobić to w sposób 07:22.020 --> 07:24.180 niezabezpieczony, możesz to zrobić, dodając HTTP:// 07:24.180 --> 07:25.650 na początku adresu internetowego. 07:25.650 --> 07:28.110 Teraz, jeśli chcesz połączyć 07:28.110 --> 07:32.430 się za pomocą FTP, użyj FTP://FTP. diontraining. com jako adres URL, a więc istnieje wiele różnych sposobów, aby to 07:32.430 --> 07:34.320 zrobić, gdy powiesz systemowi, 07:34.320 --> 07:39.320 co ma zrobić, a to utworzy 07:40.230 --> 07:42.000 adres URL i w pełni kwalifikowaną 07:42.000 --> 07:43.860 nazwę domeny. 07:43.860 --> 07:45.450 Następnie musimy omówić różne typy 07:45.450 --> 07:47.670 rekordów DNS, które istnieją na serwerze DNS. 07:47.670 --> 07:49.470 Wewnątrz serwera DNS będziesz tworzyć 07:49.470 --> 07:53.100 różne rekordy, które przechowują różne typy informacji w zależności 07:53.100 --> 07:55.200 od przypadku użycia. 07:55.200 --> 07:58.170 Są one znane jako rekordy A, rekordy AAAA, rekordy CNAME, rekordy 07:58.170 --> 07:59.760 MX, rekordy TXT i rekordy NS. 07:59.760 --> 08:04.470 Rzućmy okiem na każdy z tych różnych 08:04.470 --> 08:08.520 typów rekordów. 08:08.520 --> 08:09.600 Po pierwsze, mamy rekord 08:09.600 --> 08:11.610 A, który oznacza rekord adresu. 08:11.610 --> 08:13.170 Rekord A służy do powiązania 08:13.170 --> 08:15.210 nazwy hosta z adresem IPv4. 08:15.210 --> 08:17.370 Na przykład, istnieje rekord A dla www. diontraining. com i łączy go z adresem 08:17.370 --> 08:19.350 IP 45. 79. 184. 180. 08:19.350 --> 08:24.000 Oprócz tego można również ustawić rekord A 08:24.000 --> 08:27.450 dla hosta @, co oznacza rekord 08:30.720 --> 08:31.650 dla domeny trasy. 08:31.650 --> 08:34.350 W przykładzie Dion Training, nasz rekord 08:34.350 --> 08:36.930 @ oznacza, że diontraining. com, która jest trasą naszej domeny, będzie 08:36.930 --> 08:38.400 wyświetlana pod określonym 08:38.400 --> 08:41.430 adresem IP. 08:41.430 --> 08:43.980 W ten sposób nasi użytkownicy mogą znaleźć naszą witrynę, 08:43.980 --> 08:45.510 przechodząc do subdomeny www. diontraining. com lub po prostu wchodząc 08:45.510 --> 08:47.910 na stronę diontraining. com przy użyciu tego rekordu 08:47.910 --> 08:51.180 A @. 08:51.180 --> 08:54.060 Obecnie rekordy A działają tylko dla adresów 08:54.060 --> 08:56.820 IPv4, ale wiele nowoczesnych stron internetowych obsługuje również IPv6. 08:56.820 --> 09:00.210 Aby zmapować nazwę domeny na adres 09:00.210 --> 09:04.410 IPv6, należy użyć rekordu AAAA. 09:04.410 --> 09:06.804 Tak więc, używając witryny Dion Training jako przykładu, 09:06.804 --> 09:09.870 mógłbym ustawić rekord AAAA na 2400:cb00:2049:1::a29f:1804, 09:09.870 --> 09:12.930 gdyby był to adres IPv6 mojego serwera WWW. 09:12.930 --> 09:17.930 Jak widać, adresy IPv6 są o wiele bardziej skomplikowane niż 09:26.400 --> 09:29.730 IPv4 i naprawdę trudne do zapamiętania 09:29.730 --> 09:30.563 dla nas, ludzi, 09:30.563 --> 09:34.110 dlatego lubimy używać tych rekordów AAAA 09:34.110 --> 09:36.300 lub rekordów 4A. 09:36.300 --> 09:39.630 Kolejnym typem rekordu, którego możemy użyć, jest znany jako rekord 09:39.630 --> 09:41.580 CNAME lub rekord nazwy kanonicznej. 09:41.580 --> 09:43.650 Teraz rekord CNAME jest używany zamiast 09:43.650 --> 09:46.620 rekordu A dla rekordu AAAA, jeśli chcesz wskazać domenę 09:46.620 --> 09:49.200 na inną nazwę domeny lub nazwę subdomeny. 09:49.200 --> 09:52.230 Na przykład, posiadam wiele różnych 09:52.230 --> 09:55.050 nazw domen oprócz diontraining. com. 09:55.050 --> 09:58.020 Niektóre z nich dotyczą byłych firm, które prowadziłem lub projektów, 09:58.020 --> 10:00.120 które prowadziłem, a niektóre 10:00.120 --> 10:02.220 z nich planuję wykorzystać kiedyś w przyszłości, 10:02.220 --> 10:05.220 ale w międzyczasie mam je ustawione z rekordem CNAME, który rozwiązuje 10:05.220 --> 10:07.890 się z powrotem na diontraining. com. 10:07.890 --> 10:09.780 Na przykład, kiedyś prowadziłem stronę internetową o nazwie itil4exam. com, ale od tego czasu przestałem 10:09.780 --> 10:12.300 używać tej nazwy domeny 10:12.300 --> 10:15.960 i połączyłem wszystkie te kursy 10:15.960 --> 10:18.570 w moją własną diontraining. com. 10:18.570 --> 10:20.430 Więc kiedy zamknąłem ten stary serwer internetowy, nadal chciałem 10:20.430 --> 10:23.160 umożliwić ludziom wpisywanie itil4exam. com i osiągnąć coś 10:23.160 --> 10:25.380 zamiast strony błędu. 10:25.380 --> 10:28.770 Użyłem więc rekordu CNAME, aby 10:28.770 --> 10:31.650 skierować go bezpośrednio na diontraining. com. 10:31.650 --> 10:33.510 Dlaczego miałbym to robić? 10:33.510 --> 10:36.180 Cóż, byliśmy w innym miejscu przez kilka 10:36.180 --> 10:37.542 lat równolegle z diontrainingiem. com, a wiele z zamieszczonych 10:37.542 --> 10:40.200 tam linków jest w całym Internecie z rekomendacjami 10:40.200 --> 10:42.390 do naszych kursów, które 10:42.390 --> 10:45.060 były hostowane na itil4exam. com. 10:45.060 --> 10:47.400 Jednym z naszych najpopularniejszych kursów z tej strony 10:47.400 --> 10:50.100 był nasz kurs ITIL 4 Foundation, 10:50.100 --> 10:52.260 który znajdował się pod adresem itil4exam. com/itil-4-foundation. 10:52.260 --> 10:54.000 Teraz, jeśli wpiszesz to w przeglądarce 10:54.000 --> 10:59.000 internetowej, rozwiąże ona itil4exam. com część do diontraining. com i przeniesie Cię bezpośrednio 10:59.430 --> 11:01.680 do diontraining. com/itil-4-foundation. 11:01.680 --> 11:06.000 Oznacza to, że nawet jeśli korzystasz 11:06.000 --> 11:11.000 z linku znalezionego na Reddicie, który polecał nasz 11:11.550 --> 11:13.500 kurs sprzed kilku lat, nadal będzie on działał 11:13.500 --> 11:15.510 i przeniesie Cię na naszą stronę sprzedaży, 11:15.510 --> 11:17.790 mimo że oryginalny itil4exam. com nie działa i został 11:17.790 --> 11:20.070 wyłączony. 11:20.070 --> 11:23.370 Innym przypadkiem użycia rekordu 11:23.370 --> 11:25.950 CNAME jest korzystanie z oprogramowania jako usługi, 11:25.950 --> 11:28.380 które zapewnia subdomenę na swoim serwerze. 11:28.380 --> 11:30.630 Na przykład, korzystam z oprogramowania do śledzenia zgłoszeń serwisowych 11:30.630 --> 11:33.240 znanego jako Freshdesk, które jest dostępne pod adresem freshdesk. com i dali nam dość trudną do 11:33.240 --> 11:36.360 zapamiętania subdomenę dla swojej 11:36.360 --> 11:39.780 usługi, coś w rodzaju 11:39.780 --> 11:42.060 FDUS-143-D15. freshdesk. com. 11:42.060 --> 11:42.960 Aby ułatwić moim pracownikom znalezienie 11:42.960 --> 11:47.160 naszego działu pomocy technicznej, utworzyliśmy 11:49.050 --> 11:52.170 rekord CNAME o nazwie Support i skierowaliśmy go na tę trudną do zapamiętania subdomenę. 11:52.170 --> 11:54.840 Więc jeśli moi pracownicy wejdą do wsparcia. diontraining. com, przenosi ich bezpośrednio do naszego systemu wsparcia, 11:54.840 --> 11:57.780 który w rzeczywistości przekierowuje nas do tej instancji w chmurze, 11:57.780 --> 12:01.230 która jest dostarczana przez 12:01.230 --> 12:03.330 subdomenę wydaną przez Freshdesk. 12:03.330 --> 12:06.180 Pamiętaj, że rekordy CNAME nie mogą 12:06.180 --> 12:09.480 być używane do wskazywania adresu IP. 12:09.480 --> 12:12.180 Może być używany tylko do wskazywania innej nazwy 12:12.180 --> 12:13.710 domeny lub subdomeny. 12:13.710 --> 12:15.030 Następnie mamy rekord 12:15.030 --> 12:17.940 MX, który oznacza rekord wymiany poczty 12:17.940 --> 12:19.890 i robi to, co myślisz. 12:19.890 --> 12:21.930 Pomaga ustalić, gdzie znajduje się serwer poczty e-mail. 12:21.930 --> 12:23.670 Rekord MX służy do kierowania wiadomości e-mail na serwer pocztowy. 12:23.670 --> 12:26.370 Rekordy MX, podobnie jak rekordy CNAME, mogą 12:26.370 --> 12:30.360 być używane tylko do wskazywania innej domeny, a nie adresu IP. 12:30.360 --> 12:33.750 Podczas tworzenia rekordów MX, będziesz również 12:33.750 --> 12:36.780 w stanie określić priorytet dla każdego z 12:36.780 --> 12:38.340 tych rekordów. 12:38.340 --> 12:39.863 Umożliwia to wskazanie preferencji dotyczących serwera, 12:39.863 --> 12:42.030 z którego wiadomość e-mail powinna próbować korzystać w pierwszej kolejności. 12:42.030 --> 12:43.770 Jeśli chodzi o ustawianie 12:43.770 --> 12:47.220 priorytetu, im niższa wprowadzona liczba, tym 12:47.220 --> 12:48.900 wyższy priorytet. 12:48.900 --> 12:50.490 Zasadniczo są to zasady gry w golfa. 12:50.490 --> 12:52.140 Więc jeśli mamy mail1. diontrainf. com ustawiono 12:52.140 --> 12:54.270 na 10, a mail2. diontraining. com ustawione na 20 dla ich priorytetów, e-maile będą próbowały 12:54.270 --> 12:57.720 najpierw użyć poczty pierwszej. 12:57.720 --> 13:01.140 Jeśli nie uda mu się dotrzeć 13:01.140 --> 13:04.200 do poczty pierwszej, spróbuje dotrzeć do poczty drugiej. 13:04.200 --> 13:05.700 Teraz, jeśli chcesz zrównoważyć obciążenie 13:05.700 --> 13:07.860 poczty e-mail na wielu serwerach, wystarczy ustawić 13:07.860 --> 13:09.960 ich priorytety na tę samą wartość. 13:09.960 --> 13:11.640 Jeśli więc utworzyłem rekordy dla 13:11.640 --> 13:14.760 poczty pierwszej i drugiej, a oba mają priorytet 10, wszystkie 13:14.760 --> 13:17.730 przychodzące wiadomości e-mail będą naprzemiennie i równomiernie 13:17.730 --> 13:19.770 obciążać te serwery. 13:19.770 --> 13:21.990 Pierwszy przechodzi na jeden, 13:21.990 --> 13:24.240 drugi na dwa, trzeci na jeden, 13:24.240 --> 13:26.820 czwarty na dwa itd. 13:26.820 --> 13:28.050 Następnie mamy rekordy TXT, czyli rekordy tekstowe. 13:28.050 --> 13:30.600 Obecnie rekord tekstowy jest używany przez administratorów 13:30.600 --> 13:33.720 domen do dodawania tekstu do systemu nazw domen (DNS). 13:33.720 --> 13:36.120 Pierwotnie rekordy tekstowe zostały zaprojektowane 13:36.120 --> 13:39.810 jako sposób na dodawanie czytelnych dla człowieka notatek do naszych rekordów 13:39.810 --> 13:42.420 DNS, a z biegiem czasu coraz więcej rzeczy zaczęło być 13:42.420 --> 13:45.450 dodawanych do tych rekordów tekstowych, a ostatecznie zaczęliśmy 13:45.450 --> 13:48.000 dodawać dane do odczytu maszynowego również do tych 13:48.000 --> 13:50.850 rekordów tekstowych, i to właśnie tam zobaczysz głównie 13:50.850 --> 13:53.970 w dzisiejszych czasach. 13:53.970 --> 13:55.770 Twoja domena może mieć również 13:55.770 --> 13:57.990 wiele różnych rekordów tekstowych. 13:57.990 --> 13:59.160 Nie jesteś ograniczony tylko do jednego z nich. 13:59.160 --> 14:00.720 W większości przypadków rekordy tekstowe 14:00.720 --> 14:02.640 są używane do udowodnienia własności domeny poprzez 14:02.640 --> 14:05.100 dodanie kodu do odczytu maszynowego w celu weryfikacji oraz do zapobiegania 14:05.100 --> 14:06.990 spamowi e-mail, ponownie poprzez dodanie określonego 14:06.990 --> 14:09.420 kodu do odczytu maszynowego do rekordu TXT. 14:09.420 --> 14:12.540 Na przykład w diontraining. com, mamy rekord tekstowy 14:12.540 --> 14:15.990 o nazwie fdkey. i teksturowanie 32 cyfr szesnastkowych 14:15.990 --> 14:18.330 wewnątrz naszych 14:18.330 --> 14:21.820 rekordów DNS. 14:21.820 --> 14:24.870 Pozwala to naszemu systemowi wsparcia Freshdesk zweryfikować, że jesteśmy 14:24.870 --> 14:26.970 właścicielem nazwy domeny diontraining. com, więc są upoważnieni do wysyłania wiadomości 14:26.970 --> 14:30.000 e-mail w naszym imieniu do naszych studentów, gdy nasz zespół odpowiada 14:30.000 --> 14:32.670 w ich systemie na zgłoszenie 14:32.670 --> 14:34.712 do pomocy technicznej. 14:34.712 --> 14:37.140 Jest to forma weryfikacji własności domeny, ponieważ 14:37.140 --> 14:39.870 ich system może sprawdzić nasze rekordy DNS i zobaczyć, 14:39.870 --> 14:42.660 że wprowadziliśmy tę unikalną serię 32 cyfr szesnastkowych 14:42.660 --> 14:45.240 do naszego rekordu DNS TXT. 14:45.240 --> 14:47.130 Zasadniczo działa to jak hasło, 14:47.130 --> 14:51.360 które mówi: "Hej, jestem właścicielem tej domeny. W rekordach TXT można również umieścić informacje takie jak SPF, 14:51.360 --> 14:53.407 DKIM lub wiadomości DMARC, aby pomóc 14:53.407 --> 14:55.348 w weryfikacji usług e-mail i zablokować 14:55.348 --> 14:57.932 przesyłanie fałszywych lub niechcianych 14:57.932 --> 15:01.950 wiadomości znanych jako spam do innych osób korzystających z 15:01.950 --> 15:04.950 domeny i adresów e-mail. 15:04.950 --> 15:06.535 SPF lub sender policy 15:06.535 --> 15:10.068 framework, jest to rekord DNS, który identyfikuje 15:10.068 --> 15:13.170 hosta upoważnionego do wysyłania poczty 15:13.170 --> 15:15.300 dla domeny i będzie tylko jeden 15:15.300 --> 15:18.300 dozwolony dla każdej domeny. 15:18.300 --> 15:19.920 Teraz, patrząc na nie, będziesz mieć coś, 15:19.920 --> 15:21.780 co wygląda tak, a jest to rekord DNS zwany rekordem 15:21.780 --> 15:22.800 tekstowym. 15:22.800 --> 15:24.480 Zauważysz, że ma znak @, a następnie 15:24.480 --> 15:27.240 mówi V=SPF1, co jest strukturą polityki nadawcy jeden. 15:27.240 --> 15:31.350 To pierwszy z nich. 15:31.350 --> 15:33.600 Następnie ma MX, który jest rekordem serwera pocztowego, 15:33.600 --> 15:37.830 a następnie mówi include:_SPF. google. com i dołączyć:email. 15:37.830 --> 15:37.830 freshdesk. com-all. 15:37.830 --> 15:41.520 Co ci to mówi? 15:41.520 --> 15:46.200 W rzeczywistości jest to rekord SPF dla mojego serwera pocztowego. 15:46.200 --> 15:47.700 Teraz, dlaczego mamy google. com tam? 15:47.700 --> 15:51.390 Cóż, to dlatego, że używamy G Suite od Google, a więc Google jest naszym dostawcą 15:51.390 --> 15:53.640 usług e-mail. 15:53.640 --> 15:55.620 Nie prowadzimy własnego serwera poczty e-mail. 15:55.620 --> 15:57.600 Zamiast tego pozwalamy im to robić i dajemy im do tego upoważnienie, 15:57.600 --> 15:58.920 że są upoważnieni do wysyłania wiadomości 15:58.920 --> 16:00.330 e-mail w naszym imieniu poprzez dołączenie 16:00.330 --> 16:02.100 oświadczenia SPF. 16:02.100 --> 16:04.052 Drugi z nich może cię 16:04.052 --> 16:06.510 zastanawiać: "Po co to? 16:06.510 --> 16:07.343 Myślałem, że można mieć tylko jedną. Cóż, możesz mieć tylko 16:07.343 --> 16:08.970 jedną deklarację SPF, ale cała ta 16:08.970 --> 16:10.440 rzecz jest jedną linią, gdy jest 16:10.440 --> 16:12.960 napisana w DNS, a cała ta rzecz od tekstu aż do wszystkich 16:12.960 --> 16:16.560 jest jedną linią, a to jest jedna pojedyncza deklaracja SPF. 16:16.560 --> 16:19.230 Mogę autoryzować wiele serwerów do wysyłania w moim imieniu, 16:19.230 --> 16:22.050 ale mogę to zrobić tylko w jednej linii DNS, jak widać tutaj, 16:22.050 --> 16:24.930 a Freshdesk to nasz system zgłoszeń problemów. 16:24.930 --> 16:28.710 Jeśli wyślesz wiadomość e-mail do działu pomocy technicznej w Dion Training, 16:28.710 --> 16:31.170 trafi ona do Freshdesk, ale jeśli wyślesz wiadomość 16:31.170 --> 16:33.060 e-mail na mój osobisty adres e-mail w Dion 16:33.060 --> 16:34.770 Training, trafi ona do Google, ponieważ 16:34.770 --> 16:37.980 to on obsługuje nasze osobiste wiadomości e-mail dla naszej firmy, 16:37.980 --> 16:39.300 więc musisz uwzględnić oba 16:39.300 --> 16:42.540 te elementy we wszystkim, co będzie autoryzowane do wysyłania w Twoim 16:42.540 --> 16:44.940 imieniu w tym oświadczeniu. 16:44.940 --> 16:46.592 Następną rzeczą, o której musimy porozmawiać, jest DKIM lub dkim. 16:46.592 --> 16:48.660 Teraz jest to poczta identyfikowana za pomocą kluczy domeny. 16:48.660 --> 16:52.500 Zapewnia to kryptograficzny mechanizm uwierzytelniania poczty przy użyciu klucza 16:52.500 --> 16:55.020 publicznego opublikowanego jako rekord DNS. 16:55.020 --> 16:57.660 Teraz, gdy sprawdzisz SPF 16:57.660 --> 17:01.252 lub DKIM, zobaczysz coś takiego. 17:01.252 --> 17:03.960 Oto przykład pokazujący pocztę dla Adobe. com. 17:03.960 --> 17:05.339 Możesz zobaczyć DMARC na górze, 17:05.339 --> 17:08.910 o którym porozmawiamy za chwilę, zobaczysz 17:08.910 --> 17:10.290 SPF, o którym właśnie rozmawialiśmy, 17:10.290 --> 17:11.520 a następnie zobaczysz DKIM, 17:11.520 --> 17:13.800 o którym teraz mówimy. 17:13.800 --> 17:14.700 Jest to w zasadzie bardzo długi kryptograficzny 17:14.700 --> 17:16.200 klucz uwierzytelniający, który można zobaczyć na ekranie. 17:16.200 --> 17:19.440 Obecnie DKIM może zastąpić SPF lub być z nim używany. 17:19.440 --> 17:21.510 Następnym, o którym będziemy mówić, 17:21.510 --> 17:25.740 jest DMARC, a DMARC to raportowanie i zgodność uwierzytelniania 17:25.740 --> 17:28.410 wiadomości opartego na domenie. 17:28.410 --> 17:31.230 Jest to w zasadzie framework, który służy do zapewnienia 17:31.230 --> 17:32.430 prawidłowego stosowania 17:32.430 --> 17:33.870 SPF i DKIM przy użyciu polityki 17:33.870 --> 17:36.510 opublikowanej jako rekord DNS, co pokazałem 17:36.510 --> 17:39.240 bardzo krótko na ostatnim obrazku na ekranie, 17:39.240 --> 17:41.370 gdy pokazałem ci DMARC jako górną linię 17:41.370 --> 17:43.860 tego obrazka. 17:43.860 --> 17:45.630 Jeśli chcesz wrócić i przyjrzeć się temu, 17:45.630 --> 17:47.190 możesz to zrobić w tym momencie. 17:47.190 --> 17:48.690 Teraz, gdy masz do czynienia 17:48.690 --> 17:50.340 z DMARC, możesz użyć tego albo 17:50.340 --> 17:51.720 z SPF, z DKIM, albo używając 17:51.720 --> 17:55.890 obu, ponieważ pamiętaj, że SPF i DKIM nie muszą być używane razem. 17:55.890 --> 17:56.723 Możesz użyć jednego lub drugiego, 17:56.723 --> 17:58.830 lub możesz użyć obu, a DMARC będzie używany z jednym z nich lub z obydwoma. 17:58.830 --> 18:01.020 Teraz, gdy masz do czynienia 18:01.020 --> 18:03.867 z MARC, tak to wygląda. 18:03.867 --> 18:05.670 Jak to wszystko ze sobą współgra? 18:05.670 --> 18:07.050 Cóż, najpierw musisz upewnić się, że 18:07.050 --> 18:08.842 SPF, DKIM i DMARC znajdują się na serwerze DNS. 18:08.842 --> 18:12.180 Gdy masz już wszystkie te rekordy, 18:12.180 --> 18:15.720 rozpoczyna się cały proces. 18:15.720 --> 18:17.160 Teraz, gdy już raz to zrobisz, wszystko 18:17.160 --> 18:19.260 inne będzie następować za każdym razem, gdy chcesz 18:19.260 --> 18:20.321 wysłać wiadomość. 18:20.321 --> 18:22.320 W tym przykładzie będziemy mieć dwie wysyłane 18:22.320 --> 18:24.540 wiadomości, jedną z serwera SMTP, która jest autoryzowana 18:24.540 --> 18:27.270 i wyświetlana na zielono, a drugą od przeciwnika, który próbuje 18:27.270 --> 18:28.740 sfałszować twoją domenę, która będzie 18:28.740 --> 18:30.960 wyświetlana na czerwono. 18:30.960 --> 18:33.690 Zacznijmy od tego, który jest autoryzowany. 18:33.690 --> 18:35.280 Tutaj jest wymieniony jako 2A. 18:35.280 --> 18:37.350 Twój nadawca wyśle tę wiadomość do MTA. 18:37.350 --> 18:39.030 Trafia ona do MTA, czyli agenta 18:39.030 --> 18:42.510 przesyłania wiadomości, który ostatecznie przyjmuje 18:42.510 --> 18:45.630 tę wiadomość z nagłówkiem SPF lub DKIM. 18:45.630 --> 18:47.340 Pozostańmy przez chwilę przy tym przesłaniu, 18:47.340 --> 18:49.700 a następnie wrócimy do przeciwnika. 18:49.700 --> 18:51.810 Gdy MTA otrzyma tę wiadomość, przejrzy 18:51.810 --> 18:55.455 ją i przetworzy. 18:55.455 --> 18:57.840 Kiedy to robi, częścią tego będzie wyszukiwanie 18:57.840 --> 18:59.400 polityki DMARC nadawcy oraz rekordów 18:59.400 --> 19:02.100 SPF i DKIM za pośrednictwem DNS, tak jak rozmawialiśmy 19:02.100 --> 19:05.430 o tym w ciągu ostatnich trzech lub czterech minut. 19:05.430 --> 19:07.380 Teraz, gdy MTA to zrobi, jeśli jest to legalne, wiadomość 19:07.380 --> 19:09.330 ta może zostać umieszczona w skrzynce pocztowej 19:09.330 --> 19:12.570 odbiorcy na serwerze IMAP i czekać, aż dana osoba będzie mogła odczytać swoją wiadomość 19:12.570 --> 19:15.360 za pomocą swojego agenta użytkownika poczty. 19:15.360 --> 19:17.790 To wszystko jest dobre, ponieważ wiedzą, że ta wiadomość 19:17.790 --> 19:20.310 była autentyczna, ponieważ porównali te wartości z SPF, DKIM 19:20.310 --> 19:21.143 lub DMARC, w oparciu 19:21.143 --> 19:22.740 o skonfigurowaną politykę. 19:22.740 --> 19:25.897 Teraz, jeśli spojrzymy na przeciwnika z drugiej strony, kiedy wysyła 19:25.897 --> 19:29.370 wiadomość, nadal trafia ona do MTA, ponieważ musi dotrzeć do MTA, aby dotrzeć 19:29.370 --> 19:31.020 do użytkownika końcowego. 19:31.020 --> 19:33.205 Gdy jednak tam dotrze, MTA sprawdzi 19:33.205 --> 19:36.450 go pod kątem polityki DMARC, patrząc na rekordy SPF 19:36.450 --> 19:37.350 lub DKIM. 19:37.350 --> 19:40.110 Gdy to zrobi, jeśli nie będą pasować, odrzuci 19:40.110 --> 19:42.600 tę wiadomość, usunie ją lub podda kwarantannie 19:42.600 --> 19:45.990 i wyrzuci, jak widać w 5B. 19:45.990 --> 19:48.210 Ponownie, to jest sposób, w jaki te rzeczy działają, a używając 19:48.210 --> 19:50.010 DKIM, DMARC i SPF razem, możemy dodać trochę 19:50.010 --> 19:52.110 bezpieczeństwa do naszych organizacji. 19:52.110 --> 19:55.740 Na koniec mamy rekord NS, który oznacza 19:55.740 --> 19:58.910 rekord serwera nazw. 19:58.910 --> 20:01.320 Rekord serwera nazw służy do wskazania, 20:01.320 --> 20:03.600 który serwer DNS na świecie będzie autorytatywny 20:03.600 --> 20:05.730 dla danej domeny. 20:05.730 --> 20:08.550 Jest to ważne, ponieważ DNS wykorzystuje model hierarchiczny, 20:08.550 --> 20:11.220 o którym mówiliśmy, a wszystkie serwery muszą wiedzieć, 20:11.220 --> 20:14.160 kto jest właścicielem tego rekordu i jest upoważniony do 20:14.160 --> 20:16.620 wprowadzania w nim zmian. 20:16.620 --> 20:18.900 Serwer nazw to typ serwera DNS, który przechowuje 20:18.900 --> 20:20.550 wszystkie rekordy DNS dla danej domeny, 20:20.550 --> 20:22.855 w tym wszystkie typy, które już omówiliśmy, takie 20:22.855 --> 20:26.460 jak rekordy A, rekordy AAAA, kanoniczne rekordy nazw, rekordy wymiany poczty 20:26.460 --> 20:28.800 MX i rekordy tekstowe TXT. 20:28.800 --> 20:32.940 Często istnieje więcej niż jeden serwer nazw dla domeny, 20:32.940 --> 20:36.780 więc możesz mieć podstawowy i zapasowy serwer nazw. 20:36.780 --> 20:39.360 Dodatkowo, nie zawsze trzeba 20:39.360 --> 20:42.960 hostować własne serwery nazw. 20:42.960 --> 20:44.421 W przypadku diontraintraining. com, nie hostujemy własnych 20:44.421 --> 20:45.930 serwerów nazw. 20:45.930 --> 20:47.670 Zamiast tego polegamy na Cloudflare, 20:47.670 --> 20:49.410 który jest dostawcą usług w chmurze, który robi to za nas. 20:49.410 --> 20:51.540 Jeśli więc sprawdzisz rekordy DNS dla diontraining. com, wiarygodnym źródłem są dwa 20:51.540 --> 20:57.870 serwery nazw Cloudflare. 20:57.870 --> 20:59.880 Do tej pory mówiłem o DNS z perspektywy hostowania 20:59.880 --> 21:01.593 publicznie dostępnego serwera DNS, 21:02.490 --> 21:04.950 do którego każdy na świecie może uzyskać dostęp, ale DNS 21:04.950 --> 21:06.330 może być faktycznie używany wewnętrznie 21:06.330 --> 21:08.250 lub zewnętrznie. 21:08.250 --> 21:10.230 Wszystko, o czym mówiłem do tej 21:10.230 --> 21:14.100 pory, dotyczyło kwestii zewnętrznych, ale porozmawiajmy 21:14.100 --> 21:16.380 trochę o kwestiach wewnętrznych. 21:16.380 --> 21:18.900 W dzisiejszych czasach w chmurze obliczeniowej bardzo często 21:18.900 --> 21:20.460 konfiguruje się również wewnętrzną usługę 21:20.460 --> 21:22.140 DNS, która umożliwia instancjom chmury w 21:22.140 --> 21:25.590 tej samej sieci lub chmurze prywatnej dostęp do siebie nawzajem za pomocą wewnętrznych 21:25.590 --> 21:28.350 nazw DNS zamiast konieczności używania ich adresów IP. 21:28.350 --> 21:32.250 W tym celu tworzone są wewnętrzne rekordy A, a także 21:32.250 --> 21:34.950 wewnętrzne rekordy wskaźników w 21:34.950 --> 21:36.960 strefie odwrotnej. 21:36.960 --> 21:39.150 Na szczęście większość dostawców usług w chmurze 21:39.150 --> 21:40.740 automatycznie tworzy, aktualizuje 21:40.740 --> 21:43.980 i usuwa te wewnętrzne rekordy DNS podczas tworzenia i usuwania różnych maszyn 21:43.980 --> 21:46.800 wirtualnych i innych instancji w chmurze prywatnej. 21:46.800 --> 21:49.200 Zewnętrzny DNS jest jednak tym, z czym większość 21:49.200 --> 21:51.930 z nas będzie bardziej zaznajomiona. 21:51.930 --> 21:54.240 Są to rekordy tworzone wokół nazw domen, które 21:54.240 --> 21:55.710 kupujemy od centralnego organu 21:55.710 --> 21:56.940 i których używamy w publicznym 21:56.940 --> 21:58.830 Internecie. 21:58.830 --> 21:59.970 Teraz dla każdego rekordu DNS mamy również 21:59.970 --> 22:02.130 tak zwany TTL, czyli czas życia, który jest z nim powiązany. 22:02.130 --> 22:04.890 Czas życia to ustawienie, które mówi resolwerowi 22:04.890 --> 22:09.060 DNS, jak długo może buforować zapytanie przed zażądaniem nowego. 22:09.060 --> 22:12.060 Jeśli więc moje rekordy DNS są ustawione z czasem 22:12.060 --> 22:15.540 życia wynoszącym 86 400 sekund, co jest zwykle wartością 22:15.540 --> 22:18.390 domyślną, oznacza to, że mój komputer rozwiąże 22:18.390 --> 22:22.380 ten rekord DNS i zapamięta go przez 24 godziny, zanim będzie musiał 22:22.380 --> 22:25.410 wrócić do serwera DNS i ponownie poprosić o te 22:25.410 --> 22:27.720 informacje. 22:27.720 --> 22:30.090 Ten resolver DNS, znany również jako pamięć podręczna 22:30.090 --> 22:32.160 DNS, znajduje się na indywidualnym hoście. 22:32.160 --> 22:35.820 Jeśli na przykład korzystasz z systemu Windows 10, Twój komputer tworzy lokalną 22:35.820 --> 22:37.410 kopię każdego wpisu DNS, który rozwiązuje, 22:37.410 --> 22:39.870 gdy łączysz się ze stronami internetowymi w całym 22:39.870 --> 22:41.610 Internecie. 22:41.610 --> 22:43.409 Ta tymczasowa baza danych zapamiętuje 22:43.409 --> 22:46.680 odpowiedzi otrzymane z serwera DNS. 22:46.680 --> 22:49.410 Więc jeśli przejdziesz do diontraining. com, za pierwszym razem komputer musi zapytać 22:49.410 --> 22:50.940 serwer DNS o ten adres IP, 22:50.940 --> 22:52.980 ale teraz wie, gdzie 22:52.980 --> 22:54.630 się znajduje i pamięta ten 22:54.630 --> 22:57.720 adres IP przez następne 24 godziny. 22:57.720 --> 22:59.550 Jeśli dziś odwiedziłeś moją stronę 22:59.550 --> 23:02.370 pięć razy, musiałeś wyszukać ten adres IP tylko raz. 23:02.370 --> 23:04.620 Pomaga nam to przyspieszyć cały proces. 23:04.620 --> 23:07.110 Jeśli spróbujesz ponownie jutro, twój komputer 23:07.110 --> 23:09.660 najpierw sprawdzi pamięć podręczną DNS i zobaczy, 23:09.660 --> 23:11.010 że jest tam rekord. 23:11.010 --> 23:13.590 Ale jeśli ten czas życia już minął, unieważni 23:13.590 --> 23:15.270 ten rekord i wykona kolejne 23:15.270 --> 23:17.520 wyszukiwanie. 23:17.520 --> 23:19.050 Ostatnią rzeczą, którą musimy omówić, 23:19.050 --> 23:20.910 jest koncepcja rekursywnego wyszukiwania. 23:20.910 --> 23:23.100 Widzisz, kiedy twój komputer chce znaleźć daną stronę 23:23.100 --> 23:24.690 internetową, taką jak diontraining. com, musi najpierw zapytać swój 23:24.690 --> 23:26.400 serwer DNS, gdzie się znajduje. 23:26.400 --> 23:28.560 Jeśli więc siedzisz 23:28.560 --> 23:31.830 w domu i korzystasz na przykład z połączenia Verizon 23:31.830 --> 23:33.210 Fios, zapytasz ich serwer 23:33.210 --> 23:35.790 DNS: "Who's diontraining. com? Teraz DNS Verizon może znać adres 23:35.790 --> 23:37.597 IP diontraining lub 23:37.597 --> 23:39.510 nie. com. 23:39.510 --> 23:41.940 W końcu istnieją miliony witryn internetowych, a jeśli musieliby 23:41.940 --> 23:44.220 zsynchronizować nasze rekordy 23:44.220 --> 23:46.200 co 24 godziny, zajęłoby to dużo czasu. 23:46.200 --> 23:48.240 Zamiast tego DNS wykorzystuje 23:48.240 --> 23:51.900 strategię rekursywną do wyszukiwania. 23:51.900 --> 23:55.350 Więc pytasz Verizon, a jeśli nie znają odpowiedzi, przejdą na wyższy poziom i zapytają 23:55.350 --> 23:56.610 następny serwer DNS. 23:56.610 --> 23:59.850 Jeśli serwer nie zna odpowiedzi, przejdzie na wyższy poziom 23:59.850 --> 24:02.820 i będzie kontynuował ten proces, dopóki nie znajdzie 24:02.820 --> 24:05.520 kogoś, kto zna adres IP diontraining. 24:05.520 --> 24:05.520 com. 24:05.520 --> 24:07.654 Teraz, jeśli podczas tej rekurencji 24:07.654 --> 24:11.370 dotrze aż do . com lub domena trasy dla diontraining. com, wtedy może 24:11.370 --> 24:13.740 zapytać . com, który serwer DNS jest autorytatywny 24:13.740 --> 24:16.950 dla diontrain. com i uzyskać wiarygodną odpowiedź 24:16.950 --> 24:19.170 bezpośrednio od nich. 24:19.170 --> 24:22.530 Zasadniczo, w przypadku wyszukiwania 24:22.530 --> 24:25.320 rekursywnego, resolver DNS mówi: "Nie wiem, jaki jest 24:25.320 --> 24:27.090 adres IP tej domeny, ale zapytam mój 24:27.090 --> 24:28.777 serwer DNS, a ten serwer będzie 24:28.777 --> 24:30.870 go szukał, aż go znajdzie, a następnie 24:30.870 --> 24:32.910 poda mi ten adres IP. Teraz można użyć innej metody, 24:32.910 --> 24:35.310 która jest znana jako iteracyjne 24:35.310 --> 24:37.140 wyszukiwanie. 24:37.140 --> 24:38.760 W przypadku wyszukiwania iteracyjnego jest ono podobne 24:38.760 --> 24:40.620 do wyszukiwania rekurencyjnego, z tą różnicą, że serwer DNS 24:40.620 --> 24:43.530 nie będzie kontynuował wyszukiwania informacji dla użytkownika i wysyłania mu wyniku. 24:43.530 --> 24:45.929 Zamiast tego, w iteracyjnym wyszukiwaniu, 24:45.929 --> 24:48.840 resolver DNS zapyta serwer DNS o adres IP domeny, 24:48.840 --> 24:50.730 a jeśli serwer DNS nie będzie wiedział, 24:50.730 --> 24:53.550 powie resolverowi, aby zapytał następny serwer 24:53.550 --> 24:55.320 DNS, a ten serwer poda swój adres 24:55.320 --> 24:57.390 IP. 24:57.390 --> 25:00.390 W przypadku wyszukiwania rekursywnego, serwer DNS 25:00.390 --> 25:02.820 wyszuka go i zgłosi z powrotem do resolvera, 25:02.820 --> 25:04.800 ale w przypadku wyszukiwania iteracyjnego, 25:04.800 --> 25:06.510 twój resolver DNS będzie nieustannie 25:06.510 --> 25:09.390 wykonywał to zapytanie przez całą rekurencję, aż 25:09.390 --> 25:12.540 znajdzie ten z adresem IP dla tej domeny, więc tak naprawdę 25:12.540 --> 25:14.430 jest to tylko kwestia tego, kto szuka 25:14.430 --> 25:17.310 tych informacji. 25:17.310 --> 25:19.770 W porządku, omówiliśmy wiele informacji w tej 25:19.770 --> 25:20.909 lekcji, więc jako krótkie 25:20.909 --> 25:23.670 podsumowanie, co musisz wiedzieć na egzamin? 25:23.670 --> 25:26.220 Cóż, musisz zrozumieć, jak działa DNS, używając różnych 25:26.220 --> 25:28.260 typów rekordów do konwersji nazw domen na 25:28.260 --> 25:30.463 adresy IP i adresów IP na nazwy domen. 25:30.463 --> 25:33.690 Należy pamiętać, że rekordy A są używane dla nazw domen 25:33.690 --> 25:36.840 z adresami IPv4, podczas gdy rekordy AAAA są używane 25:36.840 --> 25:39.213 dla nazw domen z adresami IPV6. 25:39.213 --> 25:42.990 Rekordy CNAME służą do mapowania nazw 25:42.990 --> 25:45.840 domen na inne nazwy domen. 25:45.840 --> 25:48.030 Rekordy MX są używane dla poczty e-mail, a rekordy 25:48.030 --> 25:49.530 NS są używane dla serwerów nazw. 25:49.530 --> 25:51.450 Rekordy TXT przechowują tekst w postaci danych 25:51.450 --> 25:53.910 czytelnych dla człowieka lub danych czytelnych maszynowo. 25:53.910 --> 25:56.700 Jeśli zapamiętasz to podsumowanie, powinieneś być w stanie odpowiedzieć 25:56.700 --> 25:58.410 na większość pytań dotyczących DNS, które 25:58.410 --> 25:59.850 pojawią się na egzaminie.