Змініть DNS, щоб пришвидшити перегляд: налаштування, які мають значення (і ті, що ні)

DNS простими словами (і чому це відчувається як «швидкість»)

DNS — це телефонна книга для інтернету: вводите ім’я, отримуєте IP-адресу. Коли ваш браузер потребує example.com, він звертається до резольвера, отримує адресу (або кілька) і підключається.

Чому це важливо для «швидкості»? Тому що DNS часто виконується саме на початку завантаження сторінки, коли ви дивитесь на порожню вкладку. Навіть затримка 150–300 мс може створити відчуття, що весь інтернет повільний, навіть якщо решта сторінки завантажилася б швидко після встановлення з’єднань.

Сучасні сторінки також викликають багато DNS-запитів: головний сайт, CDN, зображення, шрифти, аналітика, рекламні мережі, вбудовані відео, «сповіщення про згоду», які потребують завантаження трьох постачальників. Один повільний резольвер може додати багато дрібних пауз.

Цікаві факти й короткий історичний контекст

• DNS стандартизували на початку 1980-х щоб замінити єдиний спільний файл hosts. Центральні файли не масштабуються; сюрприз.
• Коренева система DNS обслуговується 13 «логічними» кореневими серверами (A–M), але кожен anycast’иться в багато фізичних локацій по світу.
• TTL існує тому, що DNS розрахований на кешування: більшість запитів не повинні постійно потрапляти на авторитетні сервери.
• EDNS0 розширив DNS за межі початкових UDP-обмежень — важливо для сучасних функцій і DNSSEC.
• DNSSEC додає автентичність відповідям DNS, але збільшує розмір відповіді й обсяг валідації; зроблено правильно — варте того, зроблено неправильно — ламає речі.
• Anycast став суперсилою DNS: великі публічні резольвери розміщують той самий IP у багатьох місцях, тож зазвичай ви потрапляєте на близький вузол.
• Негативне кешування (кешування «такого імені не існує») існує, бо відсутність запису теж може бути дорогою.
• DoH/DoT стали мейнстрімом наприкінці 2010-х через зростаючі побоювання щодо конфіденційності та перехоплення; вони про конфіденційність, а не про якусь чарівну швидкість.

Одна максима надійності варта запам’ятати. Тут парафраз ідеї, приписаної Вернеру Вогелсу (CTO Amazon): Все ламається, весь час — тож проектуйте і керуйте так, ніби відмова нормальна. DNS — ідеальне місце для застосування цього підходу, бо DNS-збої виглядають як «інтернет не працює», навіть якщо ваша мережа в порядку.

Жарт №1: DNS як просити напрямків у місті — іноді найшвидший шлях просто «спитати того, хто тут живе», а не туристичну довідку.

Що може змінити DNS — і чого очікувати не варто

Це допоможе, коли…

• Резольвер вашого провайдера повільний або перевантажений. Ви побачите високі часи відповіді, таймаути або переривчасті збої DNS.
• Резольвер провайдера «помічливий» у поганому сенсі. Дехто переписує NXDOMAIN у рекламні сторінки або інжектує «допомогу пошуку». Це додає латентності і ламає припущення безпеки.
• Ви далеко від поточного резольвера. Якщо ви використовуєте корпоративний DNS через VPN із готелю через океан — кожен запит платить повний круг.
• У вашого резольвера погане кешування або погане пірінгування. Публічні резольвери з хорошим anycast і високим відсотком кеш-потраплянь можуть зменшити повторну латентність.
• Ваша локальна мережа неправильно перехоплює DNS. Деякі captive portal або «security appliances» затримують або ламають запити.

Це не допоможе, коли…

• Вузьке місце — пропускна спроможність або втрата пакетів. Якщо ви перевантажуєте канал 10 Mbps, DNS не ваш ворог.
• Сайт повільний. DNS може швидко вирішитися, але сервер відповідає 2 секунди. Це не проблема DNS; це проблема сервера/додатку/CDN.
• Браузер блокується чимось іншим. Затримки TLS, проблеми з QUIC, перевантаження CPU, неправильні проксі — DNS тут лише перша здогадка користувачів.
• Ви вже використовуєте хороший резольвер з кешем. Деякі зміни — це просто обмін одного компетентного постачальника на іншого.

