як працює DNS та як налаштувати в системі й браузері

2026-11-04 ⏱ 29 min read • TECH

Ви вводите https://codebyme.de у браузері. Перш ніж встановити з’єднання із сайтом, браузер має з’ясувати, куди його встановлювати. Зазвичай для цього потрібно перетворити доменне ім’я на IP-адресу. Цю задачу вирішує DNS — Domain Name System.

Але DNS — це не один сервер із переліком усіх сайтів. Це розподілена система: клієнт на вашому пристрої, кеші, рекурсивний resolver та сервери, відповідальні за різні частини простору імен. Браузер також може використовувати власний DNS, оминаючи resolver операційної системи.

Розберемо шлях запиту, типи записів, налаштування комп’ютера й роутера, шифрування та перевірку результату. Для читання достатньо розуміти IP-адресу й мережевий інтерфейс; IPv4 і підмережі розглянуті окремо.

Зміст

Що саме робить DNS
Що називають DNS-сервером
Шлях запиту і кешування
Записи, зони й делегування
Звідки система бере DNS
Як подивитися поточну конфігурацію
Як змінити DNS у системі та роутері
Як вибрати публічний resolver
Звичайний DNS, DoT, DoH і DNSSEC
DNS безпосередньо у браузері
DNS-блокування та приватність
Після DNS: HTTPS, SNI та ECH
Скільки сайтів може бути за однією IP-адресою
Cloudflare: DNS, CDN і reverse proxy
Що змінюють VPN і Tor
Діагностика і шпаргалка

Що саме робить DNS

У URL https://codebyme.de/blog є схема https, ім’я хоста codebyme.de та шлях /blog. DNS працює з іменем хоста. Він не шукає статтю /blog і не передає браузеру її HTML.

Після отримання адреси браузер окремо встановлює з’єднання, узгоджує TLS та обмінюється HTTP-повідомленнями. Для HTTP/3 використовується QUIC, для HTTP/1.1 та HTTP/2 зазвичай TCP. Успішний DNS-запит ще не означає, що сервер доступний або його TLS-сертифікат правильний.

Відповідність між іменами й адресами не обов’язково взаємно однозначна:

Одне ім’я може мати кілька IPv4- та IPv6-адрес: для балансування, резервування або CDN.
Багато імен можуть вести на одну адресу. Сервер розрізняє потрібний сайт за інформацією в TLS та HTTP.
Відповіді можуть відрізнятися залежно від часу, resolver і мережевого розташування.

DNS також публікує поштові маршрути, перевірки володіння доменом і параметри сервісів. Пошук IP-адреси — лише найпомітніший випадок його використання.

Що називають DNS-сервером

У налаштуваннях мережі «DNS server» зазвичай означає адресу рекурсивного resolver або локального посередника до нього. Це не той самий сервер, де ви редагуєте записи власного домену.

Учасник	Задача
Stub resolver	Клієнтська частина на пристрої: передає запити й отримує відповіді
Рекурсивний resolver	Знаходить відповідь для клієнта, звертаючись до інших серверів і використовуючи кеш
DNS-forwarder	Передає запити іншому resolver; часто працює на домашньому роутері
Root server	Допомагає знайти сервери доменів верхнього рівня, наприклад `.de`
TLD server	Допомагає знайти авторитетні сервери домену в зоні, наприклад `example.net` у `.net`
Авторитетний сервер	Відповідає на підставі даних DNS-зони, за яку відповідає

Серверне ПЗ може виконувати кілька ролей, але логічно їх варто розрізняти. Публічний resolver не стає власником зони, коли кешує її записи.

Адреса 192.168.1.1 у полі DNS часто означає: «запитуй роутер, а він перешле запит далі». Адреса 127.0.0.53 на Linux із systemd-resolved означає локальний stub listener, а не зовнішній сервер.

Ієрархію та формати DNS описують RFC 1034 і RFC 1035.

Шлях запиту і кешування

Припустімо, клієнту потрібен запис A для www.example.net, а потрібних даних немає в кеші. Нижче — спрощений сценарій; адреса відповіді умовна.

Клієнт звертається до рекурсивного resolver. Той отримує делегування від root і .net, а потім відповідь від авторитетного сервера example.net

Клієнт просить resolver знайти відповідь. Це рекурсивний запит: клієнт очікує результат або помилку, а не перелік серверів для самостійного обходу.
Resolver звертається до кореневого сервера й отримує делегування до .net.
Сервер .net вказує авторитетні сервери example.net.
Авторитетний сервер повертає потрібний запис або іншу відповідь: наприклад, CNAME чи повідомлення про відсутність імені.
Resolver повертає результат клієнту та кешує дані відповідно до їхнього TTL.

Між resolver та серверами ієрархії це зазвичай ітеративний пошук. Кореневий сервер не звертається до .net замість resolver. У реальній мережі кеш делегувань дозволяє пропускати частину кроків. QNAME minimization може також обмежувати, яку частину імені бачить кожен рівень.

Подивитися делегування можна через dig:

dig +trace codebyme.de A

dig +trace сам проходить ієрархію. Це не журнал запитів вашого звичайного resolver і не перевірка DoH браузера. У мережі, яка дозволяє DNS лише через внутрішній resolver, команда може не працювати.

TTL і негативне кешування

TTL — Time To Live, час кешування в секундах. Якщо запис отримано з TTL 300, кеш зазвичай може використовувати його протягом наступних п’яти хвилин. У відповіді кешувального resolver ви часто бачите вже залишок цього часу.

dig codebyme.de A +noall +answer

Щоб читати результат, корисно розкласти одну відповідь. Нижче умовний скорочений вивід, а не поточні дані реального домену:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.example.net.       IN A
;; ANSWER SECTION:
www.example.net. 187    IN A 203.0.113.10
;; Query time: 12 msec
;; SERVER: 192.0.2.53#53(192.0.2.53) (UDP)

Тут NOERROR — код результату, 187 — TTL у секундах, IN — клас Internet, A — тип, а 203.0.113.10 — дані запису. rd означає запитану рекурсію, ra — повідомлення сервера, що рекурсія доступна. SERVER — адресат саме цього запиту, а не обов’язково авторитетний сервер домену. Адреса 192.0.2.53 також узята з документаційного діапазону.

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

