#DNS

🕸️📖👈 Що я вам скажу — не раджу підіймати свій DNS.

Принаймні, не рекурсивний. Річ у тім, що DNS - вкрай езотерична технологія. І хоч ми всі їй користуємося постійно, мабуть, мало хто здогадується, що таке рекурсивний DNS, і який ще буває.

Так от, DNS це насправді дві роздільні системи.

Перша — це, грубо кажучи, дерево DNS-серверів, які зберігають адреси сайтів. А саме, є кореневі сервера, що знають адреси DNS-серверів доменів верхнього рівня (.org). Далі у домену .org є свої сервери, які знають адреси DNS-серверів всіх доменів .org - наприклад, .telegram.org. Зазвичай DNS-сервер домену другого рівня скаже вам адресу самого сайту та його піддоменів. Але не завжди — бо глибина дерева технічно не обмежена. (До речі, самі DNS-сервера вказуються у вигляді доменів, а не IP-адрес. Мені це здається зациклюванням, але ж якось воно працює. Таємниця!)

Тепер, щоб знайти адресу будь-якого сайту, треба погуляти по дереву DNS, починаючи з кореня, спитати у всіх серверів по ціпочці, і нарешті адреса буде знайдена. Це й називається рекурсивний DNS. Проблема в тому, що це повільно і може займати навіть секунди, а деколи десятки секунд. Залежить від конкретних серверів, які взагалі можуть бути недоступними.

Через повільність і ненадійність такої системи DNS існує друга. Це кешуючі DNS сервера, які зберігають результати запитів та віддають їх моментально. Часто вони теж не роблять рекурсивний пошук, а питають в інших. Так робить DNS-сервер на вашому пристрої (бо звісно, є й такий!), на роутері, у провайдера.

А є ще публічні кешуючі DNS сервери, наприклад, 1.1.1.1 від Cloudflare. Їх користь в тому, що вони працюють “нормально”. Бо протокол DNS складний і неоднозначний, і в деяких історичних ситуаціях “нормальні” сервери роблять не так, як написано. (Принаймні, це я так розумію.)

Ми спробували підіймати рекурсивний DNS сервер Unbound. Він дуже класний, але він жорстко слідкує за стандартом, а це “ненормально”, тобто інколи результати не збігаються з очікуваннями, і пояснити, чому, нелегко. Після численних проблем повернулись до DNS від Cloudflare.

Якщо хочеться почитати про DNS більше, раджу чудовий блог Джулії Еванс.

Якщо ваша бізнес-логіка спирається на DNS, то цілком логічно мати тестове середовище, де DNS контрольований. Тоді можна перевірити різні випадки — який запис є, якого немає, що за значення повертає і так далі. Але, DNS здається таким глибоко системним сервісом, що торкатись його здається неможливо (хіба що /etc/hosts міняти, але то дуже обмежено.)

Насправді зробити свій DNS-сервер досить нескладно; принаймні на Go для цього є проста бібліотека, з якої можна зібрати свій простий сервер (ось приклад). Все, що вам потрібно — це приймати деякі DNS запити та відповідати на них; решту можна або не обробляти, або передавати іншому серверу (як 99.9% DNS серверів в інтернеті й роблять.)

Я колись давно робив сервер, що перекриває DNS записи за розкладом. Така була міра обмеження відволікань. Досить ефективно працює, до речі — особливо якщо не зробиш можливість вимкнути. Бо пізніше я перейшов на більш функціональний Pi-hole, так от там вже можна було припинити блокування через вебінтерфейс. А зараз взагалі цього не роблю.

Залишається, щоправда, останнє питання — як підʼєднати той сервер до вашої тестової системи? Тут проблема, бо системний клієнт DNS не дасть поміняти порт, до якого він буде звертатись — домен чи IP - будь ласка, а порт тільки системний. Я так розумію, що то заради безпеки, хоча хтозна. В інших клієнтах можна вказати порт — наприклад, dig -p 5353, або якщо клієнт на Ruby.