Важлива рамка: «швидший перегляд» зазвичай означає зменшення time-to-first-byte (TTFB) або «паузи порожньої вкладки». DNS впливає на стадію перед встановленням з’єднання, а не на стадію завантаження. Це не кнопка турбо. Це набір рішень про те, де відбувається резолюція і як вона шифрується та поводиться при збоях.

Налаштування, які справді мають значення

1) Який резольвер ви використовуєте (і наскільки він близько)

Це очевидне. Резольвер з кращим anycast-покриттям, кращим кешем і менше збоями може скоротити час резолюції і зменшити кількість помилок.

Але «найкращий» залежить від географії та мережі. Той резольвер, що швидший у вашого сусіда, може бути посереднім для вашого маршруту. Вимірюйте у своїй мережі.

2) Де ви задаєте DNS: роутер проти пристрою проти VPN

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

VPN ускладнює ситуацію: багато клієнтів VPN штовхають DNS-настройки. Якщо перегляд уповільнений лише на VPN, вибір резольвера всередині тунелю може домінувати. «Швидкий» публічний резольвер не допоможе, якщо всі запити принуджено йдуть через корпоративний DNS в іншому регіоні.

3) Поведінка кешування DNS (локальний stub, кеш ОС, кеш браузера)

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

4) DNS over HTTPS (DoH) / DNS over TLS (DoT): компроміс приватність ↔ продуктивність

DoH/DoT шифрують DNS-запити, щоб запобігти спостереженню на шляху. Це може підвищити надійність у недружніх мережах (гостьовий Wi‑Fi, captive portal, сумнівні middlebox’и). Водночас це додає накладних витрат: нові TLS-сесії, інший маршрут, інколи більшу латентність ніж простий UDP до близького резольвера.

На практиці:

• DoH може бути швидким, якщо реалізовано з повторним використанням з’єднань і з близьким кінцевим пунктом.
• DoT може бути простішим для системного (OS) налаштування і часто має передбачувану поведінку.
• Простий DNS може бути найшвидшим в добре налаштованій мережі провайдера, але його легко перехопити.

5) EDNS Client Subnet (ECS) і локальність CDN

Це хитрий момент. CDN обирають «близькі» сервери частково на підставі мережевого розташування клієнта. Якщо ваш резольвер далеко і використовує ECS так, що неправильно відображає ваше місцезнаходження (або зовсім не використовує), вам можуть повернути CDN-ендпоінт, який не є близьким. Це може сповільнити доставку контенту, навіть якщо сам DNS швидкий.

Деякі публічні резольвери використовують ECS вибірково; деякі мінімізують його заради приватності. Це компроміс: точніша CDN-мапінг проти розкриття додаткового сигнала про місцезнаходження. Вимірюйте реальне завантаження сторінки і TTFB, а не тільки час DNS-запиту.

6) Поведінка при збоях: таймаути, відкат і кілька резольверів

Резольвери ламаються. Мережі ламаються. Ваш ноутбук перемикається між Wi‑Fi мережами, налаштованими людиною, яка вважає «гостьову мережу» приводом порушити основи.

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

Операційно бажано:

• Швидкий, надійний первинний.
• Резервний відмінний і незалежний, щоб бути корисним коли перший хворий.
• Таймаути, які швидко переключають (де це можна налаштувати).

Налаштування, які люди чіпають даремно (помітно не впливають)

«Я змінив DNS і моя швидкість завантаження подвоїлася»

Ні, не подвоїлася. DNS не змінює, скільки біт ваш провайдер доставляє. Що може статися: вас направили на кращий CDN-ендпоінт, тож завантаження з певного сервісу покращилося. Це не «DNS швидший», це «обрано інший сервер».

Рандомні списки «переможців бенчмарків DNS»