Кешуються й негативні відповіді. Якщо ім’я не існувало, щойно створений запис може ще деякий час залишатися невидимим для resolver, який зберіг попередню відповідь. Правила визначає RFC 2308. Деякі resolver також можуть тимчасово повертати прострочені дані при збоях upstream: це окремий механізм serve-stale, а не «нескінченний TTL».

Записи, зони й делегування

Запит визначається не лише ім’ям, а й типом запису. A example.net і MX example.net — різні питання.

Тип	Що визначає
`A`	IPv4-адресу
`AAAA`	IPv6-адресу
`CNAME`	Інше доменне ім’я — канонічну ціль псевдоніма
`MX`	Поштові сервери та їхні пріоритети
`TXT`	Текстові дані: зокрема SPF, DKIM і перевірки володіння
`NS`	Авторитетні сервери зони та делегування
`SOA`	Метадані зони: серійний номер і параметри її обслуговування
`PTR`	Ім’я в просторі зворотного DNS
`CAA`	Які центри сертифікації можуть видавати сертифікати
`HTTPS`, `SVCB`	Прив’язку сервісу та параметри підключення

Умовний фрагмент зони:

$ORIGIN example.net.
$TTL 300
@       IN A     203.0.113.10
@       IN AAAA  2001:db8::10
www     IN CNAME example.net.
@       IN MX    10 mail.example.net.
mail    IN A     203.0.113.20

Це ілюстрація, а не готова зона: тут немає обов’язкових SOA та NS. Адреси 203.0.113.0/24 і 2001:db8::/32 призначені для документації. Крапка наприкінці example.net. означає абсолютне ім’я; без неї файловий формат зони може дописати поточний $ORIGIN.

CNAME не є HTTP-редиректом. Він допомагає знайти DNS-дані іншого імені, але не змінює URL у браузері. Звичайний CNAME також не можна довільно поєднувати з іншими даними на тому самому імені. «CNAME flattening» у панелях провайдерів — окрема можливість реалізації.

Зона — частина DNS-простору під певним адміністративним керуванням. Піддомен не обов’язково є окремою зоною: blog.example.net може залишатися записом у зоні example.net. Для окремого керування його можна делегувати іншими NS; за потреби публікуються glue-записи адрес серверів.

Реєстратор домену й DNS-хостинг можуть бути різними компаніями. Зміна NS у реєстратора змінює делегування, а зміна DNS у Wi-Fi на ноутбуці — лише те, кого ноутбук запитуватиме.

Для IPv4 зворотні записи розміщені в in-addr.arpa, для IPv6 — в ip6.arpa. Власник IP-простору часто керує ними окремо від власника прямої зони. Відсутність PTR не означає, що запис A неправильний.

Записи HTTPS/SVCB, визначені в RFC 9460, можуть повідомляти підтримувані протоколи й параметри сервісу. Вони не замінюють перевірку TLS-сертифіката.

Звідки система бере DNS

За типової домашньої конфігурації пристрій отримує параметри автоматично. Для IPv4 DNS часто передається через DHCP. В IPv6 джерелами можуть бути Router Advertisement з RDNSS та DHCPv6.

У результаті система може знати кілька resolver: від Ethernet, Wi-Fi та VPN. Це не завжди один глобальний список. Наприклад, запити до corp.example можуть спрямовуватися у VPN, а решта — до домашньої мережі. Це split DNS.

На визначення імен впливають також:

hosts: локальні відповідності імен адресам;
правила системного name service, наприклад /etc/nsswitch.conf у Linux;
mDNS для локального виявлення, зокрема імен .local;
кеші операційної системи й програм;
власний resolver браузера та його DoH-політики.

Універсальна схема «спочатку hosts, потім кеш, потім DNS» недостатня для всіх програм. Наприклад, dig робить DNS-запит і не є тестом того, що поверне системний getaddrinfo() з урахуванням усіх локальних механізмів.

Як подивитися поточну конфігурацію

Спочатку з’ясуйте, що вже налаштовано. dig постачається, наприклад, у пакетах dnsutils або bind-utils; назва залежить від дистрибутива. На Windows використовуйте PowerShell-аналоги нижче.

Linux

Якщо використовується systemd-resolved:

resolvectl status

Дивіться DNS-сервери кожного інтерфейсу, поточний сервер і routing domains. Позначення ~corp.example означає домен маршрутизації DNS, а ~. — кореневий routing domain для запитів без більш специфічного маршруту. Вибір залежить від конфігурації всіх інтерфейсів.

Запит через systemd-resolved:

resolvectl query codebyme.de

У системах із glibc перевірка через механізм NSS:

getent ahosts codebyme.de

Перевірка файлу сумісності та його цілі:

ls -l /etc/resolv.conf
cat /etc/resolv.conf

Якщо там 127.0.0.53, це ще не відповідь на питання «який зовнішній resolver використовується». Дивіться resolvectl status. Режими файлу описані в документації systemd-resolved.

Windows

У PowerShell:

Get-DnsClientServerAddress | Format-Table InterfaceAlias, AddressFamily, ServerAddresses -AutoSize

Запит із використанням поточної конфігурації:

Resolve-DnsName codebyme.de -Type A

macOS

Поточна конфігурація системних resolver, включно зі scoped resolver:

scutil --dns

Перелік мережевих сервісів:

networksetup -listallnetworkservices

Ручні DNS-параметри конкретного сервісу:

networksetup -getdnsservers "Wi-Fi"

Відсутність вручну заданих DNS не означає, що DNS не працює: сервери можуть надходити автоматично. Ефективну картину дивіться через scutil --dns.

Запит до конкретного сервера

На системі з dig:

dig @1.1.1.1 codebyme.de A

У PowerShell:

Resolve-DnsName codebyme.de -Type A -Server 1.1.1.1 -DnsOnly

У dig поле SERVER показує адресата запиту: якщо це локальний forwarder, воно не показує, до кого він звертався далі.

Як змінити DNS у системі та роутері

Нижче як приклад використовується стандартний resolver Cloudflare. Збережіть поточні налаштування.

Linux: NetworkManager

Знайдіть назву активного профілю:

nmcli connection show --active

Замініть My Wi-Fi на точну назву профілю з’єднання, яка не обов’язково збігається з іменем інтерфейсу на кшталт wlp2s0.

