Браузер Chromium, що активно розвивається open-source-батько Google Chrome і нового Microsoft Edge, звернув на себе серйозну негативну увагу через функцію, яка замислювалася з добрими намірами: вона перевіряє, чи не «викрадає» провайдер користувача неіснуючі результати запитів доменів.
, що створює підроблені запити випадкових «доменів», існування яких статистично малоймовірне, відповідальний приблизно половину загального трафіку, одержуваного кореневими DNS-серверами у світі. Інженер Verisign Метт Томас написав розлогий у блозі APNIC з описом проблеми та оцінкою її масштабу.
Як зазвичай виконується DNS-перетворення
Ці сервери є вищою інстанцією, до якої слід звертатися для резолвінгу .com,.
DNS, або Domain Name System («система доменних імен») - це система, завдяки якій комп'ютери можуть перетворювати пам'ятні доменні на зразок arstechnica.com в набагато менш зручні IP-адреси, наприклад 3.128.236.93. Без DNS Інтернет не міг би існувати у придатному для людей вигляді, отже, непотрібне навантаження на інфраструктуру верхнього рівня є реальною проблемою.
Для завантаження єдиної сучасної веб-сторінки може знадобитися неймовірна кількість операцій DNS-пошуку. Наприклад, коли ми аналізували головну сторінку ESPN, нарахували 93 окремих доменних імені, від a.espncdn.com до z.motads.com. Всі вони потрібні для повного завантаження сторінки!
Щоб таке навантаження могла витримувати система пошуку, яку необхідно обслуговувати весь світ, DNS спроектована як багаторівнева ієрархія. На вершині цієї піраміди знаходяться кореневі сервери — кожен домен верхнього рівня, наприклад, .com, має власну родину серверів, які є вищою інстанцією для кожного домену нижче за них. Однією сходинкою вище цих серверів знаходяться самі кореневі сервери, a.root-servers.net до m.root-servers.net.
Як часто це відбувається?
Завдяки багаторівневій ієрархії кешування інфраструктури DNS кореневих серверів досягає дуже малий відсоток світових DNS-запитів. Більшість людей одержують інформацію DNS-резолвера безпосередньо від свого провайдера. Коли пристрій користувача повинен дізнатися, як потрапити на певний сайт, запит спочатку надсилається DNS-серверу, керованому цим локальним провайдером. Якщо локальний DNS-сервер не знає відповіді, він перенаправляє запит власним «серверам пересилання» (якщо вони вказані).
Якщо ні DNS-сервер локального провайдера, ні задані в його конфігурації «сервери пересилання» не мають кешованої відповіді, запит піднімається безпосередньо до повноважного сервера домену вище того, що ви намагаєтеся перетворити. В разі домен.com це означатиме, що запит надсилається до повноважних серверів самого домену com, що знаходяться за адресою gtld-servers.net.
Система gtld-servers, до якої був запит, відповідає на нього списком повноважних серверів імен для домену домен.com, а також як мінімум одним сполучним записом, що містить IP-адресу одного такого сервера імен. Далі відповіді спускаються ланцюжком — кожен сервер пересилання передає ці відповіді вниз тому серверу, який їх запитував, поки відповідь нарешті не досягне сервера локального провайдера та комп'ютера користувача. Всі вони при цьому кешують цю відповідь, щоб без необхідності не турбувати системи верхнього рівня.
Найчастіше записи серверів імен для домен.com вже будуть кешовані на одному з цих серверів пересилання, тому кореневі сервери ніхто не турбує. Однак поки що ми говоримо про звичний нам вид URL - той, який перетворюється на звичайний веб-сайт. Запити Chrome належать до рівня вище цього, на сходинці самих кластерів root-servers.net.
Chromium та перевірка викрадення NXDomain
Перевірки Chromium «цей DNS-сервер мене не дурить?» становлять майже половину всього трафіку, що досягає кластера кореневих DNS-серверів Verisign.
Браузер Chromium, батьківський проект Google Chrome, нового Microsoft Edge та незліченної кількості менш відомих браузерів, хоче забезпечити користувачам простоту пошуку в одному полі, що іноді називається «Omnibox». Іншими словами, користувач вводить і реальні URL, і запити до пошукового движка в те саме текстове поле у верхній частині вікна браузера. Роблячи ще один крок до спрощення, він також не змушує користувача вводити частину URL з http:// або https://.
Як би це зручно не було, такий підхід вимагає, щоб браузер зрозумів, що потрібно вважати URL, а що — пошуковим запитом. Найчастіше це досить очевидно — наприклад, рядок із пробілами може бути URL. Але все може бути хитрішим, якщо врахувати інтранети — приватні мережі, які можуть також використовувати приватні домени верхнього рівня для резолвінгу цих веб-сайтів.
Якщо користувач в інтранеті своєї компанії вводить «marketing», а в інтранеті компанії є внутрішній веб-сайт з такою ж назвою, Chromium відображає інформаційне вікно, яке запитує користувача, чи хоче він шукати «marketing», або перейти до https://marketing. Це ще куди не йшло, але багато провайдерів Інтернету та провайдери спільних мереж Wi-Fi «викрадають» кожен введений з друкарською URL-адресою, перенаправляючи користувача на якусь напхану рекламними банерами сторінку.
Випадкова генерація
Розробники Chromium не хотіли, щоб користувачі у звичайних мережах при кожному пошуку одного слова бачили інформаційне вікно, яке запитало, що ті мали на увазі, тому вони реалізували тест: при запуску браузера або зміні мережі Chromium виконує операції DNS-пошуку трьох випадково згенерованих «доменів» верхнього рівня довжиною від XNUMX до XNUMX символів. Якщо будь-які два з цих запитів повертаються з однаковою IP-адресою, Chromium передбачає, що локальна мережа «викрадає» помилки NXDOMAIN, які він повинен отримувати, тому браузер до подальшого повідомлення рахує всі введені запити з одного слова спробами пошуку.
На жаль, у мережах, які НЕ викрадають результати DNS-запитів, ці три операції зазвичай піднімаються на верх, до самих кореневих серверів імен: локальний сервер не знає, як перетворити qwajuixk, тому перекидає цей запит своєму серверу пересилання, який робить те саме, поки, нарешті, a.root-servers.net або один із його «братів» не буде змушений сказати «Вибачте, але це не домен».
Так як існує приблизно 1,67 * 10 ^ 21 можливих фальшивих доменних імен довжиною від семи до п'ятнадцяти символів, найчастіше кожен з цих тестів, виконаних у «чесній» мережі, дістається кореневого сервера. Це складає аж половину від загального навантаження на кореневі DNS, якщо вірити статистиці від частини кластерів root-servers.net, що належать компанії Verisign.
Історія повторюється
Це не перший випадок, коли створений із найкращими намірами проект або мало не завалював громадський ресурс необов'язковим трафіком — нам це одразу ж нагадало довгу та сумну історію D-Link та NTP-сервера (Network Time Protocol) Поуля-Хеннінга Кампа середини 2000-х.
У 2005 році розробник FreeBSD Поуль-Хеннінг, який володів також єдиним у Данії сервером Network Time Protocol рівня Stratum 1, отримав несподіваний і великий рахунок за трафік. Якщо стисло, то причина полягала в тому, що розробники D-Link прописали адреси NTP-серверів Stratum 1, у тому числі і сервера Кампа, в прошивку лінійки комутаторів, маршрутизаторів і точок доступу компанії. Це миттєво підвищило у дев'ять разів трафік сервера Кампа, через що Danish Internet Exchange (точка обміну Інтернет-трафіком Данії) змінила його тариф із «Безкоштовного» на «9 000 доларів на рік».
Проблема полягала не в тому, що маршрутизаторів D-Link було надто багато, а в тому, що вони порушували субординацію. Майже як і DNS, NTP повинні працювати в ієрархічній формі - сервери рівня Stratum 0 передають інформацію серверам Stratum 1, які передають інформацію серверам Stratum 2 і так далі вниз по ієрархії. Звичайний домашній маршрутизатор, комутатор або точка доступу на кшталт тих, які D-Link прошила адреси NTP-серверів, мали надсилати запити серверу Stratum 2 чи Stratum 3.
Проект Chromium, ймовірно, маючи найкращі наміри, повторив проблему з NTP у проблемі з DNS, завантаживши кореневі сервери Інтернету запитами, які вони ніколи не повинні були обробляти.
Надія на швидке рішення є
У проекті Chromium є відкритий , що вимагає усунення цієї проблеми відключення за промовчанням Intranet Redirect Detector. Потрібно віддати належне проекту Chromium: баг було знайдено до того, як Метт Томас з Verisign привернув до нього величезну увагу своїм у блозі APNIC. Баг був відкритий у червні, але залишався в забутті до посту Томаса; після поста він почав перебувати під чуйним наглядом.
Є надія, що проблему незабаром буде вирішено, і кореневим DNS-серверам більше не доведеться відповідати щодня на приблизно 60 мільярдів фіктивних запитів.
На правах реклами
Епічні сервери - це або Linux з потужними процесорами сімейства AMD EPYC та дуже швидкими NVMe дисками Intel. Поспішайте замовити!
Джерело: habr.com