Бенчмарки часто тестують одиничну затримку запиту, інколи без поведінки кешування, що відповідає реальному перегляду. Реальний перегляд — це: кешовані відповіді, паралельні запити, повторне використання з’єднань і випадкова валідація DNSSEC. Ставтеся до списків «топ-10 найшвидших DNS» як до енергетичних напоїв: в основному маркетинг і легке почуття нагальності.

Зміна TTL на локальній машині

Більшість клієнтських TTL-ручок або не доступні, або не працюють так, як люди думають, або є чудовим способом створити дивні помилки. Браузери, системні stub-резольвери й локальні кеші мають власну політику.

Ручне редагування /etc/hosts заради продуктивності

Файл hosts призначений для фіксації чи тестування, не для продуктивності. Можна «прискорити» резолюцію, жорстко вказавши IP — звичайно, до першого випадку, коли IP зміниться або включать гео-маршрування. Тоді ви створите маленький генератор простою.

Жарт №2: Жорстко прописувати IP, щоб «уникнути DNS», — це як зняти пожежну сигналізацію, бо вона голосна.

Швидкий план діагностики

Якщо перегляд здається повільним, не починайте з перемикання резольверів, мов лотерейних номерів. Зробіть так:

По-перше: вирішіть, чи це DNS чи ні (30–60 секунд)

• Перевірте час DNS-запиту для кількох поширених доменів.
• Перевірте, чи затримка перед з’єднанням (порожня вкладка) або під час передачі (повільний прогрес).
• Порівняйте поведінку з VPN і без (якщо застосуємо).

По-друге: знайдіть, де саме виконується резолюція

• Чи пристрій використовує DNS роутера, DNS провайдера, публічний резольвер чи корпоративний VPN-резольвер?
• Чи DoH увімкнено в браузері і перебиває налаштування ОС?
• Чи є локальний кеш (systemd-resolved, dnsmasq, Unbound, Pi-hole)?

По-третє: протестуйте два кандидатні резольвери і виміряйте вплив на сторінку

• Виміряйте сиру латентність DNS і рівень таймаутів.
• Виміряйте різницю у CDN-мапінгу для кількох великих сайтів (перевірте, які IP ви отримуєте).
• Завантажте декілька репрезентативних сторінок і порівняйте «start render» і TTFB.

По-четверте: зміна тільки одного параметра, потім спостерігайте

• Віддавайте перевагу змінам на рівні роутера для домогосподарства.
• Для однієї машини змінюйте налаштування ОС.
• Обережно увімкніть DoH у декількох місцях (браузер + ОС + роутер), якщо ви не плануєте шарування.

Практичні дії: команди, виводи, рішення (12+)

Ось завдання, які я справді виконую, коли хтось каже «інтернет повільний». Кожне містить (1) команду, (2) що означає вивід, (3) яке рішення з цього випливає.

Завдання 1: Подивитися, яким DNS-сервером користується Linux-машина (systemd-resolved)

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 192.168.1.1
       DNS Servers: 192.168.1.1 1.1.1.1
DNS Domain: ~.

Значення: Активний резольвер — роутер (192.168.1.1) з вторинним публічним резольвером в списку. DNS-over-TLS вимкнено.

Рішення: Якщо DNS повільний, ви, ймовірно, залежите від роутера/шляху до провайдера. Протестуйте 192.168.1.1 проти публічного резольвера напряму за допомогою dig.

Завдання 2: Подивитися вміст /etc/resolv.conf (і чи щось його переписує)

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Feb  5 09:12 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Значення: Система використовує systemd stub-резольвер. Імовірно, nameserver у файлі буде 127.0.0.53.

Рішення: Не редагуйте цей файл очікуючи, що зміни збережуться. Налаштовуйте DNS через NetworkManager/systemd-resolved.

Завдання 3: Виміряти час DNS-запиту до поточного резольвера

cr0x@server:~$ dig +stats example.com
; <<>> DiG 9.18.24-1ubuntu1.3-Ubuntu <<>> +stats example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38451
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com.            2600    IN      A       93.184.216.34

;; Query time: 18 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
;; WHEN: Wed Feb 05 09:20:12 UTC 2026
;; MSG SIZE  rcvd: 56

