# Зашифрований DNS на macOS: DoH і DoT із профілями конфігурації > Чому звичайний DNS витікає з кожного сайту, який ви відвідуєте, як DNS-over-HTTPS і DNS-over-TLS це виправляють і як налаштувати будь-який із них нативно на Mac із підписаним профілем конфігурації, перевіреним із терміналу. HisnLabs Security & Research Team · Published 2026-09-15 Canonical: https://hisnlabs.com/uk/blog/encrypted-dns-macos-guide HTTPS приховує те, що ви надсилаєте на веб-сайт, але перш ніж ваш Mac навіть зможе відкрити це з’єднання, він має поставити запитання у вигляді звичайного тексту: «на який сервер вказує це ім’я?» Це запитання — DNS-пошук — передається незашифрованим за замовчуванням у більшості мереж, що означає, що ваш інтернет-провайдер, адміністратор офісної мережі чи будь-хто, хто користується незахищеною мережею Wi-Fi, може бачити кожен домен, який ви вирішите, навіть якщо самі сторінки після цього повністю зашифровані. ## Чому звичайний DNS витік Традиційний DNS, стандартизований за десятиліття до того, як HTTPS став стандартним для Інтернету, надсилає запити через звичайний UDP або TCP на порт 53 без шифрування, а в більшості налаштувань домашніх і публічних мереж також немає автентифікації резолвера. Мережевому оператору не потрібно порушувати HTTPS, щоб створити список кожного домену, який ви відвідуєте — йому потрібно лише стежити за вашим DNS-трафіком, який відкрито поруч із ним. Так працює багато фільтрів вмісту на основі DNS і деякі форми спостереження на рівні мережі: не перевіряючи ваш зашифрований трафік, а просто реєструючи або блокуючи пошук, який має відбутися, перш ніж цей трафік існує. ## DoH і DoT: два способи шифрування одного пошуку Два стандарти IETF вирішують це, загортаючи сам запит DNS у шифрування. DNS-over-TLS, визначений у RFC 7858, загортає запити DNS у спеціальне зашифроване TLS-з’єднання на порту 853, відрізняючи його від звичайного трафіку та полегшуючи ідентифікацію для мережі — і, в принципі, для мережі, щоб повністю заблокувати його, якщо вона хоче спеціально зупинити зашифрований DNS. DNS-over-HTTPS, визначений у RFC 8484, замість цього відображає DNS-запит на стандартний HTTPS-запит на порт 443, той самий порт, який використовується майже всім звичайним веб-трафіком. Такий вибір робить запити DoH набагато складніше відрізнити від них і, отже, блокувати їх окремо від загального веб-перегляду. ## Вбудована підтримка Apple з macOS 11 Apple вбудувала зашифрований DNS безпосередньо у свій мережевий стек, а не залишала це додаткам сторонніх розробників, оголосивши про цю функцію на WWDC 2020 разом із macOS Big Sur (macOS 11) і еквівалентною версією iOS 14. Під час сеансу було запропоновано два способи ввімкнути його: `NEDNSSettingsManager` API для додатків, щоб налаштувати його програмним шляхом, і — варіант, який насправді використовує більшість людей — профіль конфігурації, що містить корисне навантаження `com.apple.dnsSettings.managed`, задокументований у довідці Apple щодо керування пристроями, який дозволяє вказати адресу DoH або DoT-розв’язувача та дозволити кожній програмі в системі використовувати його за замовчуванням, без стороннього програмного забезпечення. ## Зразок профілю конфігурації Профіль конфігурації — це список властивостей XML (файл `.mobileconfig`), який macOS може інсталювати за допомогою параметрів системи, якщо ви двічі клацнете його або перетягнете на панель «Профілі». Наведений нижче приклад вказує Mac на загальнодоступний розпізнавач DNS-over-HTTPS Quad9 — широко використовувану службу без облікового запису, яка також за замовчуванням блокує з’єднання з доменами, відомими фішингом та іншими шкідливими діями. Замініть ідентифікатор заповнювача та значення UUID перед його використанням; кожен справжній профіль потребує власного унікального `PayloadUUID`. *quad9-doh.mobileconfig* ```xml PayloadContent PayloadType com.apple.dnsSettings.managed PayloadIdentifier com.example.dns.quad9-doh PayloadUUID REPLACE-WITH-A-UNIQUE-UUID-1 PayloadVersion 1 PayloadDisplayName Quad9 Encrypted DNS (DoH) DNSSettings DNSProtocol HTTPS ServerURL https://dns.quad9.net/dns-query ServerAddresses 9.9.9.9 149.112.112.112 2620:fe::fe 2620:fe::9 PayloadDisplayName Encrypted DNS - Quad9 PayloadIdentifier com.example.dns.quad9-doh.root PayloadType Configuration PayloadUUID REPLACE-WITH-A-UNIQUE-UUID-2 PayloadVersion 1 ``` Щоб замість цього використовувати Cloudflare, встановіть `ServerURL` на `https://cloudflare-dns.com/dns-query` і `ServerAddresses` на `1.1.1.1` та `1.0.0.1` (з `2606:4700:4700::1111` та `2606:4700:4700::1001` для IPv6) — або, для DNS-over-TLS замість DoH, встановіть `DNSProtocol` на `TLS` і `ServerName` на `one.one.one.one`, згідно з опублікованою документацією DoT Cloudflare. ## Встановлення 1. Збережіть файл із розширенням `.mobileconfig` і двічі клацніть його або відкрийте «Параметри системи», перейдіть до «Конфіденційність і безпека», потім «Профілі» та перетягніть файл. 2. macOS покаже вміст корисного навантаження — включно з налаштованим вами резолвером — до того, як ви його схвалите; переглядайте це кожного разу, оскільки профіль — це саме те, як зловмисник може перенаправити ваш DNS, якщо ви встановите його з ненадійного джерела. 3. Натисніть «Встановити та автентифікувати». Непідписаний профіль, подібний до цього зразка, відображатиметься як статус перевірки «Непідписаний»; це очікувано для профілю, створеного вручну, і само по собі не є ознакою втручання, але для будь-чого, що виходить за межі особистого тестування, ви повинні підписати профіль, щоб можна було перевірити його цілісність. ## Перевірка спрацювала Не просто довіряйте панелі налаштувань — перевірте з терміналу. *Термінал* ```console # Show the resolvers macOS is actually configured to use $ scutil --dns # Look for your interface's resolver entry — it should now show # the DoH/DoT server address you configured, not your router or ISP's resolver # Confirm a lookup succeeds and see which resolver answered $ dig example.com # Cloudflare's own diagnostic page also reports whether your # connection is using encrypted DNS when you open it in a browser $ open https://1.1.1.1/help ``` Якщо `scutil --dns` все ще вказує адресу вашого маршрутизатора або резолвер вашого провайдера як активний DNS-сервер, профіль не набув чинності — переконайтеся, що ви встановили його в розділі «Профілі», а не просто завантажили, і що жодна інша конфігурація мережі (див. нижче) не замінює його. ## Підводні камені, через які це перестає працювати безшумно - Додаток VPN дуже часто скасовує системні налаштування DNS під час підключення, спрямовуючи натомість пошук через власний резолвер — перевірте конфігурацію DNS знову після підключення до VPN, а не безпосередньо перед цим. - Адаптивні портали Wi-Fi готелів, аеропортів і кав’ярень зазвичай не можуть завершити потік входу через зашифрований DNS, оскільки вони покладаються на перехоплення простого запиту DNS, щоб перенаправити вас на сторінку входу; можливо, вам знадобиться тимчасово видалити або вимкнути профіль, щоб вийти в Інтернет, а потім повторно встановити його після підключення. - Деякі веб-переглядачі, серед яких Firefox і Chrome, постачають власні, окремі параметри DoH, які можуть перевизначати або дублювати конфігурацію системного рівня; перевірте власні мережеві налаштування браузера, якщо його поведінка не відповідає тому, що повідомляє `scutil --dns`. - iCloud Private Relay і зашифрований DNS вирішують різні проблеми, що збігаються — Private Relay приховує вашу IP-адресу від сайтів, які ви відвідуєте в Safari, тоді як зашифрований DNS приховує, які домени ви вирішуєте у своїй мережі; використання одного не робить іншого зайвим. > **Note:** Зашифрований DNS захищає пошук, а не все, що йде від нього. Оператор мережі, який не може побачити, який домен ви розв’язали, часто все ще може бачити IP-адресу, до якої ви згодом під’єднуєтеся за допомогою рукостискання TLS, якщо ви також не використовуєте щось на зразок DNS-over-HTTPS у поєднанні з підтримкою Encrypted Client Hello на обох кінцях — окремий захист, який все ще підтримується нерівномірно. ## Яке місце тут посідають FireAI та HisnLabs FireAI does not provide encrypted DNS today — it is on the roadmap, not in the current release — so a configuration profile like the one above is what actually closes the DNS-leak gap; FireAI’s job is different, watching and controlling which apps get to make a connection at all once that lookup resolves. FireAI — це власний продукт HisnLabs: ШІ-фаєрвол, який працює безпосередньо на вашому Mac. Він показує простою мовою кожне з’єднання, яке встановлюють ваші застосунки, і дає вам вирішувати, що покидає ваш Mac, — його ШІ працює локально, тож ваш трафік ніколи не надсилається ні нам, ні будь-кому іншому. Команда дослідників безпеки HisnLabs — саме вона підтримує точність цих рішень: каталогізує, які домени є звичайною телеметрією, а які — справжнім сервісом, відстежує країну та мережу за з’єднанням і навчає локальну модель (функцію FireAI Pilot) на реальних шаблонах трафіку — і нічого з цього не покидає ваш Mac. Ви можете почитати про технічні рішення, що лежать в його основі, або спробувати FireAI протягом 17 днів на сторінці [FireAI від HisnLabs](https://hisnlabs.com/fireai/uk/download). ## Sources - [RFC 8484: DNS Queries over HTTPS (DoH)](https://www.rfc-editor.org/rfc/rfc8484) - [RFC 7858: DNS over TLS (DoT)](https://www.rfc-editor.org/rfc/rfc7858) - [Apple Developer, WWDC20: Enable encrypted DNS](https://developer.apple.com/videos/play/wwdc2020/10047/) - [Apple Developer Documentation: DNSSettings payload](https://developer.apple.com/documentation/devicemanagement/dnssettings) - [Cloudflare: DNS over HTTPS](https://developers.cloudflare.com/1.1.1.1/encryption/dns-over-https/) - [Cloudflare: DNS over TLS](https://developers.cloudflare.com/1.1.1.1/encryption/dns-over-tls/) - [Cloudflare: 1.1.1.1 IP addresses](https://developers.cloudflare.com/1.1.1.1/ip-addresses/) - [Quad9: Service addresses and features](https://quad9.net/service/service-addresses-and-features)