Для IPv4:

sudo nmcli connection modify "My Wi-Fi" ipv4.ignore-auto-dns yes ipv4.dns "1.1.1.1 1.0.0.1"

За наявності робочого IPv6 налаштуйте його DNS також:

sudo nmcli connection modify "My Wi-Fi" ipv6.ignore-auto-dns yes ipv6.dns "2606:4700:4700::1111 2606:4700:4700::1001"

Застосуйте профіль. Це може короткочасно перервати з’єднання:

sudo nmcli connection up "My Wi-Fi"

ignore-auto-dns не переводить DHCP-адресу на статичну. Перевірте результат через resolvectl status або засоби вашого resolver. Активний VPN може продовжувати застосовувати свої DNS-маршрути.

Повернення до автоматичних DNS, якщо до експерименту не було власного ручного списку:

sudo nmcli connection modify "My Wi-Fi" ipv4.ignore-auto-dns no ipv4.dns "" ipv6.ignore-auto-dns no ipv6.dns ""
sudo nmcli connection up "My Wi-Fi"

Попередню ручну конфігурацію відновіть зі збережених значень. Властивості описані в NetworkManager Reference Manual.

Linux: systemd-resolved

systemd-resolved обслуговує визначення імен, а джерелом постійної конфігурації часто є NetworkManager або systemd-networkd. Не варто одночасно редагувати всі можливі місця.

Тимчасовий експеримент для інтерфейсу enp3s0:

sudo resolvectl dns enp3s0 1.1.1.1 1.0.0.1
sudo resolvectl domain enp3s0 '~.'
resolvectl status enp3s0

Це тимчасові параметри: мережевий менеджер, перепідключення або перезавантаження можуть їх замінити. Більш специфічні DNS-маршрути VPN вони також не скасовують.

Скидання тимчасових per-link параметрів:

sudo resolvectl revert enp3s0

Після скидання перевірте стан; за потреби перепідключіть профіль, щоб менеджер знову передав автоматичні параметри. revert не є збереженою копією попередньої конфігурації.

Якщо /etc/resolv.conf генерується автоматично або є симлінком, ручне додавання nameserver у нього буде ненадійним. Змінюйте джерело конфігурації, яке реально керує DNS.

Windows

У Windows 11: Settings → Network & internet → Wi-Fi або Ethernet → властивості потрібного підключення → DNS server assignment → Edit. Виберіть ручне призначення й внесіть адреси. Для Wi-Fi спочатку може знадобитися відкрити властивості вибраної мережі.

Не плутайте це з призначенням IP-адреси: DHCP може залишатися увімкненим, а DNS бути ручним. Назви елементів залежать від версії та локалізації; актуальні кроки є в довідці Microsoft.

У PowerShell від адміністратора, використовуючи точну назву інтерфейсу:

Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ServerAddresses @("1.1.1.1", "1.0.0.1", "2606:4700:4700::1111", "2606:4700:4700::1001")

IPv6-адреси використовуйте за наявності робочого IPv6. Саме задання IP не гарантує шифрування: у Windows 11 окремо перевірте параметри DoH та дозволеного fallback. Доступність залежить від версії й політик.

Якщо початково DNS надходив автоматично, поверніть його:

Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ResetServerAddresses

Попередню ручну конфігурацію потрібно відновити явно. Параметри команди описані в Set-DnsClientServerAddress.

macOS

Відкрийте System Settings → Network → потрібний сервіс → Details → DNS. Додайте адреси й застосуйте зміни. Для повернення до автоматичних DNS приберіть додані вручну записи. Інструкція Apple

Через Terminal, використовуючи точну назву сервісу:

sudo networksetup -setdnsservers "Wi-Fi" 1.1.1.1 1.0.0.1

Скидання ручного списку для сервісу, який початково використовував автоматичні DNS:

sudo networksetup -setdnsservers "Wi-Fi" empty

Це не налаштовує DoH. Профілі та VPN можуть створювати додаткові resolver: перевірте scutil --dns. Синтаксис утиліти доступний локально через man networksetup.

Роутер: дві різні настройки

У роутері можуть бути окремо upstream DNS — кого він запитує сам або як forwarder — та DNS, який роздається LAN-клієнтам через DHCP й IPv6 RA/DHCPv6.

Якщо клієнтам видається адреса роутера, вони звертаються до нього. Якщо видається 1.1.1.1, його DNS-forwarder обходиться. Зміна WAN DNS не на кожній моделі змінює обидва механізми.

Після зміни клієнтам може знадобитися оновити DHCP-оренду або перепідключитися. Власний DoH браузера, ручні DNS та VPN можуть продовжувати використовувати інший маршрут. DNS, отриманий через IPv6, також не зникає лише від зміни IPv4 DHCP.

Як вибрати публічний resolver

Публічний DNS-провайдер отримує запити, які раніше міг обробляти resolver провайдера доступу. Це зміна сторони, якій ви довіряєте.

Сервіс	IPv4 стандартного профілю	Особливість
Cloudflare	`1.1.1.1`, `1.0.0.1`	Стандартний профіль без контентної фільтрації; окремі профілі Families
Google Public DNS	`8.8.8.8`, `8.8.4.4`	Публічний resolver із DNSSEC і зашифрованими транспортами
Quad9	`9.9.9.9`, `149.112.112.112`	Захищений профіль із блокуванням відомих шкідливих доменів

У Cloudflare, Google та Quad9 є різні профілі й способи підключення. Профілі одного сервісу можуть відрізнятися фільтрацією, DNSSEC та ECS.

Оцінюйте журналювання та строки зберігання, потрібну фільтрацію, доступність у своїй мережі, підтримку IPv6 і шифрування. Перевірте також EDNS Client Subnet: цей механізм може передавати частину мережевого префікса клієнта upstream. Єдиний «найшвидший DNS для всіх» не враховує ваше розташування й маршрут.

Дві адреси DNS не обов’язково означають «перша завжди, друга лише при аварії». Клієнти можуть перемикатися або виконувати запити паралельно. Якщо один сервер фільтрує домен, а інший ні, результат буде непослідовним. Для узгодженої політики використовуйте адреси одного профілю або однаково налаштовані власні resolver.