Значення: 18 ms — нормально. Якщо бачите 150+ ms або таймаути, DNS може бути вашою «паузою порожньої вкладки».

Рішення: Якщо час запиту постійно низький, перестаньте звинувачувати DNS і піднімайтесь по стеку (TLS, маршрутизація, втрата пакетів).

Завдання 4: Порівняти резольвери поруч один з одним (публічний vs ISP/роутер)

cr0x@server:~$ for s in 192.168.1.1 1.1.1.1 8.8.8.8; do echo "== $s =="; dig +tries=1 +time=1 @${s} www.cloudflare.com | grep -E "Query time:|SERVER:"; done
== 192.168.1.1 ==
;; Query time: 24 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
== 1.1.1.1 ==
;; Query time: 13 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
== 8.8.8.8 ==
;; Query time: 31 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)

Значення: Тут 1.1.1.1 найшвидший для цієї мережі. Це не універсально.

Рішення: Якщо роутер/ISP постійно повільні або глючні, розгляньте перемикання на рівні роутера або ОС.

Завдання 5: Виявити переривчасті таймаути (те, що відчувають користувачі)

cr0x@server:~$ for i in $(seq 1 20); do dig +tries=1 +time=1 @192.168.1.1 www.google.com >/dev/null || echo "timeout on attempt $i"; done
timeout on attempt 7
timeout on attempt 12

Значення: Два таймаути з 20 — погано. Це перетвориться на «іноді сторінки зависають».

Рішення: Не оптимізуйте під 10 ms. Виправте надійність спочатку: змініть резольвер, зменшіть навантаження роутера або вирішіть проблеми каналу.

Завдання 6: Перевірити, чи DoH обходить налаштування ОС (приклад Firefox)

cr0x@server:~$ ps aux | grep -i firefox | head -n 2
cr0x    2134  6.2  3.1 3021456 512344 ?      Sl   09:10   1:22 /usr/lib/firefox/firefox
cr0x    4982  0.0  0.0   9220  2432 pts/0    S+   09:31   0:00 grep -i firefox

Значення: Це не доводить DoH, але показує, що Firefox запущено і може мати власні DNS-настройки.

Рішення: Якщо зміни ОС не впливають, перевірте DNS-настройки браузера (режим DoH) і політики підприємства.

Завдання 7: Підтвердити, яку IP-адресу повертає домен (підказка про CDN)

cr0x@server:~$ dig @1.1.1.1 www.netflix.com +short
203.0.113.41
203.0.113.52

Значення: Ви отримали два A-записи. Інший резольвер може повернути інші IP, потенційно направляючи вас на інші CDN-края.

Рішення: Якщо зміна DNS змінює ці IP, протестуйте реальну продуктивність (ping/traceroute/TTFB) перед тим, як святкувати.

Завдання 8: Виміряти встановлення з’єднання і TTFB (DNS vs TLS vs сервер)

cr0x@server:~$ curl -o /dev/null -s -w 'dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n' https://www.wikipedia.org/
dns:0.014 connect:0.041 tls:0.112 ttfb:0.238 total:0.402

Значення: DNS зайняв 14 ms; TLS і відповідь сервера домінують. Зміна DNS мало б вплинути на загальний час тут.

Рішення: Якщо time_namelookup великий (наприклад 0.2–1.0s), DNS — реальний внесок. Якщо ні — дивіться вище по стеку.

Завдання 9: Перевірити втрачені пакети/латентність до резольвера (поганий шлях?)

cr0x@server:~$ ping -c 5 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=12.4 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=13.1 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=12.7 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=12.9 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=57 time=55.2 ms

--- 1.1.1.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 12.4/21.3/55.2/16.8 ms

Значення: Втрат немає, але є джиттер (один стрибок до 55 ms). Іноді такі сплески нормальні; постійні втрати — ні.

Рішення: Якщо є втрата до резольвера, зміна резольвера може допомогти — але також підозрівайте якість Wi‑Fi, bufferbloat або проблеми у провайдера.

Завдання 10: Очистити кеші при тестуванні (щоб не тестувати свій кеш)

