Przeglądarka Chromium, przedsięwzięcie open-source rozwijane przez Google jako rodzic Google Chrome oraz nowego Microsoft Edge, zwróciła na siebie poważną negatywną uwagę z powodu funkcji, która miała dobre intencje: sprawdza, czy dostawca nie 'kradnie' wyników zapytań domen, które nie istnieją.
, powodując fałszywe zapytania do losowych 'domen', które statystycznie są mało prawdopodobne, odpowiada za około połowę całego ruchu trafiającego do głównych serwerów DNS na całym świecie. Inżynier Verisign, Matt Thomas, napisał obszerny w blogu APNIC na temat problemu i oceny jego skali.
Jak zazwyczaj przeprowadza się konwersję DNS
Te serwery są najwyższą instancją, do której należy się zgłaszać w celu rozwiązywania .com, .net itd., aby poinformowały cię, że frglxrtmpuf nie jest domeną najwyższego poziomu (TLD).
DNS, czyli System Nazw Domenowych, to system, który pozwala komputerom przekształcać zapamiętywalne nazwy domen, takie jak arstechnica.com, w znacznie mniej wygodne adresy IP, na przykład 3.128.236.93. Bez DNS Internet nie mógłby istnieć w formie zrozumiałej dla ludzi, a więc niepotrzebne obciążenie infrastruktury najwyższego poziomu stanowi rzeczywisty problem.
Aby załadować jedną współczesną stronę internetową, może być potrzebna niewyobrażalna liczba operacji wyszukiwania DNS. Na przykład, gdy analizowaliśmy stronę główną ESPN, zliczyliśmy 93 oddzielne nazwy domen, od a.espncdn.com po z.motads.com. Wszystkie te nazwy są potrzebne, aby strona w pełni się załadowała!
Aby system wyszukiwania mógł wytrzymać takie obciążenie, które musi obsługiwać cały świat, DNS jest zaprojektowany jako hierarchia wielopoziomowa. Na szczycie tej piramidy znajdują się serwery główne - każda domena najwyższego poziomu, taka jak .com, ma swoją własną rodzinę serwerów, które są najwyższą instancją dla każdej domeny poniżej nich. Jednym poziomem wyżej tych serwerów znajdują się same serwery główne, od a.root-servers.net do m.root-servers.net.
Jak często to się zdarza?
Dzięki wielowarstwowej hierarchii pamięci podręcznej infrastruktury DNS, do serwerów głównych dociera bardzo mały procent globalnych zapytań DNS. Większość ludzi uzyskuje informacje z rozwiązywacza DNS bezpośrednio od swojego dostawcy. Kiedy urządzenie użytkownika musi dowiedzieć się, jak dotrzeć do określonej strony internetowej, zapytanie jest najpierw wysyłane do serwera DNS zarządzanego przez tego lokalnego dostawcę. Jeśli lokalny serwer DNS nie zna odpowiedzi, przekazuje zapytanie do własnych „serwerów przekazywania” (o ile są one wskazane).
Jeśli ani serwer DNS lokalnego dostawcy, ani podane w jego konfiguracji „serwery przekazywania” nie mają zbuforowanej odpowiedzi, zapytanie jest kierowane bezpośrednio do autorytatywnego serwera domeny powyżej której chcesz dokonać konwersji. W przypadku domeny.com oznacza to, że zapytanie jest wysyłane do autorytatywnych serwerów samej domeny com, które znajdują się pod adresem gtld-servers.net.
System gtld-servers, na które wysłano zapytanie, odpowiada listą autorytatywnych serwerów nazw dla domeny domena.com oraz przynajmniej jednym rekordem powiązanym, zawierającym adres IP jednego z tych serwerów nazw. Następnie odpowiedzi są przekazywane w dół łańcucha — każdy serwer przekazywania przesyła te odpowiedzi do serwera, który je zapytał, aż odpowiedź w końcu dotrze do serwera lokalnego dostawcy i komputera użytkownika. Wszystkie one przechowują tę odpowiedź w pamięci podręcznej, aby nie martwić systemów wyższego poziomu bez potrzeby.
W większości przypadków rekordy serwerów nazw dla domeny.com będą już zbuforowane na jednym z tych serwerów przekazywania, więc nikt nie niepokoji serwerów głównych. Jednak gdy mówimy o znanym nam typie URL — takim, który jest konwertowany na zwykłą stronę internetową. Zapytania Chrome dotyczą poziomu powyżej tego, na poziomie samych klastrów root-servers.net.
Chromium oraz weryfikacja przejęcia NXDomain
Weryfikacje Chromium „ten serwer DNS mnie nie oszukuje?” stanowią prawie połowę całego ruchu docierającego do klastra głównych serwerów DNS Verisign.
Przeglądarka Chromium, projekt macierzysty Google Chrome, nowego Microsoft Edge i niezliczonej liczby mniej znanych przeglądarek, ma na celu zapewnienie użytkownikom łatwości wyszukiwania w jednym polu, czasami nazywanym „Omnibox”. Innymi słowy, użytkownik wpisuje zarówno rzeczywiste adresy URL, jak i zapytania do wyszukiwarki w to samo pole tekstowe na górze okna przeglądarki. Uproszczając jeszcze bardziej, nie wymaga od użytkownika wpisywania części adresu URL z http:// lub https://.
Jak wygodne by to nie było, takie podejście wymaga, aby przeglądarka zrozumiała, co należy uznać za adres URL, a co za zapytanie wyszukiwania. W większości przypadków jest to dość oczywiste — na przykład ciąg z spacjami nie może być adresem URL. Ale wszystko może być bardziej skomplikowane, gdy uwzględnimy intranety — prywatne sieci, które mogą także korzystać z prywatnych domen najwyższego poziomu do rozwiązywania prawdziwych witryn internetowych.
Jeśli użytkownik w intranecie swojej firmy wpisuje „marketing”, a w intranecie firmy istnieje wewnętrzna witryna o tej samej nazwie, to Chromium wyświetla okno informacyjne, pytające użytkownika, czy chce szukać „marketing”, czy przejść do https://marketing. To tyle dobrze, ale wielu dostawców Internetu i dostawcy ogólnodostępnych sieci Wi-Fi „kradnie” każdy wprowadzony z literówką adres URL, przekierowując użytkownika na jakąś napakowaną reklamami stronę.
Losowe generowanie
Twórcy Chromium nie chcieli, aby użytkownicy w zwykłych sieciach przy każdym wyszukiwaniu jednego słowa widzieli okno informacyjne pytające, co mieli na myśli, dlatego wprowadzili test: podczas uruchamiania przeglądarki lub zmiany sieci, Chromium wykonuje zapytania DNS dla trzech losowo wygenerowanych „domen” najwyższego poziomu o długości od siedmiu do piętnastu znaków. Jeśli jakiekolwiek dwa z tych zapytań zwrócą ten sam adres IP, to Chromium zakłada, że lokalna sieć „kradnie” błędy NXDOMAIN, które powinien otrzymywać, więc przeglądarka do dalszego powiadomienia uważa wszystkie wprowadzane zapytania składające się z jednego słowa za próby wyszukiwania.
Niestety, w sieciach, które nie kradną wyniki zapytań DNS, te trzy operacje zazwyczaj są podnoszone na sam szczyt, do samych podstawowych serwerów nazw: lokalny serwer nie wie, jak przekształcić qwajuixk, dlatego przesyła to zapytanie do swojego serwera przekazywania, który robi to samo, aż ostatecznie, a.root-servers.net lub jeden z jego „braci” nie będzie musiał powiedzieć „Przykro mi, ale to nie jest 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ęściej każde z tych testów, przeprowadzonych w „uczciwej” sieci, dociera do serwera głównego. To stanowi aż połowę całkowitego obciążenia głównych DNS, jeśli wierzyć statystykom z tej części klastrów root-servers.net, które należą do firmy Verisign.
Historia się powtarza
To nie pierwszy przypadek, kiedy stworzony z najlepszymi intencjami projekt lub ledwie nie zawalił publicznego zasobu niepotrzebnym ruchem — od razu przypomniało nam to długą i smutną historię D-Linka i serwera NTP (Network Time Protocol) Poul-Henninga Kampa z połowy lat 2000.
W 2005 roku programista FreeBSD Poul-Henning, który również posiadał jedyny w Danii serwer Network Time Protocol poziomu Stratum 1, otrzymał niespodziewany i duży rachunek za przesłany ruch. Krótko mówiąc, powodem było to, że programiści D-Linka zapisali adresy serwerów NTP poziomu Stratum 1, w tym serwera Kampa, w oprogramowaniu linii switchy, routerów i punktów dostępu firmy. Natychmiast zwiększyło to ruch serwera Kampa dziewięciokrotnie, co spowodowało, że Danish Internet Exchange (punkt wymiany ruchu internetowego w Danii) zmienił jego taryfę z „Bezpłatnej” na „9000 dolarów rocznie”.
Problem nie leżał w tym, że routerów D-Link było za dużo, ale w tym, że „łamały subordynację”. Tak jak w przypadku DNS, NTP również powinno działać w hierarchicznej formie — serwery poziomu Stratum 0 przekazują informacje serwerom Stratum 1, które przekazują informacje serwerom Stratum 2, i tak dalej, w dół hierarchii. Zwykły domowy router, switch lub punkt dostępu, jak te, w które D-Link wprowadził adresy serwerów NTP, powinien wysyłać zapytania do serwerów Stratum 2 lub Stratum 3.
Projekt Chromium, prawdopodobnie mając na celu najlepsze intencje, powtórzył problem z NTP w kwestii DNS, obciążając główne serwery Internetu zapytaniami, których nigdy nie powinny były przetwarzać.
Jest nadzieja na szybkie rozwiązanie
W projekcie Chromium jest otwarty , wymagający wyłączenia domyślnego Intranet Redirect Detector, aby rozwiązać ten problem. Należy oddać hołd projektowi Chromium: błąd został znaleziony wcześniej, kiedy Matt Thomas z Verisign przyciągnął do niego ogromną uwagę swoim na blogu APNIC. Błąd został zgłoszony w czerwcu, ale pozostał w zapomnieniu do postu Thomasa; po jego publikacji zaczął być bacznie obserwowany.
Jest nadzieja, że problem wkrótce zostanie rozwiązany i serwery DNS na poziomie root nie będą musiały codziennie odpowiadać na około 60 miliardów fałszywych zapytań.
Reklama
Epickie serwery — to lub Linux z potężnymi procesorami z rodziny AMD EPYC i bardzo szybkim dyskiem NVMe Intel. Nie zwlekaj, zamów już teraz!
Źródło: habr.com