Низька DNS-затримка не дорівнює швидкості завантаження сайту: після визначення адреси час витрачається на з’єднання, серверну обробку й передавання даних.

Звичайний DNS, DoT, DoH і DNSSEC

DNS over HTTPS (DoH) передає DNS-запити всередині зашифрованого HTTPS-з’єднання — з тією самою технологією захисту, яку браузер використовує для відкриття HTTPS-сайтів. Навіщо це потрібно, найкраще видно в порівнянні зі звичайним DNS.

Звичайний DNS: запит у відкритому вигляді

Коли браузеру потрібна IP-адреса codebyme.de, він може звернутися через систему до DNS-сервера, отриманого від роутера або заданого вручну. У звичайному DNS запит і відповідь передаються без шифрування через UDP або TCP на порт 53.

Це має кілька наслідків:

Домен видно в мережі. Провайдер та інші учасники, які можуть спостерігати цей трафік, бачать запитане ім’я. Воно може належати сайту, рекламному сервісу або програмі, яка працює у фоні. Шлях сторінки на кшталт /blog/dns-guide у DNS-запиті не передається.
Відповідь можна відфільтрувати. DNS-сервер провайдера може замість адреси заблокованого домену повернути помилку або адресу заглушки.
Запит і відповідь можна підмінити на шляху. Наприклад, це може зробити зловмисник, який контролює точку доступу Wi-Fi або іншу ділянку мережі. Звичайний DNS сам по собі не захищає канал від такого втручання.

TCP у звичайному DNS використовується не лише для перенесення зон. Клієнт може повторити запит через TCP після обрізаної UDP-відповіді. Заблокований TCP/53 здатен спричинити ситуацію «маленькі відповіді працюють, частина інших запитів — ні». Це докладніше описано в RFC 7766.

DoH: DNS усередині HTTPS

З DoH браузер або системний клієнт встановлює HTTPS-з’єднання з вибраним DNS-сервісом, наприклад Cloudflare чи Google, і передає запит через нього. Зазвичай це порт 443. TLS шифрує обмін і дозволяє перевірити, що клієнт підключився до потрібного сервера.

Для провайдера це HTTPS-з’єднання: він бачить адресу DNS-сервісу та параметри передавання, але не може прочитати запитане доменне ім’я з його зашифрованого вмісту. Учасник публічної Wi-Fi-мережі також не може непомітно замінити DNS-відповідь усередині правильно перевіреного TLS-з’єднання.

Якщо блокування реалізовано через DNS провайдера, звернення через DoH до іншого resolver, який повертає справжню відповідь, може відновити доступ до сайту. Водночас DoH-сервіс можна впізнати за його адресою й заблокувати саме з’єднання до нього. Спільний із вебсайтами порт 443 не робить DoH невідрізнимим або невразливим до блокування.

Параметр	Звичайний DNS	DNS over HTTPS
Шифрування каналу	Відсутнє	TLS / HTTPS
Типовий порт	UDP або TCP `53`	`443`
Що видно з DNS-трафіку	Запитані імена та відповіді	Адресу DoH-сервісу й метадані з’єднання; вміст зашифрований
Підміна відповіді на шляху	Сам канал її не запобігає	TLS захищає від непомітної підміни за правильної перевірки сервера
DNS-фільтр провайдера	Діє при зверненні до його resolver або підміні на шляху	Можна обійти через доступний сторонній resolver без цього фільтра

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

DoT: окремий TLS-канал для DNS

DNS over TLS (DoT) також шифрує DNS-запити, але передає їх без HTTPS, безпосередньо через TLS — зазвичай на TCP-порт 853. Його використовують, зокрема, системні resolver та роутери. З погляду приховування вмісту запитів від провайдера він вирішує ту саму задачу, а окремий порт дозволяє простіше визначити й обмежити такий трафік. Протокол описаний у RFC 7858.

DNSSEC: перевірка даних

DNSSEC дозволяє перевіряти підписи та ланцюжок довіри, включно з автентифікованим запереченням існування запису. Він не приховує імена, не замінює HTTPS і не підписує довільну непідписану зону. Важливі записи DS, DNSKEY, RRSIG та механізми NSEC/NSEC3. Вступ — у RFC 4033.

Bootstrap: адреса самого DoH-сервера

DoH задають URL, наприклад https://cloudflare-dns.com/dns-query. Але для HTTPS-з’єднання спочатку потрібна IP-адреса cloudflare-dns.com.

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

Для DoT також важлива перевірка TLS-сертифіката за правильним іменем. Просте підключення до порту 853 без автентифікації сервера не дає тієї самої гарантії захисту.

DNS безпосередньо у браузері

Браузер може виконувати запити через власний DoH, тоді як ssh, пакетний менеджер та інші програми продовжують використовувати системний resolver.

Окремі маршрути DNS: CLI використовує системний resolver, браузер із власним DoH звертається до вибраного сервісу через HTTPS. Подальше підключення до сайту відбувається окремо

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

Firefox

Відкрийте about:preferences#privacy та знайдіть DNS over HTTPS. Назви залежать від мови інтерфейсу.

Рівень	Практичний зміст
Default Protection	Firefox вирішує, коли застосовувати DoH, враховуючи мережу, VPN, політики та інші умови
Increased Protection	Використовує вибраний DoH-сервіс, але допускає повернення до системного DNS при проблемах
Max Protection	Вимагає зашифрованого DNS; при недоступності показує попередження замість тихого fallback
Off	Вимикає власний DoH Firefox; системний DNS може залишатися зашифрованим окремо

Можна вибрати сервіс або задати власну DoH-адресу. Для експерименту з явно вибраним resolver без тихого fallback використовуйте Max Protection і перевірте статус. Вручну додані винятки можуть змінити поведінку для конкретних сайтів.

У about:networking#dns доступна діагностика DNS-кешу; у підтримуваних версіях вона також показує використання TRR/DoH. Поля й назви колонок залежать від версії.

Режими описані в офіційній довідці Firefox. Сам увімкнений перемикач ще не підтверджує, що кожен запит конкретного сеансу пішов через DoH.

Chrome та Chromium-браузери

У Chrome відкрийте chrome://settings/security та знайдіть Use secure DNS. Для зміни resolver виберіть провайдера або введіть власну DoH-адресу.