cr0x@server:~$ sudo resolvectl flush-caches
cr0x@server:~$ resolvectl statistics
DNSSEC supported: no
Transactions: 146
Cache size: 0
Cache hits: 0
Cache misses: 12

Значення: Кеш очищено; наступні запити будуть «холодними» і правдивіше відобразять поведінку резольвера/мережі.

Рішення: Використовуйте тести з холодним кешем для усунення проблем; використовуйте теплий кеш, щоб зрозуміти повсякденний перегляд.

Завдання 11: Перевірити системні логи на помилки DNS (Linux)

cr0x@server:~$ sudo journalctl -u systemd-resolved --since "30 minutes ago" | tail -n 8
Feb 05 09:07:41 server systemd-resolved[812]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 192.168.1.1.
Feb 05 09:08:03 server systemd-resolved[812]: DNS server 192.168.1.1 does not support DNSSEC, disabling validation.
Feb 05 09:10:22 server systemd-resolved[812]: Server returned error NXDOMAIN, retrying transaction 21961.
Feb 05 09:11:05 server systemd-resolved[812]: Timeout reached while resolving 'fonts.gstatic.com'.

Значення: Деградований EDNS0 і таймаути свідчать, що DNS-форвардер роутера ненадійний або пошкоджений.

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

Завдання 12: Проінспектувати поведінку DNS роутера з клієнта (форвардить чи сам резолвить?)

cr0x@server:~$ dig +norecurse @192.168.1.1 example.com | grep -E "ra;|flags:"
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

Значення: Прапор ra вказує, що рекурсія доступна; роутер поводиться як рекурсивний резольвер/форвардер.

Рішення: Якщо роутер повільний, можна або (a) змінити його upstream DNS, або (б) не використовувати його для DNS і вказати публічні резольвери напряму.

Завдання 13: Протестувати DNS over TLS на латентність (якщо у вас локальний stub як Unbound)

cr0x@server:~$ kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com example.com
;; TLS session (TLS1.3)-(ECDHE)-(RSA)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 12345
;; QUESTION SECTION:
;; example.com. IN A
;; ANSWER SECTION:
example.com. 2600 IN A 93.184.216.34
;; Received 56 B
;; Time 29 ms

Значення: DoT працює і тут трохи повільніший за простий UDP (поширено). Вартість може зникнути при повторному використанні сесій.

Рішення: Обирайте DoT/DoH заради приватності і цілісності в ненадійних мережах; не очікуйте за замовчуванням, що це швидше.

Завдання 14: Перевірити, чи VPN змушує використовувати певний DNS

cr0x@server:~$ resolvectl dns tun0
Link 7 (tun0): 10.60.0.53

Значення: DNS для VPN-інтерфейсу встановлено на корпоративний резольвер. Навіть якщо ви змінили Wi‑Fi DNS, трафік VPN може і надалі використовувати це.

Рішення: Якщо продуктивність падає на VPN, потрібні політики split-DNS/split-tunnel або ближчий корпоративний резольвер — не інший публічний DNS.

Три корпоративні історії з практики

Історія 1: Інцидент через неправильне припущення («кеш DNS вирішить»)

Середня SaaS-компанія мігрувала частину стеку на новий рівень балансувальників. На папері вони зробили «правильно»: зменшили TTL для api.company.tld, щоб швидко переключитися. Припущення було, що клієнти поважатимуть новий TTL і перехід пройде гладко.

Настав день cutover. Рівні помилок зросли, потім коливалися. Деякі клієнти потрапляли на новий VIP, інші залишалися на старому. Інженери дивилися на графіки, які нагадували поганий кардіограму. Балансувальники були в порядку. Сервери — теж. Мережа — теж. «Інтернет» був не в порядку — але тільки для деяких користувачів і не завжди.

Що сталося: значна частина клієнтів ніколи не побачила нової поведінки з низьким TTL. Дехто був за рекурсивними резольверами, які обрізали мінімальні TTL. Деякі корпоративні мережі мали агресивні кеш-проксі. Декілька мобільних операторів поводилися «легально-особливим» способом. Тим часом внутрішні сервіси компанії використовували інший шлях резолюції, тож внутрішнє тестування виглядало добре.

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