Якщо ж треба саме замінити саме системний DNS, то заміну доведеться розташувати в Докері; тоді можна відкрити стандартний DNS порт (а це 53, до речі). Взагалі я б такі тести тільки в Докері й робив би; створюєш собі docker-compose на всі сервіси та тестуєш в повній ізоляції.

Якщо тобі доводилось додавати домен до якогось SaaS, будь то Heroku, Firebase, Cloudflare, і так далі — то ти, напевно, знаєш, що для підтвердження власності треба додати DNS запис. А потім зазвичай довго чекати, поки SaaS його перевірить. Деколи це займає хвилини, а деколи прямо кажуть приходити завтра.

DNS - протокол, яким ми користуємось постійно, без нього неможливо вийти в Інтернет. Однак коли ти відкриваєш сайт, то чомусь отримуєш адресу миттєво, а не завтра. Чому ж тоді верифікація домену це такий довгий процес?

Винний, як завжди, кеш. Поняття кешу закладене в основу протоколу DNS. Чому так? Бо записи DNS не сидять всі на одному сервері. Як я вже писав, пошук адреси в DNS - процес рекурсивний — рухаючись від центральних вузлів Інтернету до більш детальних серверів, аж допоки не знайде конкретний запис. Робити так щоразу дуже витратно, бо будь-який з серверів на шляху може бути повільним чи навіть недоступним. Тому проміжні та кінцеві результати пошуку DNS кешуються. Коли створюєш запис, вказуєш параметр TTL - Time-To-Live. Він і показує (або принаймні натякає), скільки цей запис можна тримати в кеші.

Це вже дає зрозуміти, чому ми можемо бачити застарілі результати. Особливо якщо сервіс вже встиг перевірити запис до того, як ми його створили, та тепер побачить тільки вже закешовану хибну версію.

Можна спитати — а чому тоді сервіс не ходить щоразу до DNS сервера, що містить запис (це називається SOA - Source of Authority), та не перевіряє без всякого кешу? Це не так просто. По-перше, сам авторитетний DNS-сервер може мінятись, хоча це не так часто трапляється. По-друге, проміжні сервери теж можуть мати кеш.

По-третє, і найгірше, цей кеш може розрізнятись між собою, та тоді перевірка буде стрибати з одного результату на інший. Бо DNS-сервери зазвичай мають декілька копій. Наприклад, кореневих серверів зараз аж 1696. Ясно, що коренева конфігурація (тобто адреси DNS-серверів доменів верхнього рівня) не так часто змінюється. Та сервери провайдерів, такі, як GoDaddy або NameCheap, теж мають багато копій — інакше б вони не були надійними. І звісно, свіжо доданий запис ніяк не може синхронно зʼявитися на всіх копіях.

Мине час, та думка DNS серверів про твій домен зійдеться до однієї. Але поки він свіжий, проблем не минути. Або затримка — через кеш. Або результат, що стрибає.

Раптом після вчорашнього посту знайшовся ще один локальний рекурентний DNS сервер - Knot Resolver. Чим він гарний — це той самий сервер, який використовує Cloudflare для свого відкритого DNS 1.1.1.1. Це цікаво, бо самі автори Knot не гарантують його підтримку “в продакшні”, а тільки для простих споживацьких потреб. Втім, як бачиш, для Cloudflare його функціоналу вистачає (хоча Cloudflare додали власний кеш та ще дещо; кеш Knot не масштабується та обмежений однією машиною.)

Рекомендація від Cloudflare багато значить саме тому, що такий сервер буде давати результати, схожі на їхні. А значить, можна очікувати, що не буде незрозумілої клієнтам розбіжності, яку створював unbound. Взагалі це найбільший ризик з локальними DNS серверами — що невідомо, як вони себе поведуть в складній ситуації.