У режимі поточного провайдера браузер може спробувати захищене підключення до сумісного сервісу, але це не обов’язково змінює сам сервіс. Автоматичний режим може допускати незашифрований fallback. За вибору власного провайдера Chrome не повертається автоматично до незашифрованого режиму. На керованих пристроях можливість може бути недоступною. Довідка Chrome

В Edge знайдіть Secure DNS через пошук у Settings. Не переносіть поведінку Chrome на кожну Chromium-збірку: перевіряйте її режими й політики. Microsoft визначає для Edge automatic із fallback та secure без незашифрованого fallback у документації DnsOverHttpsMode.

Приклади DoH endpoint:

https://cloudflare-dns.com/dns-query

https://dns.google/dns-query

https://dns.quad9.net/dns-query

Перевірка саме браузера

dig @1.1.1.1 ... перевіряє сервер 1.1.1.1, а не маршрут браузера. Перевіряйте статус DoH, DNS-діагностику та мережевий журнал браузера. Для поглибленого аналізу зіставляйте їх із захопленням трафіку й відомими адресами endpoint.

Для Cloudflare є сторінка 1.1.1.1/help. Вона допомагає перевірити використання сервісу й зашифрованого DNS у поточному браузері. Позитивний результат стосується цієї перевірки: він не підтверджує DNS-конфігурацію ssh, торент-клієнта чи всього комп’ютера.

Відсутність UDP/53 сама по собі не доводить DoH: могла спрацювати кешована відповідь, DNS міг піти через TCP, DoT або VPN. DNS-пакети від іншої програми також не доводять, що браузер не використовує DoH.

Сайти перевірки DNS-leak зазвичай створюють унікальні імена та визначають, які resolver звернулися до їхніх авторитетних серверів. Це допомагає перевірити вибір resolver, але не є повним доказом шифрування каналу від браузера до нього.

DNS-блокування та приватність

Провайдер може блокувати доступ до сайту через свій DNS: замість справжньої адреси повертати помилку або адресу сторінки-заглушки. У такому випадку допомагає DoH або DoT до іншого resolver, який не блокує цей домен. Запит проходить зашифрованим каналом, тому провайдер не може просто прочитати його й підмінити DNS-відповідь на шляху. Сам вибраний DNS-сервіс при цьому має бути доступним із вашої мережі.

Проста заміна адреси DNS, наприклад на 8.8.8.8, теж може спрацювати, але звичайні запити залишаються відкритими. Провайдер може бачити їх і перехоплювати звернення на порт 53. DoH та DoT прибирають саме цю можливість читати або змінювати вміст запитів у мережі доступу. Якщо ж блокується безпосередньо IP-адреса сайту, зміна DNS такого блокування не усуне.

Шифрований DNS корисний і без блокувань. Звичайні DNS-запити розкривають домени, до яких звертаються браузер та інші програми. З DoH або DoT до стороннього сервісу провайдер доступу вже не може отримати цей перелік простим читанням DNS-трафіку. Сам вибраний resolver запити бачить, тому його політика приватності має значення.

Водночас провайдер продовжує бачити IP-адреси з’єднань, час та обсяг передавання. Ім’я сайту також може бути видно в незашифрованому SNI, якщо з’єднання не використовує ECH. Отже, шифрування DNS зменшує кількість доступної провайдеру інформації, але не робить відвідування сайтів невидимим.

VPN, внутрішні імена й captive portal

VPN може передавати власні DNS та маршрути. Власний DoH браузера може обійти внутрішній DNS VPN, але це ще не означає вихід трафіку поза тунель: HTTPS-з’єднання до DoH може йти через VPN. Перевіряйте окремо, хто розв’язує ім’я та яким маршрутом іде з’єднання.

Для git.corp.example, відомого лише внутрішній зоні, публічний resolver може повернути NXDOMAIN. Потрібні корпоративний resolver та правильний split DNS. Аналогічно, зовнішній DoH може обходити Pi-hole або іншу домашню DNS-фільтрацію.

У гостьовій мережі з captive portal спочатку може знадобитися пройти сторінку входу. Суворий DoH і заблокований endpoint здатні завадити визначенню імен до авторизації. Автоматичні режими браузерів можуть спеціально враховувати такі мережі.

Після DNS: HTTPS, SNI та ECH

Браузер отримав IP-адресу codebyme.de від стороннього DoH-сервісу. Далі він встановлює з’єднання з повернутою адресою. Вебтрафік не проходить через DNS-resolver лише тому, що той знайшов адресу: його робота на цьому етапі закінчилася.

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

Що приховує HTTPS

Для адреси https://example.net/books/manual.pdf?download=1 DNS шукає адресу example.net. Шлях /books/manual.pdf і параметр download=1 передаються вже в HTTP-запиті всередині TLS.

Пасивний спостерігач на мережевому шляху не читає ці частини запиту, cookies, паролі чи вміст файла, якщо HTTPS працює з належною перевіркою сертифіката. Сервер, на якому TLS-з’єднання закінчується, ці дані отримує. Частина після #, якщо вона є в URL, взагалі не передається як частина HTTP-адреси запиту; її обробляє клієнт.

Для прямого завантаження файла це означає, що HTTPS захищає і запит, і передані байти. Провайдер усе ще бачить адресу сервера, тривалість з’єднання й обсяг трафіку, а домен може бути видимим окремо через DNS або TLS. Саме шифрування нічого не говорить про законність файла, його безпечність чи те, як сервер зберігає журнал завантажень.

Чому ім’я може бути видно через SNI

На одній IP-адресі можуть працювати сотні HTTPS-сайтів. Ще до передавання HTTP-запиту сервер має вибрати потрібний TLS-сертифікат і конфігурацію. Для цього клієнт зазвичай надсилає ім’я сервера в розширенні SNI — Server Name Indication повідомлення ClientHello.

Без ECH це ім’я зазвичай доступне спостерігачу в мережі. Навіть TLS 1.3 сам по собі не приховує звичайний SNI. Тому можливий такий результат: DNS-запит зашифрований, а ім’я домену видно через початок наступного TLS-з’єднання. При цьому шлях конкретної сторінки залишається всередині захищеного HTTP-обміну.

Що додає ECH