Історія 2: Оптимізація, що відбилася боком (DoH усюди, тепер з загадковою латентністю)

Глобальне підприємство розгорнуло «оновлення приватності» на кінцевих точках: увімкнути DoH у браузері, увімкнути DoT на рівні ОС і вказати все на сторонній резольвер. Безпекова команда хотіла припинити локальний мережевий аналіз DNS. Намір був розумний. План розгортання — ні.

За тиждень тикети helpdesku зрісли: «іноді сайти довго починають завантажуватися». Не постійно. Не у всіх. Більше в регіональних офісах зі старими фаєрволами. Команди звинувачували ISP, потім провайдера резольвера, потім браузер, потім фазу місяця. Розбиратися було важко, бо проблема виглядала як «загальна повільність».

Фактичний режим відмови: мережеві security middlebox-и періодично втручались у довгоживучі HTTPS-з’єднання до DoH-ендпоінта, особливо коли кінцева точка використовувала HTTP/2 мультиплексування. Коли ті з’єднання зависали, DNS-запити накопичувалися за ними. OS-рівневий DoT шар також створював більше одночасних зашифрованих сесій, ніж очікували, і старі фаєрволи почали rate-limitити те, що бачили як підозрілий сплеск шифрованого трафіку.

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

Історія 3: Нудна, але правильна практика, що врятувала день (локальний кеш + адекватні таймаути)

Ритейлер мав тисячі POS-терміналів і тонких клієнтів у магазинах, багато з яких мали ненадійний last-mile. Вони не робили нічого екзотичного. Запустили невеликий локальний кешуючий резольвер у кожному магазині, форвардячі запити до двох upstream-резольверів через WAN.

Одного вечора upstream ISP мав інцидент і виникла переривчаста втрата пакетів. Магазини без локального кешу (залишкова частина) бачили UI-стали і помилки «неможливо підключитись», бо кожний DNS-запит мусив проходити по хворому каналу. Магазини з локальним кешем працювали довше, бо поширені імена були вже в локальному кеші. Коли кеши сходили, збої все одно траплялися — але рідше й менш помітно для користувачів.

Що це зробило — не магія. Це: (1) кеш розміром під звичний набір імен магазину, (2) upstream-и з різних мереж, (3) таймаути, налаштовані так, щоб швидко відкатуватись, але не займатись через дрібний джиттер. Ось і все. Ніяких геройств. Просто дисциплінована експлуатація.

WAN-інцидент усе ще був. Але це не перетворилося на повний бізнес-аутейдж. Іноді «нудно» — найвища похвала для продуктивних систем.

Поширені помилки: симптом → корінна причина → виправлення

1) Симптом: Перша завантажена сторінка зависає, перезавантаження — швидко

Корінна причина: Холодний DNS-кеш + повільний резольвер або переривчасті таймаути. Після перезавантаження ім’я кешується (ОС/браузер), і здається, що «полагодилося».

Виправлення: Виміряйте холодні DNS-запити (Завдання 5). Переключіться на надійний резольвер. Переконайтесь, що локальний кеш не вимкнений або не очищується постійно.

2) Симптом: Деякі сайти швидкі, деякі — дивно повільні після зміни DNS

Корінна причина: Різна CDN-мапінг через розташування резольвера/ECS; вас направили на менш оптимальний edge.

Виправлення: Порівняйте IP (Завдання 7). Виміряйте TTFB (Завдання 8) і якість маршруту. Якщо CDN-мапінг гірший, поверніть або оберіть резольвер ближчий до вашої мережі.

3) Симптом: Все ламається тільки в певних Wi‑Fi мережах (готелі, аеропорти)

Корінна причина: Captive portal перехоплює DNS або блокує DoH/DoT ендпоінти, що викликає таймаути.

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

4) Симптом: Ви змінили DNS на роутері, але нічого не змінилося

Корінна причина: Пристрої використовують жорстко прописані DNS (поширено в IoT) або браузерний DoH перебиває налаштування ОС/роутера.