Щодо технічних деталей, то Knot Resolver встановлюється хоч на Linux, хоч на macOS, хоч в Docker; цікаво він конфігурується — файл конфігурації є скриптом на Lua. Можна кешувати запити, можна навпаки, кеш вимкнути. Можна використати в інтерактивному режимі, на кшталт dig.

Найбільші граблі, на які я наступив, поки налаштовував — це те, що DNS працює за протоколом UDP, та порти для нього треба відкривати окремо. Наприклад, в Docker: docker -p 35353:53/udp. Причому — підтримка TCP теж є — але як резервний варіант. Тому без відкритого UDP ваш DNS сервер працювати буде, тільки не з кожним клієнтом, та майже напевно з затримками. Піди та здогадайся, чому.

🇨🇿 До речі, Knot - продукт чеського доменного реєстратора CZ.NIC; на їхньому акаунті в GitHub можна знайти ще багато цікавого.

Сьогодні закінчив з налаштуванням HomeAssistant. Бо, хоч він в мене вже був, оновлення за чотири роки потребує низки змін. На щастя, нічого складнішого, ніж редагування конфігурації.

Розумна розетка (Meross) підʼєдналася в Home Assistant теж без проблем. Власне, до розетки підключений витяжний вентилятор (української фірми Vents), який сам по собі розумний — вмикається при наявності вологості в ванній. Але, чого вентилятор не вміє — це вимикатись за розкладом.

А мені не хотілося, щоб він вмикався вночі. Тут і допомогла розумна розетка — коли вона вже є в HomeAssistant, то додати роботу за розкладом це справа на пару хвилин. Та й витрати невеликі - 200-300 грн за розетку, причому є варіанти на декілька розʼємів, так виходить економніше.

Інший сервіс, який варто мати на домашньому сервері — це DNS Pi-hole. Він водночас і прискорює DNS запити — принаймні повторювані, і блокує рекламу, трекери, та й взагалі що захочеш, та ще й послужить для перевірки DNS запитів, якщо для роботи таке знадобиться. А головне, що працюватиме це для всіх пристроїв в мережі без індивідуальних налаштувань.

З DietPi Pi-hole встановлюється дуже просто. Залишається вказати його як DNS сервер на роутері — на моєму Asus навіть є така функція DNS Director, щоб зробити використання Pi-hole примусовим через перенаправлення всіх DNS запитів на нього.

Знаходжусь в пошуках рішення для живлення роутера від павербанка постійного струму. Про це буде окремий пост пізніше, а поки що зачеплю дотичну тему: що робити з Pi-Hole?

Pi-Hole - то домашній DNS з блокуванням реклами. В мене він встановлений на ODroid XU4. Нарікань жодних не маю, але з живленням виходить проблема. ODroid XU4 живиться власним блоком з параметрами 5 В на 4 А. Чотири ампери — це поза будь-яким стандартом USB, тож просто “взяти та вткнути” не вийде, який би потужний павербанк не був. Дев’ять вольтів ніби йому теж протипоказано. Також немає надії, що вистачить менш ніж 4 А, принаймні тому, що в мене система завантажується з зовнішнього диска.

Бачив ідеї, що можна взяти USB-C кабель з вибором режиму 20 В та конвертор напруги до 5 В та заживити через такий ланцюг. Поки залишимо це на план “Г”, бо немає ніякої впевненості.

Далі, альтернативи: перемістити блокувальник DNS на роутер. Сам Pi-Hole не вийде — він досить важкий по залежностях. Є аналог для AsusWRT-Merlin: Diversion. Нюанс: в нього немає вебінтерфейсу. Вебінтерфейс в DNS-блокувальнику вкрай потрібний, щоб його можна було вимкнути. (Хибні позитиви це нормальна справа — наприклад, Pi-Hole не дозволяє мені відписатися від деяких розсилок через заблокований домен.) Тут теж можна розвʼязати технологіями — може, навіть, встановити для того розумну кнопку-вимикач.

Та ще пропонують купити малесенький Pi Zero, що живиться від USB, та увіткнути його в сам роутер. Теж цікаве рішення з очевидними мінусами: теж потрібно щось купувати, налаштовувати, та й підтримувати.