ECH — Encrypted Client Hello шифрує внутрішнє повідомлення ClientHello, зокрема справжнє SNI. Зовні залишається інше ClientHello, необхідне для встановлення з’єднання; воно може містити спільне публічне ім’я інфраструктури замість домену потрібного сайту.

Для цього потрібна сумісна конфігурація клієнта й сервера. Дані ECH можуть публікуватися через DNS-записи HTTPS; їх також важливо отримувати захищеним способом. Вибір 1.1.1.1 у браузері сам по собі не додає ECH довільному сайту. Деталі механізму описані в RFC 9849.

DoH і ECH захищають різні етапи: перший — визначення адреси, другий — частину TLS-рукостискання. IP-адреса, час і розмір пакетів залишаються видимими. Спільна IP-адреса CDN у поєднанні з ECH зменшує можливість одразу прочитати назву сайту, але не дає гарантії анонімності або неможливості висновків за іншими ознаками.

Скільки сайтів може бути за однією IP-адресою

Для власного VPS найточніша відповідь міститься в його конфігурації: virtual hosts Nginx/Apache, правилах Caddy, ingress або іншого reverse proxy. Той самий сервер може обслуговувати кілька доменів і піддоменів. Оренда окремого VPS не означає, що на його адресі обов’язково один сайт.

Зовнішні reverse IP lookup сервіси збирають відомі їм відповідності з DNS-спостережень, історичних баз та інших джерел. Вони корисні для пошуку, але не мають повного реєстру всіх сайтів на адресі. У списку можуть бути старі записи, пропущені домени або кілька імен одного проєкту. Один знайдений домен не доводить, що інших немає.

Не плутайте цей пошук зі звичайним reverse DNS:

dig -x 203.0.113.10 +short

Команда запитує PTR для умовної документаційної адреси. Навіть для реальної адреси відповідь показала б налаштовані зворотні записи, а не всі сайти на сервері. Відсутність PTR теж не означає відсутності вебсайтів.

Журнали Certificate Transparency можуть допомогти знайти імена в публічно довірених сертифікатах. Але сертифікат не повідомляє повний поточний перелік virtual hosts та їхніх IP-адрес. Пошук IP у такому журналі не є універсальним способом отримати всі домени за цією адресою.

Адреса сайту й адреса DNS-сервера в dig

У виводі dig легко випадково взяти не ту адресу. Наприклад:

;; ANSWER SECTION:
www.example.net.  300 IN A 203.0.113.10
;; SERVER: 10.255.255.254#53(10.255.255.254) (UDP)

У цьому умовному прикладі 203.0.113.10 — повернута адреса сайту. 10.255.255.254 — resolver, якому клієнт поставив питання. Це може бути роутер, VPN або локальна віртуальна мережа.

Адреси з 10.0.0.0/8, 172.16.0.0/12 та 192.168.0.0/16 приватні й повторно використовуються в різних мережах. Результат їхнього пошуку в зовнішній базі не описує ваш домашній роутер і не встановлює власника віддаленого сайту.

Cloudflare: DNS, CDN і reverse proxy

Назва Cloudflare зустрічається в різних місцях, через що легко сплутати три окремі ролі:

Роль	Що відбувається
Публічний resolver `1.1.1.1`	Відповідає на DNS-запити користувача до різних доменів
Авторитетний DNS-хостинг	Зберігає записи зони власника домену та відповідає на запити до неї
Reverse proxy / CDN	Приймає HTTP/HTTPS-з’єднання від відвідувачів сайту

Можна користуватися Cloudflare як resolver і відкривати сайт, який взагалі не використовує його CDN. А сайт за Cloudflare CDN можна знайти через Google DNS, Quad9 або resolver провайдера. Вибір DNS у браузері не вмикає проксі для всього вебтрафіку.

DNS only та Proxied

Коли запис працює в режимі DNS only, DNS повертає налаштовану адресу сервера. Відвідувач підключається до неї напряму.

Для запису в режимі Proxied Cloudflare повертає адреси своєї edge-мережі. Браузер підключається до edge-сервера, а вже той за потреби звертається до origin — сервера, де розміщено застосунок. Різниця описана в документації proxy status.

DNS через DoH лише знаходить адресу. Для сайту за reverse proxy браузер встановлює окреме TLS-з’єднання з edge-сервером, а edge — окреме з origin

CDN кешує дозволений до кешування вміст на розподілених вузлах. Якщо об’єкт уже є в кеші, edge може віддати його без запиту до origin. Це залежить від правил, заголовків і типу відповіді: не будь-який HTML або приватний документ автоматично потрапляє в кеш.

Anycast дозволяє оголошувати ту саму сервісну IP-адресу з кількох вузлів мережі. Маршрутизація спрямовує клієнта до одного з них, але «найближчий» тут визначається мережевими маршрутами, а не просто відстанню на карті.

Спільні адреси роблять грубе IP-блокування менш вибірковим: разом із одним доменом воно може зачепити сторонні сайти. Це не робить таке блокування технічно неможливим і не означає, що кожен великий сайт обов’язково використовує CDN.

Де закінчується HTTPS

У звичайній конфігурації HTTPS reverse proxy існують два окремі TLS-з’єднання: браузер → edge та edge → origin. На edge перше з’єднання закінчується, тому проксі обробляє HTTP-запит у розшифрованому вигляді. Інакше він не міг би кешувати відповідь або перевіряти HTTP-заголовки.

Отже, HTTPS захищає дані на мережевому шляху, але TLS-проксі може читати шлях і параметри запиту, cookies та передане тіло. Слово «може» важливе: доступ до HTTP-даних не означає, що сервіс обов’язково зберігає все, бачить дані інших програм або може розшифрувати окреме шифрування всередині самого застосунку.

Другу ділянку також потрібно захищати. У Cloudflare режим Full (strict) шифрує з’єднання до origin і перевіряє його сертифікат. Замок у браузері сам по собі не підтверджує налаштування цього другого з’єднання. Режими TLS

Перевірка браузера, WAF і приховування origin

Сторінка «перевіряємо ваш браузер» належить до механізмів захисту від ботів або challenge-перевірок. WAF аналізує HTTP-запити за правилами безпеки; CDN відповідає за розподілену доставку й кешування. Ці можливості можуть працювати разом, але це різні функції.

Сам віджет Turnstile не доводить, що весь сайт проксіюється Cloudflare: Turnstile можна підключити окремо від CDN.