Виправлення: Підтвердіть активний резольвер за допомогою resolvectl status (Завдання 1) або DNS на інтерфейсі (Завдання 14). Відкоригуйте налаштування пристроїв або браузера відповідно.

5) Симптом: Випадкові NXDOMAIN або «сайт недоступний» для легітимних доменів

Корінна причина: Неправильна валідація DNSSEC на резольвері або форвардер роутера, який некоректно обробляє EDNS0/великий розмір відповіді.

Виправлення: Перевірте логи (Завдання 11). Спробуйте інший резольвер напряму (Завдання 4). Якщо роутер не справляється з сучасним DNS — обійдіть його або замініть прошивку/апарат.

6) Симптом: Перегляд повільніший на VPN

Корінна причина: DNS спрямовано через віддалений корпоративний резольвер; кожен запит платить WAN-латентність. Іноді split-DNS налаштовано неправильно, і всі запити йдуть через тунель.

Виправлення: Ідентифікуйте DNS VPN (Завдання 14). Виправте політику split-tunnel/split-DNS; додайте регіональні резольвери; переконайтесь, що клієнт VPN не переписує DNS неправильно.

7) Симптом: Ви увімкнули DoH і деякі внутрішні сайти не резолвляться

Корінна причина: Внутрішні зони DNS доступні тільки через корпоративні резольвери. DoH шле запити до публічних резольверів, які не бачать приватних зон.

Виправлення: Вимкніть DoH у мережах, де потрібен внутрішній DNS, або використайте керований DoH, який може резолвити внутрішні зони, або впровадьте політики OS зі split-DNS.

8) Симптом: «DNS в порядку» за бенчмарком, але перегляд все одно повільний

Корінна причина: Бенчмарк тестував теплий кеш або один домен; реальний перегляд включає багато паралельних запитів, TCP/TLS і серверну відповідь.

Виправлення: Використовуйте curl таймінги (Завдання 8) і реальні тести сторінок. Визначте, чи домінує DNS, з’єднання, TLS або сервер.

Контрольні списки / покроковий план

План A: Хочете зрозуміти, чи допоможе зміна DNS

1. Виміряйте базову латентність і надійність DNS. Запустіть Завдання 3 і Завдання 5 проти поточного резольвера.
2. Виміряйте, де витрачається час при завантаженні сторінки. Запустіть Завдання 8 для кількох репрезентативних сайтів.
3. Виберіть два кандидатні резольвери (один публічний, один — ваш поточний/ISP) і порівняйте їх за Завданням 4.
4. Перевірте чутливість CDN-мапінгу. Порівняйте IPи за Завданням 7 принаймні для одного CDN-важкого сайту.
5. Змініть DNS тільки в одному місці (роутер або ОС, не обидва одночасно), потім повторіть вимірювання.

План B: Найбезпечніша конфігурація «поставив — забув» для дому

1. Задайте DNS на роутері, щоб усі пристрої отримали користь.
2. Використовуйте надійний anycast публічний резольвер або DNS провайдера, якщо він добре тестується і не змінює відповіді.
3. Налаштуйте резервний резольвер, який справді незалежний.
4. Якщо вам потрібна приватність у ненадійних мережах — увімкніть DoH/DoT на ОС або в браузері, але уникайте подвійного шару шифрування, якщо це не навмисно.
5. Пере-тестуйте після змін завданнями 4 і 8.

План C: Ви керуєте невеликою офісною мережею і хочете менше заявок в підтримку

1. Запустіть локальний кешуючий резольвер (dnsmasq/Unbound) на стабільному пристрої або аплайансі роутера.
2. Форвардьте на два upstream-резольвери з різних мереж.
3. Тримайте таймаути достатньо низькими, щоб швидко відкатуватись, але не настільки низькими, щоб протоколювати дрібний джиттер як помилку.
4. Логируйте помилки DNS і стежте за сплесками (шаблон Завдання 11, але для вашого демона).
5. Документуйте «який DNS ми використовуємо» у документації для прийому на роботу. Це здається очевидним, поки ви не в інциденті.

