Przeglądarka Chromium, dobrze prosperujący rodzic Google Chrome i nowej przeglądarki Microsoft Edge o otwartym kodzie źródłowym, spotkała się ze znaczącym negatywnym zainteresowaniem ze względu na funkcję zaprojektowaną w dobrych intencjach: sprawdza, czy dostawca usług internetowych użytkownika „kradnie” wyniki zapytań o nieistniejącą domenę .
, która tworzy fałszywe zapytania o losowe „domen”, których istnienie jest statystycznie mało prawdopodobne, odpowiada za około połowę całkowitego ruchu odbieranego przez główne serwery DNS na całym świecie. Inżynier Verisign, Matt Thomas, napisał obszerny opis na blogu APNIC opisującym problem i oceniającym jego skalę.
Jak zwykle wykonywane jest rozpoznawanie DNS
Serwery te są najwyższymi organami, z którymi należy się skontaktować w celu rozwiązania nazw .com, .net itp. i poinformują Cię, że frglxrtmpuf nie jest domeną najwyższego poziomu (TLD).
DNS, czyli Domain Name System, to system, za pomocą którego komputery mogą przekształcać zapadające w pamięć nazwy domen, takie jak arstechnica.com, na znacznie mniej dogodne adresy IP, takie jak 3.128.236.93. Bez DNS Internet nie istniałby w sposób użyteczny dla człowieka, co oznacza, że niepotrzebnym obciążeniem infrastruktury wyższego poziomu jest realny problem.
Załadowanie pojedynczej nowoczesnej strony internetowej może wymagać niesamowitej liczby wyszukiwań DNS. Na przykład, analizując stronę główną ESPN, naliczyliśmy 93 oddzielne nazwy domen, od a.espncdn.com do z.motads.com. Wszystkie są niezbędne do pełnego załadowania strony!
Aby sprostać tego typu obciążeniom wyszukiwarki, która musi obsługiwać cały świat, system DNS zaprojektowano jako wielopoziomową hierarchię. Na szczycie tej piramidy znajdują się serwery główne — każda domena najwyższego poziomu, taka jak .com, ma własną rodzinę serwerów, które mają najwyższy autorytet dla każdej domeny znajdującej się poniżej. Jeden krok w górę z nich serwery są same serwery główne, z a.root-servers.net do m.root-servers.net.
Jak często się to zdarza?
Dzięki wielopoziomowej hierarchii buforowania infrastruktury DNS bardzo niewielki procent zapytań DNS na świecie dociera do serwerów głównych. Większość ludzi otrzymuje informacje o programie rozpoznawania nazw DNS bezpośrednio od swojego dostawcy usług internetowych. Kiedy urządzenie użytkownika musi wiedzieć, jak dostać się do określonej witryny internetowej, najpierw wysyłane jest żądanie do serwera DNS zarządzanego przez tego lokalnego dostawcę. Jeśli lokalny serwer DNS nie zna odpowiedzi, przekazuje żądanie do swoich „przesyłaczy” (jeśli zostały określone).
Jeśli ani serwer DNS lokalnego dostawcy, ani „serwery przekazujące” określone w jego konfiguracji nie mają odpowiedzi w pamięci podręcznej, żądanie jest kierowane bezpośrednio do autorytatywnego serwera domeny powyżej ten, który próbujesz przekonwertować. Gdy домен.com będzie to oznaczać, że żądanie zostanie wysłane do autorytatywnych serwerów samej domeny com, które znajdują się przy ul gtld-servers.net.
System gtld-servers, do którego skierowano żądanie, odpowiada listą wiarygodnych serwerów nazw dla domeny domain.com, a także co najmniej jednym rekordem łącza zawierającym adres IP jednego z takich serwerów nazw. Następnie odpowiedzi przechodzą w dół łańcucha — każdy spedytor przekazuje je serwerowi, który ich zażądał, aż w końcu odpowiedź dotrze do serwera lokalnego dostawcy i komputera użytkownika. Wszystkie buforują tę odpowiedź, aby niepotrzebnie nie zakłócać systemów wyższego poziomu.
W większości przypadków serwer nazw rekordy dla domena.com będzie już buforowany na jednym z tych usług przesyłania dalej, więc serwery główne nie będą zakłócane. Na razie jednak mówimy o znanym nam typie adresu URL – takim, który konwertowany jest na zwykłą stronę internetową. Żądania Chrome są na poziomie powyżej to na stopniu samych klastrów root-servers.net.
Kontrola kradzieży Chromium i NXDomain
Chromium sprawdza „czy ten serwer DNS mnie oszukuje?” odpowiadają za prawie połowę całego ruchu docierającego do klastra głównych serwerów DNS firmy Verisign.
Przeglądarka Chromium, projekt macierzysty Google Chrome, nowego Microsoft Edge i niezliczonych mniej znanych przeglądarek, chce zapewnić użytkownikom łatwość wyszukiwania w jednym polu, czasami nazywanym „Omniboksem”. Innymi słowy, użytkownik wprowadza zarówno prawdziwe adresy URL, jak i zapytania wyszukiwarki w tym samym polu tekstowym u góry okna przeglądarki. Robiąc kolejny krok w stronę uproszczenia, nie wymusza również na użytkowniku wpisywania części adresu URL http:// lub https://.
Choć jest to wygodne, podejście to wymaga od przeglądarki zrozumienia, co należy uznać za adres URL, a co za wyszukiwane hasło. W większości przypadków jest to dość oczywiste – na przykład ciąg znaków ze spacjami nie może być adresem URL. Sprawa może się jednak skomplikować, jeśli weźmiemy pod uwagę intranety — sieci prywatne, które mogą również korzystać z prywatnych domen najwyższego poziomu do rozpoznawania prawdziwych witryn internetowych.
Jeśli użytkownik w intranecie swojej firmy wpisze „marketing”, a intranet firmy ma wewnętrzną witrynę internetową o tej samej nazwie, Chromium wyświetli okno informacyjne z pytaniem, czy chce wyszukać „marketing”, czy przejść do https://marketing. Być może tak nie jest, ale wielu dostawców usług internetowych i publicznych dostawców Wi-Fi „przechwytuje” każdy błędnie napisany adres URL, przekierowując użytkownika na stronę wypełnioną banerami.
Losowe pokolenie
Twórcy Chromium nie chcieli, aby użytkownicy zwykłych sieci widzieli okno informacyjne z pytaniem, co mają na myśli za każdym razem, gdy szukają pojedynczego słowa, więc wdrożyli test: po uruchomieniu przeglądarki lub zmianie sieci Chromium sprawdza DNS na trzech losowo generowane „domeny” najwyższego poziomu, o długości od siedmiu do piętnastu znaków. Jeśli dowolne dwa z tych żądań powrócą z tym samym adresem IP, Chromium zakłada, że sieć lokalna „przechwytuje” błędy NXDOMAIN, które powinna otrzymać, dzięki czemu przeglądarka do odwołania uzna wszystkie wprowadzone zapytania składające się z pojedynczych słów za próby wyszukiwania.
Niestety w sieciach, które nie kraść wyniki zapytań DNS, te trzy operacje zwykle prowadzą na samą górę, aż do samych głównych serwerów nazw: serwer lokalny nie wie, jak rozwiązać qwajuixk, więc przekazuje to żądanie swojemu spedytorowi, który robi to samo, aż w końcu a.root-servers.net ani jeden z jego „braci” nie będzie zmuszony powiedzieć „Przykro mi, ale to nie ta domena”.
Ponieważ istnieje około 1,67*10^21 możliwych fałszywych nazw domen o długości od siedmiu do piętnastu znaków, najczęstszą każdy z tych testów przeprowadzonych w „uczciwej” sieci trafia do serwera root. To tyle połowa od całkowitego obciążenia głównego DNS, według statystyk z tej części klastrów root-servers.net, których właścicielem jest Verisign.
Historia się powtarza
To nie pierwszy raz, kiedy projekt tworzony jest z najlepszymi intencjami lub prawie zalał zasoby publiczne niepotrzebnym ruchem - od razu przypomniało nam to długą i smutną historię serwera NTP (Network Time Protocol) firmy D-Link i Poul-Henning Kamp z połowy 2000 roku.
W 2005 roku programista FreeBSD Poul-Henning, który był także właścicielem jedynego w Danii serwera Stratum 1 Network Time Protocol, otrzymał nieoczekiwany i duży rachunek za przesyłany ruch. Krótko mówiąc, powodem było to, że programiści D-Link zapisali adresy serwerów Stratum 1 NTP, w tym serwera Kampa, w oprogramowaniu firmowej linii przełączników, routerów i punktów dostępowych. To natychmiast zwiększyło ruch na serwerach Kampy dziewięciokrotnie, co spowodowało, że duńska giełda internetowa (duński punkt wymiany Internetu) zmieniła swoją taryfę z „bezpłatnej” na „9 dolarów rocznie”.
Problemem nie było to, że było zbyt wiele routerów D-Link, ale to, że były one „nie w linii”. Podobnie jak DNS, NTP musi działać w formie hierarchicznej - serwery warstwy 0 przekazują informacje do serwerów warstwy 1, które przekazują informacje do serwerów warstwy 2 i tak dalej w dół hierarchii. Typowy domowy router, przełącznik lub punkt dostępowy, taki jak ten, który D-Link zaprogramował z adresami serwera NTP, wysyłałby żądania do serwera Stratum 2 lub Stratum 3.
Projekt Chromium, prawdopodobnie mając najlepsze intencje, odtworzył problem NTP w problemie DNS, ładując internetowe serwery główne żądaniami, które nigdy nie były przeznaczone do obsługi.
Jest nadzieja na szybkie rozwiązanie
Projekt Chromium ma otwarte źródło , co wymaga domyślnego wyłączenia Detektora przekierowań intranetowych, aby rozwiązać ten problem. Musimy przyznać zasługę projektowi Chromium: znaleziono błąd przed tymjak Matt Thomas z Verisign zwrócił na niego wiele uwagi swoimi zdjęciami na blogu APNIC. Błąd został odkryty w czerwcu, ale pozostał zapomniany aż do postu Thomasa; Po poście zaczął być pod ścisłym nadzorem.
Mamy nadzieję, że problem zostanie wkrótce rozwiązany, a główne serwery DNS nie będą już musiały odpowiadać na szacunkowo 60 miliardów fałszywych zapytań każdego dnia.
O prawach reklamy
Epickie serwery - jest lub Linux z wydajnymi procesorami z rodziny AMD EPYC i bardzo szybkimi dyskami Intel NVMe. Pośpiesz się z zamówieniem!
Źródło: www.habr.com