…Що тут сказати. Певно, найрозумніший поки вихід — це вимкнути до біса то блокування.

А ви замислювались колись, як взагалі пристрої знаходять один одного в мережі? Хто подумав DNS, той вгадав. Але є нюанси.

По-перше, як взагалі працює DNS? Це протокол на основі UDP, тобто асинхронний, тобто дуже спрощено, ви гукаєте у простір “підкажіть адресу вузла (або іншу інформацію)”, та звідкілясь приходить відповідь. В типовому сценарії ви питаєте в конкретного вузла, але насправді відповідь часто приходить не звідти.

Але із виявленням пристроїв все ще цікавіше. Бо тут запит DNS йде на всі адреси в мережі — що називається mDNS, multicast DNS. Та відповідає на нього не роутер чи інший центральний вузол, а самі пристрої! Це називається DNS-SD - стандарт DNS для виявлення сервісів. В macOS є вбудована утиліта для нього, на Linux/Windows наче теж є аналоги. Ось, будь ласка, це команда “агов, хто в цій мережі взагалі підтримує DNS-SD?”

dns-sd -B _services._dns-sd._udp

(Взагалі звичайний dig теж вміє робити запити до mDNS, коли не поламаний):

dig @224.0.0.251 -p 5353 -t ptr _services._dns-sd._udp.local

Я аж рот роззявив від кількості та від різноманіття сервісів. Наприклад, тут є й _airplay, й _home-assistant, а не тільки розумні пристрої.

Як можна здогадатися, така інформація не тільки корисна, а й небезпечна, оскільки запит може надіслати будь-яка програма чи пристрій в мережі. Нарешті зрозумів, чому свіжі версії macOS видають попередження на кшталт “Дозволити застосунку бачити пристрої в локальній мережі.” Бо навіть не потрібно нічого сканувати, як Трініті в Матриці — пристрої самі все скажуть.

Для пристроїв з батарейкою такий спосіб, звісно, не підходить. Тому є інший протокол - DNS-SRP - для того, щоб реєструвати вузли на центральному сервері. Причому він цілком сумісний з DNS-SD, оскільки останньому не важливо, який саме вузол надсилає відповідь — сам за себе чи через посередника.

Пробачте, але в mDNS/DNS-SD стільки моментів, які мене змусили зупинитися та подумати, що треба про це розповісти.

По-перше, що таке multicast? Я знав про зʼєднання 1-до-1 та про broadcast - поширення сигналу на всі вузли. А Multicast - це буквально модель publish/subscribe для мережі IP. Для цього виділена категорія адрес (224.0.0.x) та повідомлення на ці адреси приймаються всіма слухачами в мережі. Звісно, це працює тільки для протоколів без сесії, тобто UDP, QUIC тощо, але не TCP.

Є реєстр відомих адрес Multicast, так само як і стандартних призначень портів. Як я розумію, Multicast більше використовується для початкового налаштування та виявлення, ніж для постійного поширення повідомлень.

Як це працює з Ethernet, зрозуміло (пакети розсилаються всім інтерфейсам, та фільтруються з боку отримувача). Але як Multicast можливий за Wi-Fi? Виявляється, так, є особливий режим надсилання за Wi-Fi, коли пакет призначається не одному, а всім клієнтам, та для того у мережі навіть є груповий ключ. Ось більше інформації та ще тут.

Чи можна DNS-SD використати у власних проєктах? Авжеж! Наприклад, для пошуку партнерів для гри в локальній мережі. Або синхронізації застосунку з телефону із компʼютером (забуте мистецтво.) Для того доведеться визначити системний сервіс DNS-SD та інтегруватися з ним. В macOS це mDNSResponder (скількі раз я його помічав, але не розумів, що він робить!), а оголосити сервіс можна тією ж утилітою dns-sd. Тобто все ж “центральний” реєстр сервісів є, але на рівні кожної машини.