План D: Ви змінили DNS і стало дивно (відкат без драми)

1. Спочатку відкотіть browser-level DoH (воно найімовірніше здивує вас).
2. Потім поверніть DNS ОС до DHCP-параметрів і перевірте.
3. Якщо потрібно, відкотіть зміни DNS на роутері.
4. Підтвердіть активний резольвер (Завдання 1) і повторіть Завдання 8, щоб переконатися в покращенні.

ЧаПи

1) Чи збільшить зміна DNS мою інтернет-швидкість?

Ні. Це може зменшити затримку «початку завантаження», пришвидшивши резолюцію або уникнувши таймаутів. Але це не збільшить пропускну здатність.

2) Чому після зміни DNS перегляд здається швидшим, хоча бенчмарки схожі?

Бо важливіше надійність і кешування, ніж одне значення латентності. Менше таймаутів і кращі потрапляння в кеш дають відчуття «швидше». Також різний CDN-мапінг може змінити реальну швидкість завантаження.

3) Де краще задавати DNS — на роутері чи на кожному пристрої?

На роутері — якщо хочете послідовності і менше налаштувань на пристроях. На пристрої — якщо потрібні винятки (робочий ноутбук, тестування, батьківський контроль). Але пам’ятайте, що браузерний DoH може перебити обидва варіанти.

4) Чи завжди краще DNS over HTTPS?

Краще для приватності від локального мережевого спостереження, часто краще проти перехоплення. Не завжди швидше і може зламати captive portal або внутрішній DNS без належної конфігурації.

5) Чи потрібен мені DNSSEC?

Як користувач, вам головне, щоб резольвер коректно валідовував DNSSEC. DNSSEC — не про швидкість; воно про запобігання певним видам підміни DNS. Якщо валідація зламана, це може викликати відмови — тому обирайте резольвер з хорошою репутацією.

6) Чи бачить провайдер, які сайти я відвідую, якщо я використовую публічний DNS?

Провайдер усе ще бачить IP-адреси, до яких ви підключаєтесь, і з урахуванням SNI/ESNI/ECH може робити висновки про призначення. Приватність DNS допомагає, але не робить вас невидимим.

7) Чому деякі пристрої ігнорують мої налаштування DNS?

Деякі мають жорстко прописані резольвери, деякі використовують DoH вбудовано в додатки, а деякі надають пріоритет IPv6 DNS, отриманим через router advertisements. Діагностуйте, перевіривши, який резольвер реально використовується (Завдання 1/14) і тестуючи з самого пристрою.

8) Чи допомагає зміна DNS у іграх?

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

9) Яка найпростіша безпечна зміна для більшості людей?

Переключіться з глючного DNS роутера/провайдера на надійний anycast публічний резольвер на роутері, додайте резервний і перевірте пару вимірів (Завдання 4 і Завдання 8).

10) Чому я отримую різні IP для одного домену від різних резольверів?

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

Наступні кроки, які можна виконати сьогодні

1. Запустіть одне вимірювання, що ріже здогадки: використайте рядок curl таймінгів (Завдання 8). Якщо DNS < 30 ms і стабільний, не витрачайте день на пошук резольвера.
2. Якщо DNS повільний або глючний — доведіть це: запустіть цикл з 20 спроб (Завдання 5) проти поточного резольвера.
3. Протестуйте два альтернативні резольвери: порівняйте часи запитів (Завдання 4) і перевірте таймаути. Оберіть резольвер, який швидкий і надійний у вашій мережі.
4. Змініть DNS в одному місці: роутер для домогосподарства, ОС для одиночної машини, політика VPN для корпоративних налаштувань. Уникайте насладання браузерного DoH, якщо це не обдумано.
5. Пере-тестуйте після зміни: очистіть кеши (Завдання 10) і знову запустіть Завдання 8 для кількох сайтів, які ви справді використовуєте.

Якщо нічого не робитимете більше — зробіть це: перестаньте трактувати DNS як забобон. Вимірюйте, змінюйте одну змінну, знову вимірюйте. Так ви не перетворите «оптимізації швидкості» на нічні інцидентні дзвінки.