Проксійований DNS-запис перестає прямо повертати origin IP. Проте адреса може залишитися в історії DNS, інших неприкритих піддоменах, поштовій конфігурації або вихідних з’єднаннях застосунку. Проксі не стирає вже опубліковану інформацію. Якщо origin приймає вебзапити напряму від будь-кого, знання його адреси може дозволити обійти edge-захист. Тому на origin окремо обмежують доступ і перевіряють, хто має право звертатися до застосунку.

Чим це відрізняється від NAT і власної proxy-VPS

Звичайний NAT змінює мережеві адреси та, за потреби, порти пакетів. Він не завершує TLS і не читає HTTP-запит лише через трансляцію адрес. HTTPS reverse proxy, навпаки, приймає клієнтське з’єднання як сервер і створює окреме upstream-з’єднання. Саме це дає йому змогу працювати з вмістом. Механіку трансляції докладніше розглянуто в статті про NAT.

Окремий VPS із Nginx, Caddy або HAProxy може виконувати роль власного reverse proxy: DNS вказує на нього, а він передає запити до origin. Це корисно для централізованого TLS, маршрутизації та власних правил доступу. Але одна додаткова VPS не перетворюється на глобальну CDN і не гарантує захисту від перевантаження мережевого каналу. Ви керуєте проксі самі, а хостинг-провайдер усе одно залишається учасником інфраструктури.

Що змінюють VPN і Tor

DoH захищає визначення адреси. VPN і Tor змінюють також маршрут наступних з’єднань. Саме тому вони впливають на те, яку адресу бачить сайт, а зміна DNS — зазвичай ні.

VPN: тунель до іншої точки виходу

У типовому VPN-клієнті для виходу в Інтернет трафік потрапляє в зашифрований тунель до VPN-сервера. Далі сервер передає його до призначення. Для трафіку, який справді проходить цим тунелем, провайдер доступу бачить VPN endpoint і метадані тунелю, а не безпосередні IP-адреси відвіданих сайтів.

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

Точка довіри переміщується до VPN-провайдера: його сервер обробляє вихідний трафік і може бачити адреси призначення та незашифровані протоколи. HTTPS залишається потрібним — звичайний VPN не завершує TLS вебсайту й не отримує автоматично доступу до його HTTP-вмісту.

VPN не приховує HTTP-запит від reverse proxy самого сайту. Якщо ви відкрили сайт за CDN через VPN, CDN бачить адресу виходу VPN замість домашньої, але продовжує завершувати TLS і обробляти ваш запит. Авторизація у власному обліковому записі та cookies також не зникають через зміну IP.

Split tunneling, DNS-витоки та kill switch

За split tunneling частина програм або маршрутів іде поза VPN. Для корпоративного VPN це часто очікувана конфігурація: внутрішні ресурси доступні через тунель, решта — напряму. Тому фраза «VPN увімкнено» ще не описує маршрут усіх програм.

DNS-витік виникає, коли запити виходять шляхом, якого ви не очікували: наприклад, до resolver провайдера поза VPN. Окремий DoH браузера може передавати DNS сторонньому сервісу всередині тунелю. Це інший resolver, але не обов’язково витік до провайдера доступу. Для перевірки важливо дивитися і на адресата запиту, і на маршрут.

Kill switch обмежує вихід трафіку, коли захищений тунель недоступний. Його конкретна поведінка залежить від клієнта: обрив, ручне відключення, запуск системи й винятки можуть оброблятися по-різному. Перевіряйте IPv4 та IPv6, DNS і програми, виключені з тунелю. Сам перемикач не є доказом відсутності будь-яких витоків.

Tor Browser: маршрут через кілька вузлів

Для звичайного вебсайту Tor зазвичай будує ланцюжок із вхідного guard-вузла, проміжного relay та вихідного exit-вузла. Guard бачить адресу клієнта, exit встановлює з’єднання з потрібним сервером, а проміжний вузол передає трафік між ними. Ця архітектура розділяє знання про клієнта й призначення між різними учасниками.

Провайдер доступу зазвичай може бачити з’єднання з Tor, а звичайний сайт бачить адресу exit-вузла. Вихідний вузол може бачити незашифрований HTTP, тому HTTPS важливий і тут. Tor Browser також спрямовує визначення звичайних доменів через Tor; звичайний dig у сусідньому терміналі автоматично цього не робить.

Tor Browser захищає власний трафік, а не весь комп’ютер. Він також зменшує унікальність браузерного відбитка, але не гарантує абсолютної анонімності: обліковий запис, розкриті особисті дані, вразливості або аналіз трафіку можуть пов’язати дії з користувачем. HTTPS reverse proxy відвіданого сайту й далі бачить HTTP-запит після завершення TLS. Практичні межі описані в рекомендаціях Tor Browser.

Чому .onion не шукають через звичайний DNS

Адреси .onion — спеціальний простір імен Tor, а не зона, делегована звичайними кореневими DNS-серверами. Встановлення 1.1.1.1 або DoH не дає браузеру можливості відкрити onion-сервіс. Потрібен Tor-клієнт, наприклад Tor Browser.

Сучасна v3-адреса має 56 символів перед .onion і пов’язана з криптографічним ключем сервісу. Її не купують у звичайного реєстратора. Клієнт знаходить сервіс через механізми Tor; для такого з’єднання не потрібен вихід через exit-вузол у звичайний Інтернет. Опис onion services

Це приховує мережеві адреси клієнта й сервера один від одного на рівні такого з’єднання, але не стирає облікові записи, вміст повідомлень чи сліди роботи застосунку. Хостер VPS також не перестає контролювати інфраструктуру лише тому, що на ній запущено onion-сервіс. Помилка конфігурації, зовнішній ресурс або пряме вихідне з’єднання можуть розкрити додаткову інформацію.

Onion-адресу варто отримувати з офіційного каналу самого сервісу: схожа довга адреса може належати іншому власнику. Розгортання onion-сайту — окрема серверна задача; для розуміння DNS тут важливо, що звичайний resolver у пошуку такої адреси не бере участі.

Інструмент	Що змінює	Що залишається
DoH / DoT	Шифрує DNS до вибраного resolver	З’єднання із сайтом має видиму IP-адресу призначення
VPN для інтернет-трафіку	Передає охоплений трафік через тунель та іншу точку виходу	VPN-провайдер — учасник маршруту; сайт обробляє ваші запити
Tor Browser	Розподіляє маршрут браузера між вузлами, підтримує onion services	Інші програми не захищені автоматично; вміст доступний кінцевому сервісу

Діагностика і шпаргалка

Розділяйте рівні: чи працює мережевий маршрут, чи є DNS-відповідь, чи доступна потрібна адреса та чи проходить TLS.

Типові відповіді

Результат	Що перевіряти
`NOERROR` із відповіддю	Далі перевіряйте повернуту адресу та підключення
`NOERROR` без потрібних записів	Ім’я може існувати без запитаного типу; дивіться також CNAME і authority
`NXDOMAIN`	Імені немає за цією відповіддю; перевірте написання, split DNS і фільтрацію
`SERVFAIL`	Можливі проблеми DNSSEC, upstream або делегування
`REFUSED`	Сервер відмовив, наприклад через політику доступу до рекурсії
Timeout	Немає відповіді в межах очікування; це не DNS-код і не доказ відсутності імені

Перевірити адресу

dig codebyme.de A +noall +answer +comments

Окремо IPv6:

dig codebyme.de AAAA +noall +answer +comments

AAAA може існувати, навіть якщо IPv6-маршрут клієнта зламаний. DNS повідомив адресу, але з’єднання з нею не встановлюється. Порівняння через curl:

curl -4 -I https://codebyme.de

curl -6 -I https://codebyme.de

Помилка другого запиту в мережі без IPv6 очікувана. Не видаляйте AAAA домену лише тому, що один клієнт не має IPv6-підключення.

Порівняти resolver

dig @1.1.1.1 codebyme.de A

dig @8.8.8.8 codebyme.de A

Різні IP не завжди означають підміну: можливі CDN, балансування та різний стан кешу. Порівнюйте також status, TTL, CNAME-ланцюжок та авторитетну відповідь.

Перевірити авторитетний сервер

dig codebyme.de NS +short

Підставте ім’я одного з отриманих серверів замість ns.example.net:

dig @ns.example.net codebyme.de A +norecurse

ns.example.net — позначення для заміни, не справжній сервер codebyme.de. Прапорець aa у відповіді вказує на авторитетність; сам +norecurse не робить довільний сервер авторитетним.

TCP і DNSSEC

Запит через звичайний TCP/53:

dig +tcp @1.1.1.1 codebyme.de A

Для окремого запиту через DoT, якщо встановлено kdig із підтримкою TLS:

kdig @1.1.1.1 +tls +tls-ca +tls-hostname=cloudflare-dns.com codebyme.de A

+tls-ca вмикає перевірку ланцюжка сертифіката через довірені CA, а +tls-hostname задає очікуване ім’я сервера. Це перевірка саме запиту kdig через DoT, а не DoH і не конфігурації решти системи. Параметри наведено в довідці kdig.

Запросити DNSSEC-дані у validating resolver:

dig @1.1.1.1 codebyme.de A +dnssec

+dnssec встановлює DO-біт і просить DNSSEC-дані, але не перетворює dig на локальний валідатор. Прапорець ad повідомляє про перевірку resolver; довіра до цього прапорця потребує довіреного каналу до resolver. Відсутність ad сама по собі не доводить поломку: зона може бути непідписаною.

Порівняльний запит із вимкненою перевіркою на resolver, який підтримує CD-біт:

dig @1.1.1.1 codebyme.de A +dnssec +cdflag

Якщо без CD отримуєте SERVFAIL, а з ним — дані, перевіряйте DNSSEC: DS у батьківській зоні, ключі, підписи й час. Це діагностика, а не рекомендація постійно вимкнути валідацію.

Очистити потрібний кеш

У Linux із systemd-resolved:

sudo resolvectl flush-caches

У PowerShell:

Clear-DnsClientCache

На сучасних macOS поширена така процедура:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Кеш браузера очищається окремо його діагностичними засобами або перезапуском. Системна команда не очищає кеш публічного resolver та не виправляє запис на авторитетному сервері.

Побачити незашифрований DNS

На Linux із tcpdump:

sudo tcpdump -ni any 'udp port 53 or tcp port 53'

Такий дамп може містити імена з DNS-запитів. DoH за цим фільтром не видно; захоплення на фізичному інтерфейсі при VPN може показувати лише тунель. Обирайте точку спостереження відповідно до задачі.

Зміст

Що саме робить DNS

Що називають DNS-сервером

Шлях запиту і кешування

TTL і негативне кешування

Записи, зони й делегування

Звідки система бере DNS

Як подивитися поточну конфігурацію

Linux

Windows

macOS

Запит до конкретного сервера

Як змінити DNS у системі та роутері

Linux: NetworkManager

Linux: systemd-resolved

Windows

macOS

Роутер: дві різні настройки

Як вибрати публічний resolver

Звичайний DNS, DoT, DoH і DNSSEC

Звичайний DNS: запит у відкритому вигляді

DoH: DNS усередині HTTPS

DoT: окремий TLS-канал для DNS

DNSSEC: перевірка даних

Bootstrap: адреса самого DoH-сервера

DNS безпосередньо у браузері

Firefox

Chrome та Chromium-браузери

Перевірка саме браузера

DNS-блокування та приватність

VPN, внутрішні імена й captive portal

Після DNS: HTTPS, SNI та ECH

Що приховує HTTPS

Чому ім’я може бути видно через SNI

Що додає ECH

Скільки сайтів може бути за однією IP-адресою

Адреса сайту й адреса DNS-сервера в dig

Cloudflare: DNS, CDN і reverse proxy

DNS only та Proxied

Де закінчується HTTPS

Перевірка браузера, WAF і приховування origin

Чим це відрізняється від NAT і власної proxy-VPS

Що змінюють VPN і Tor

VPN: тунель до іншої точки виходу

Split tunneling, DNS-витоки та kill switch

Tor Browser: маршрут через кілька вузлів

Чому .onion не шукають через звичайний DNS

Діагностика і шпаргалка

Типові відповіді

Перевірити адресу

Порівняти resolver

Перевірити авторитетний сервер

TCP і DNSSEC

Очистити потрібний кеш

Побачити незашифрований DNS

Comments