Як працює DNS: повний гайд для власника сайту у 2026 році

Коротко про головне: 

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

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

Розібратися, як працює DNS на практиці, а не лише в теорії, — мета цього гайду: повний довідник записів, окремий розгорнутий розділ про SPF, DKIM і DMARC для пошти, безпечний переїзд без простою, реальний вплив DNS на SEO, безпеку домену й розбір найчастіших помилок на кшталт DNS_PROBE_FINISHED_NXDOMAIN.

Що таке DNS простими словами

DNS (Domain Name System) перетворює доменне ім’я на IP-адресу. Коли ви вводите в браузері example.com, саме DNS підказує, що цей домен насправді розташований за адресою на кшталт 192.0.2.10, куди й треба надіслати запит.

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

Отже, що таке DNS простими словами? Це система адресації інтернету, без якої довелося б запам’ятовувати цифри замість імен сайтів.

Як це працювало до появи DNS

До появи DNS у 1984 році відповідність імен та адрес зберігалася в одному текстовому файлі hosts.txt, який регулярно оновлював і розсилав усім вручну Стенфордський дослідницький інститут, — така схема працювала, поки мережа налічувала сотні комп’ютерів, але втратила ефективність, коли їх кількість зросла до тисяч.

З чого складається DNS: сервери та ієрархія

Щоб зрозуміти, як працює DNS на рівні інфраструктури, варто розібрати чотири типи серверів, кожен із яких відповідає за свою частину пошуку: 

• рекурсивний резолвер; 
• кореневі сервери; 
• TLD; 
• авторитетні сервери домену. 

Далі розкажемо, як саме вони взаємодіють між собою за один типовий запит.

Рекурсивний резолвер, кореневі, TLD та авторитетні сервери

Рекурсивний резолвер — це перша точка контакту, зазвичай сервер провайдера чи публічний DNS на кшталт 8.8.8.8, який бере на себе весь пошук замість пристрою користувача. 

Розглянемо домен site.com.ua: резолвер спершу звертається до кореневого вузла. Той не знає потрібної адреси, але спрямовує запит до TLD-сервера зони .ua (а той — до com.ua). Далі ланцюжок веде до авторитетного джерела конкретного домену. Саме воно зберігає всі записи й надає фінальну відповідь з IP-адресою, а не проміжні ланки чи резолвер. 

Як браузер знаходить IP-адресу: шлях запиту за 6 кроків

Процес перетворення доменного імені на мережеву адресу відбувається в кілька послідовних етапів:

1. Перевірка кешу: браузер з’ясовує, чи не запитували цей домен нещодавно.
2. Звернення до резолвера: якщо збережених даних немає, запит спрямовується до рекурсивного вузла (провайдера чи публічного DNS).
3. Запит до кореня: резолвер опитує кореневий сервер, який спрямовує його до відповідної зони TLD.
4. Пошук у TLD: зона TLD (наприклад, .ua чи .com) перенаправляє запит на авторитетне джерело домену.
5. Отримання відповіді: авторитетна інстанція повертає резолверу фінальну IP-адресу.
6. Кешування та передача: резолвер надсилає результат браузеру й зберігає його на час, заданий TTL-записом (завдяки цьому повторне завантаження відбувається значно швидше).
7. З’єднання: отримавши підтверджений IP, браузер підключається до хоста для завантаження контенту.

Отримавши заповітний IP, браузер одразу встановлює з’єднання з потрібним сервером для завантаження контенту сайту. 

DNS-записи: повний довідник

DNS-записи — це чіткі інструкції в конфігурації домену, які визначають маршрутизацію вебтрафіку, корпоративної пошти та підтвердження SSL-сертифікатів.

По суті, DNS — це не просто адреса сервера, а цілий набір різнотипних інструкцій, і базові туторіали зазвичай зупиняються лише на п’яти з них (A, AAAA, CNAME, MX, TXT), хоча в реальній роботі з доменом рано чи пізно знадобляться й інші, — нижче представлений повний набір із дванадцяти типів записів:

Тип запису	Що робить	Приклад значення	Коли потрібен
A	Вказує на IPv4-адресу сервера	192.0.2.10	Завжди — базова адреса сайту
AAAA	Вказує на IPv6-адресу сервера	2606:4700::6810:85e5	Бажано мати поруч з A-записом
CNAME	Створює псевдонім, що вказує на інше доменне ім’я	www CNAME example.com.	Піддомени, зовнішні сервіси
MX	Направляє пошту на поштовий сервер	10 mail.example.com.	У тому разі, якщо на домені є пошта
TXT	Службовий текстовий запис: верифікація, SPF/DKIM/DMARC	v=spf1 include:_spf.google.com ~all	Пошта, підтвердження власності домену
NS	Вказує, які сервери авторитетні для зони домену	ns1.hostingprovider.com.	Завжди — визначає, хто керує зоною
SOA	Зберігає службові параметри зони: серійний номер, TTL	ns1… admin… 2026091001 …	Створюється автоматично для зони
SRV	Вказує хост і порт для конкретного сервісу	_sip._tcp 10 5 5060 sip.example.com.	Телефонія, деякі месенджери
CAA	Обмежує перелік центрів сертифікації для домену	0 issue “letsencrypt.org”	Захист від чужого SSL-сертифіката
HTTPS/SVCB	Одразу передає браузеру параметри з’єднання	1. alpn=h2,h3	Прискорення HTTPS-з’єднання
PTR	Зворотний запис: IP-адреса → доменне ім’я	10.2.0.192.in-addr.arpa → mail.example.com.	Розсилки, репутація поштового сервера

А та AAAA — адреса сервера

A-запис вказує на IPv4-адресу сервера (наприклад, 192.0.2.10), а AAAA-запис — те саме, але для довшого формату IPv6. У 2026 році варто мати обидва: частина мобільних операторів і мереж уже працює на IPv6 за замовчуванням. Без AAAA-запису такі користувачі підключаються через повільніші проміжні шлюзи трансляції адрес, а не напряму.

CNAME — псевдонім

CNAME створює псевдонім для домену — замість того щоб дублювати IP-адресу в окремому записі, піддомен просто вказує на інше доменне ім’я. Якщо воно зміниться, оновлювати доведеться лише один запис, а не всі псевдоніми одразу. 

Типове застосування — піддомен www, що вказує на кореневий домен, підключення зовнішніх сервісів на кшталт систем розсилок чи хелпдесків, технічні піддомени CDN. Обмеження варто пам’ятати одразу: CNAME не можна поставити на кореневий домен (голий example.com без www) — там за стандартом мають бути тільки A, AAAA чи спеціальні ALIAS-записи окремих провайдерів. 

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

MX — поштові сервери

MX-запис направляє пошту на потрібний сервер, і в нього завжди є числовий пріоритет: чим менше значення, тим вищий пріоритет, і саме до цього вузла спершу намагається достукатися відправник. 

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

TXT — службові записи

TXT-запис — це довільний текстовий рядок у зоні домену, який використовують для найрізноманітніших цілей: підтвердження прав на вебресурс у Google Search Console чи інших сервісах, а також для трьох найважливіших із погляду поштових налаштувань елементів — SPF, DKIM і DMARC. Технічно вони також є різновидом TXT, але з чітко визначеним форматом вмісту, тому й розглядаються далі окремо. 

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

NS і SOA — хто керує зоною

NS-запис вказує, які сервери є авторитетними для зони домену, — подивитися його можна в панелі реєстратора чи через будь-який DNS checker, ввівши домен. Саме тут найчастіше ламається переїзд на новий хостинг. Якщо змінити NS-записи на нового провайдера, а той ще не встиг підняти повну копію всіх даних зі старого майданчика (MX, TXT, піддомени), частина сервісів домену на якийсь час просто перестає працювати. 

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

SRV — сервіси

SRV-запис вказує конкретний хост і порт для окремого сервісу на домені. На практиці зустрічається рідше за інші типи, здебільшого в налаштуваннях IP-телефонії (SIP) чи деяких корпоративних месенджерів і протоколів на кшталт XMPP, де клієнту потрібно знайти сервер автоматично, без ручного введення адреси.

CAA — хто може видавати SSL-сертифікат вашому домену

CAA-запис обмежує перелік центрів сертифікації, яким дозволено видавати SSL для домену. Якщо в записі вказано лише «letsencrypt.org», жодна інша організація технічно не зможе випустити SSL-сертифікат на цей домен (навіть у разі помилки чи спроби зловживання з чужого акаунту). 

Без CAA-запису це не заборонено явно, теоретично дозволено будь-якому центру сертифікації. Хоча на практиці зловживання рідкісні, CAA закриває саме цю малоймовірну, але реальну діру.

HTTPS і SVCB — сучасні записи для швидкого з’єднання

HTTPS-запис (і його загальна форма SVCB) дозволяє браузеру одразу дізнатися параметри з’єднання, зокрема, які протоколи підтримує сервер (HTTP/2, HTTP/3), не витрачаючи на це окремий проміжний крок після звичайного DNS-запиту. 

Простими словами: браузер отримує потрібну інформацію за один раз замість двох, і з’єднання встановлюється на частку секунди швидше — непомітно для одного відвідування, але відчутно в сукупності на мобільних мережах із високою затримкою.

PTR — зворотний DNS

PTR виконує зворотну задачу до звичайного A-запису: перетворює IP-адресу назад на доменне ім’я. 

Найпрактичніше застосування — розсилки й поштові сервери: більшість захисних систем перевіряють, чи має IP-адреса відправника коректний зворотний DNS. За відсутності PTR-запису лист із набагато вищою ймовірністю потрапляє в спам чи взагалі відхиляється, причому незалежно від того, наскільки правильно налаштовані SPF і DKIM.

DNS для пошти: SPF, DKIM і DMARC

SPF, DKIM і DMARC — три TXT-записи, без яких пошта з власного домену у 2026 році з високою ймовірністю потрапляє в спам або взагалі не доходить до Gmail, Yahoo чи Outlook. 

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

Що робить кожен із трьох записів

SPF визначає авторизованих відправників — список IP-адрес і сервісів, яким дозволено надсилати пошту від імені вашого домену. Приклад рядка:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Тут домен дозволяє розсилку через інфраструктуру Google Workspace і сервіс SendGrid, а символ ~all у кінці означає «м’яко відхиляти» повідомлення від усіх інших джерел, не описаних вище.

DKIM завіряє вихідні листи цифровим підписом, який підтверджує, що їх вміст не змінився дорогою від відправника до отримувача. Запис виглядає так:

selector._domainkey.example.com TXT “v=DKIM1; k=rsa; p=MIGfMA0GCSq…”

Частина «selector» — довільне ім’я, яке задає поштовий провайдер (наприклад, google чи s1), а після p= йде сам публічний ключ для верифікації вихідних повідомлень.

DMARC задає реакцію на непройдену перевірку (що робити з листом, який не пройшов SPF чи DKIM: пропустити, позначити підозрілим чи відхилити повністю). Приклад:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com

Тут p=quarantine означає, що листи, які не пройшли перевірку, підуть у спам отримувача, а не будуть заблоковані повністю — це типовий безпечний старт перед переходом на суворіший p=reject.

Вимоги Google, Yahoo і Microsoft до відправників

Вимоги до розсилок, за даними Google, діють із лютого 2024 року: Gmail вимагає від масових відправників (від 5000 листів на день на особисті скриньки сервісу з одного домену) автентифікації як через SPF, так і через DKIM одночасно, опублікованого DMARC-записом рівня щонайменше p=none, скарг на спам нижче 0,1% (і в жодному разі не вище 0,3%) та підтримки one-click unsubscribe для маркетингових листів. 

З листопада 2025 року Google посилила застосування цих правил: повідомлення, що не відповідають вимогам, можуть отримувати тимчасову чи постійну відмову в доставці, а не просто листи потрапляють у спам. 

Yahoo висуває аналогічні вимоги без чіткого порогу в кількості листів, орієнтуючись на «значний обсяг» розсилки. За даними Microsoft, компанія приєдналася до цих вимог пізніше: з 5 травня 2025 року листи від масових відправників (від 5000 на день) на Outlook.com, Hotmail і Live.com, що не пройшли SPF, DKIM і DMARC-вирівнювання, отримують повну відмову в доставці з кодом помилки 550 5.7.515, а не потрапляють у папку «Спам», як планувалося спочатку. 

Важливо розуміти: ці пороги формально стосуються масових відправників, але правильно налаштовані SPF, DKIM і DMARC покращують доставку пошти для домену будь-якого розміру, а не лише для розсилок на тисячі одержувачів.

Як перевірити свої записи та що робити, якщо листи в спамі

Практичний чекліст перевірки — почніть із будь-якого публічного DNS checker (наприклад, mxtoolbox.com чи dmarcian.com), введіть назву ресурсу й перевірте SPF, DKIM та DMARC окремо — аналізатор одразу вкаже на синтаксичні помилки, якщо такі є:

1. Два SPF-записи на одному домені — найчастіша прогалина: допускається лише один SPF TXT-запис, і якщо їх два, то обидва стають недійсними. Всі потрібні джерела треба об’єднати в один рядок через include.
2. Застарілі IP-адреси в SPF — сервіс розсилок чи CRM могли змінити діапазони, поки конфігурація залишалася старою. Параметри варто звіряти з актуальною документацією кожного підключеного інструменту раз на кілька місяців.
3. DMARC без звітів — додайте rua= з власною поштою в DMARC-запис, щоб отримувати щоденні звіти про те, хто й звідки намагається надсилати листи від імені вашого домену.
4. DKIM-селектор не активовано в поштовому сервісі — сам TXT-запис може бути правильним, проте, якщо в конфігурації провайдера цифровий підпис не увімкнути примусово, це налаштування залишиться неактивним.

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

TTL і поширення змін: чому після правок сайт «то є, то немає»

TTL (Time To Live) визначає час життя запису в кеші — скільки секунд резолвери по всьому світу можуть використовувати вже отриману відповідь, не питаючи авторитетний сервер повторно. 

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

Практична порада: за добу до запланованих серйозних змін (переїзд, зміна MX) знизьте TTL до 300 секунд (5 хвилин). Це змусить резолвери частіше звіряти актуальність запису, і після самої зміни нове значення розійдеться набагато швидше. 

Після завершення переїзду TTL варто повернути до звичних значень (3600 чи вище) — надто низький показник постійно збільшує навантаження на авторитетні сервери й трохи уповільнює кожен перший запит, бо кеш доводиться оновлювати частіше, ніж потрібно.

Як перенести сайт на новий хостинг без простою

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

Чекліст переїзду

Дотримання чіткої послідовності технічних кроків допоможе мінімізувати час простою сайту та уникнути втрати даних і поштових повідомлень:

1. Знизити TTL усіх ключових записів (A, MX) до 300 секунд щонайменше за добу до переїзду.
2. Підняти повну копію сайту на новому сервері й протестувати її роботу за прямою IP-адресою чи тестовим доменом хостера.
3. Перевірити новий сервер через файл hosts на своєму комп’ютері, поки в загальному DNS усе ще діють старі записи.
4. Окремо перенести й перевірити MX-записи — про це найчастіше забувають, через що корпоративна пошта починає втрачатися першою. 
5. Змінити NS-записи (якщо переносите керування зоною на нового провайдера) або A-записи (якщо міняєте тільки сервер, а DNS залишається на старому місці).
6. Дочекатися поширення змін — з TTL у 300 секунд це зазвичай кілька годин для переважної більшості користувачів.
7. Перевірити SSL-сертифікат на новому сервері й усі редиректи, зокрема www ↔ без www, http ↔ https.
8. Повернути TTL до звичного значення (3600 і вище) після підтвердження, що все працює стабільно.

Детальніший покроковий алгоритм усіх етапів переїзду, зокрема з підготовкою контенту й SEO-складовою, — у статті «Чекліст перенесення сайту на новий домен».

Типові помилки при переїзді

Перед початком робіт варто ознайомитися з поширеними технічними прорахунками, щоб завчасно вберегти ресурс від можливих збоїв:

1. Забули перенести MX-записи → пошта на старому домені перестає доходити → звіряти MX окремим пунктом чекліста, а не «заодно» з іншими записами.
2. Змінили NS-записи, не перенісши спершу їх на новий DNS-провайдер, → зникають піддомени, пошта, підтвердження в Search Console → спочатку продублювати наявні ресурси на новому провайдері, а лише потім перемикати NS.
3. Забули CAA-запис → новий сервер не може випустити SSL-сертифікат через Let’s Encrypt чи інший ЦС → перевірити CAA до переїзду, а не після помилки випуску сертифіката.
4. Не перевірили піддомени → work сайт переїхав, а shop чи blog все ще вказує на старий сервер → скласти повний список піддоменів домену до початку переїзду.

Уважна перевірка кожного з цих пунктів гарантує безпроблемне перенесення та збереже стабільну роботу всіх сервісів. 

DNS і SEO: що реально впливає на позиції

Варто чесно сказати одразу: DNS не є фактором ранжування сам по собі — Google не підвищує чи знижує позиції сайту за те, який у вас DNS-провайдер. 

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

Швидкість DNS-відповіді й час до першого байта

Резолвінг DNS зазвичай забирає від кількох до десятків мілісекунд і додається до часу до першого байта (TTFB) — показника, який Google враховує опосередковано через Core Web Vitals. 

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

Що ламається в індексації при неправильному DNS

Неправильний DNS блокує індексацію сайту. Якщо Googlebot не може достукатися до сервера через збій в A-записі чи недоступний авторитетний сервер, сторінки поступово випадають з індексу, а в Search Console з’являються сповіщення типу «DNS-помилка» чи «Сервер не відповів». 

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

Якщо трафік із пошуку просів без видимої причини, а в Search Console бачите помилки доступності, це привід перевірити саме DNS-конфігурацію в першу чергу, до заглиблення в решту SEO-гіпотез. Докладніше про типові причини випадання сторінок з індексу — у статті «Чому Google не індексує сайт».

Піддомен чи підпапка: як це виглядає на рівні DNS

У цьому контексті технічна реалізація повністю відображає SEO-стратегію. Підпапка (example.com/blog) не потребує жодних змін у DNS, оскільки залишається частиною того самого домену й A-запису, тоді як піддомен (blog.example.com) вимагає окремого CNAME- чи A-елементу і для частини пошукових систем сприймається як відокремлений ресурс зі власною вагою в ранжуванні. 

Це не привід механічно обирати підпапку тому, що простіше в DNS», — рішення варто ухвалювати з SEO-міркувань (структура контенту, потреба в окремому піддомені для іншого продукту чи мови), а DNS-налаштування вже підлаштовується під нього. Розгорнуте порівняння підходів із прикладами — у статті «Що таке піддомени і як їх використовувати в SEO».

Переїзд домену і що перевірити з боку DNS

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

Повний перелік дій для міграції сайту — у чеклісті про перенесення на новий домен.

Безпека DNS: DNSSEC, CAA і захист акаунта реєстратора

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

Нижче — три практичні речі, які закривають більшість реальних сценаріїв атаки.

DNSSEC: що це і чи потрібно вам

DNSSEC підтверджує справжність DNS-відповіді криптографічним підписом — це доводить, що дані від авторитетного сервера не підмінили дорогою, а не шифрує сам трафік запиту (для цього існують окремі протоколи DoH, DoT і DoQ, про які розкажемо нижче). 

Тут варто одразу розділити дві різні цифри, які легко переплутати: за даними аналізу зонних файлів TLD dnschkr.com, станом на лютий 2026 року підписано близько 4,3% доменів у зоні .com — це показник того, скільки власників доменів увімкнули підпис на своєму боці. Проте, за даними вимірювань Cloudflare Radar, реальна наскрізна криптографічна перевірка (коли резолвер користувача справді звіряє підпис, а не просто отримує його) відбувається лише в приблизно 0,5% запитів у світі станом на середину 2026 року — решта підписаних відповідей просто ігнорується резолверами, які не налаштовані на перевірку. 

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

DNS-хайджекінг і підміна записів

DNS-хайджекінг — це підміна DNS-записів зловмисником, і трапляється це трьома основними шляхами: злам акаунту в реєстратора домену (найчастіший вектор — слабкий пароль чи фішинг), отруєння кешу проміжного резолвера застарілими чи підробленими записами, пряма атака на самого DNS-провайдера. 

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

Як захистити домен

Збереження контролю над доменним іменем вимагає комплексного підходу до його безпеки на всіх рівнях:

1. Увімкнути двофакторну аутентифікацію в акаунті реєстратора домену — це закриває найчастіший вектор атаки одразу.
2. Активувати registry lock, якщо реєстратор його пропонує, — додатковий захист, що вимагає окремого підтвердження для будь-яких змін NS-записів чи передачі домену.
3. Додати CAA-запис, щоб чужий центр сертифікації не міг випустити SSL-сертифікат на ваш домен навіть у разі часткового компрометування.
4. Налаштувати моніторинг змін у DNS-зоні — сповіщення про будь-яку зміну записів дозволяє помітити підозрілу активність протягом хвилин, а не тижнів.
5. Використовувати окрему, захищену поштову скриньку для акаунта реєстратора домену, а не звичайну робочу пошту, яку легше скомпрометувати.

Впровадження цих базових запобіжних заходів дозволить звести до мінімуму ризик несанкціонованого доступу чи викрадення домену. 

Публічні DNS і шифрування запитів: DoH, DoT, DoQ

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

Нижче — чотири найпоширеніші сервіси без реклами якогось одного з них як «найкращого».

Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9, AdGuard

Сервіс	Адреси	Особливості	Кому підійде
Cloudflare	1.1.1.1 / 1.0.0.1	Один із найшвидших публічних резолверів, заявлена відсутність довгострокового логування запитів	Швидкість і приватність без фільтрації
Google Public DNS	8.8.8.8 / 8.8.4.4	Найбільша інфраструктура, стабільна швидкість у більшості регіонів	Універсальний варіант без фільтрації
Quad9	9.9.9.9 / 149.112.112.112	Некомерційна організація, блокує відомі шкідливі домени за замовчуванням	Базовий захист від фішингу й малварі
AdGuard DNS	94.140.14.14 / 94.140.15.15	Блокує рекламу й трекери на рівні DNS без окремого застосунку	Хто хоче менше реклами без адблокера

DoH, DoT і DoQ простими словами

Звичайний DNS-запит іде відкритим текстом, і теоретично будь-хто між пристроєм і резолвером — від провайдера до публічної Wi-Fi мережі в кафе — може побачити, які домени ви запитуєте, навіть якщо сам вміст сайту зашифрований через HTTPS. DoH (DNS over HTTPS) і DoT (DNS over TLS) шифрують сам DNS-запит: DoH маскує його під звичайний HTTPS-трафік, тому такий обмін заблокувати або обмежити окремо значно складніше. Натомість DoT працює через виділений зашифрований канал, тож його легше розпізнати й за потреби заблокувати на рівні мережі. DoQ (DNS over QUIC) — новіший варіант поверх протоколу QUIC, який поєднує швидкість встановлення з’єднання UDP з шифруванням TLS і поступово набирає підтримку в сучасних браузерах та операційних системах. 

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

Чи варто змінювати DNS на комп’ютері та що це реально дає

Чесна відповідь без завищених обіцянок: приріст швидкості завантаження сторінок від зміни DNS-провайдера зазвичай невідчутний для пересічного відвідувача — сучасні DNS-сервери здебільшого досить швидкі. Головна реальна цінність зміни публічного DNS — приватність (менше логування запитів провайдером) і фільтрація (блокування реклами чи шкідливих доменів на рівні мережі, як в AdGuard DNS), а не обіцяне «прискорення інтернету», яке часто зустрічається в маркетингових матеріалах самих сервісів.

Що робити, коли DNS не працює: розбір типових помилок

Помилки DNS-сервера — це половина всього пошукового трафіку теми, і базові туторіали про них зазвичай навіть не згадують. 

Нижче — чотири найчастіші ситуації з конкретними кроками виправлення.

DNS_PROBE_FINISHED_NXDOMAIN: що означає і як виправити

Ця помилка Chrome означає, що браузер отримав від DNS відповідь на кшталт «такого домену не існує» (NXDOMAIN) — причина полягає або в локальних налаштуваннях користувача, або в конфігурації самого ресурсу. 

Якщо сайт відкривається в інших людей, проблема локальна. Спробуйте перезапустити роутер, перевірити, чи немає банальної помилки в написанні адреси, очистити DNS-кеш свого пристрою (команди — у наступному розділі). 

Якщо сайт не відкривається ні в кого, проблема криється в самому домені. Найчастіше це прострочена реєстрація, помилка в NS-записах після нещодавньої зміни хостингу чи взагалі відсутність A-запису для введеної адреси.

1. Windows: відкрити командний рядок і виконати ipconfig /flushdns, потім перевірити з’єднання заново.
2. macOS: у терміналі виконати sudo dscacheutil -flushcache, sudo killall -HUP mDNSResponder.
3. Android: у більшості версій достатньо перемкнути авіарежим на кілька секунд або перезапустити Wi-Fi-з’єднання, оскільки окремої команди очищення кешу в системі немає.
4. Мобільний інтернет: якщо помилка спостерігається тільки через стільникову мережу, спробуйте вручну змінити DNS у налаштуваннях приватного DNS на 8.8.8.8 чи 1.1.1.1 замість DNS оператора.

Послідовна перевірка цих параметрів дозволяє швидко усунути локальні перешкоди й повернутися до нормальної роботи. 

DNS-сервер не відповідає

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

Наступний крок — змінити канал зв’язку (наприклад, перемкнути Wi-Fi на мобільні дані). Якщо ресурс завантажується, джерело неполадки криється саме в налаштуваннях мережевого обладнання. Останній крок — банальний перезапуск роутера: він скидає власний DNS-кеш пристрою й часто усуває тимчасові збої без подальшої діагностики.

Як очистити DNS-кеш

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

Windows (командний рядок): ipconfig /flushdns

macOS (термінал): sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Linux (systemd-resolved): sudo systemd-resolve –flush-caches

Окремо від системного кешу браузер Chrome веде власний DNS-кеш: скинути його можна на сторінці chrome://net-internals/#dns кнопкою «Clear host cache», що корисно, коли системний flush dns не допоміг, а проблема — саме в Chrome. На Android окремого кешу DNS на рівні системи здебільшого немає — оновлення відбувається автоматично при перепідключенні до мережі.

Файл hosts: коли він рятує, а коли шкодить

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

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

Інструменти для перевірки DNS

Для типових задач перевірка DNS-записів не вимагає жодного платного інструменту — нижче надаємо базовий набір безкоштовних сервісів під кожну конкретну задачу. 

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

1. Аналіз поточних записів домену (dns lookup) — whatsmydns.net чи звичайний dig/nslookup у терміналі.
2. Моніторинг поширення змін по регіонах світу (dns propagation) — whatsmydns.net показує статус із кількох десятків точок одночасно.
3. Аудит SPF, DKIM і DMARC — mxtoolbox.com чи dmarcian.com із готовими інструментами саме під ці три типи записів.
4. Перевірка власника й терміну реєстрації домену (whois) — whois.com чи команда whois у терміналі Linux/macOS.
5. Оцінка доступності DNS-сервера та швидкості відповіді (dns checker) — dnschecker.org показує результат одразу з кількох країн.

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

Думка експерта Elit-Web

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

Міщенко Сергій, Chief Marketing Officer

Висновки

DNS — інфраструктура, яка непомітна, поки працює правильно, і стає джерелом втрачених замовлень, зниклої пошти й просілого трафіку в ту мить, коли щось піде не так. Розуміння того, як влаштовані записи, чому пошта вимагає окремої уваги до SPF, DKIM і DMAR та що саме перевірити перед переїздом на новий хостинг, економить дні простою й врятовані листи клієнтів. DNS не є прямим фактором ранжування, але саме через нього найчастіше ламається те, що напряму впливає на позиції: доступність сайту для Googlebot і швидкість відповіді сервера. 

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

FAQ

Що таке DNS простими словами?

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

Скільки часу оновлюються DNS-записи?

Залежить від TTL конкретного запису — зазвичай від кількох хвилин до 24–48 годин для повного поширення DNS по всьому світу. Якщо перед зміною заздалегідь знизити TTL до 300 секунд, оновлення в більшості резолверів відбувається протягом кількох годин.

Як дізнатися, які DNS-записи в мого домену?

Найпростіше рішення — ввести домен на whatsmydns.net чи скористатися командою nslookup або dig у терміналі з указанням потрібного типу запису (A, MX, TXT тощо). Це покаже поточні значення без входу в панель хостингу чи реєстратора.

Чи впливає DNS на SEO?

Прямо — ні, DNS не є фактором ранжування сам по собі. Опосередковано — так: через неправильний DNS Googlebot може не достукатися до сервера, сторінки випадають з індексу, а повільний резолвінг додається до часу завантаження контенту. Детальніше — у розгорнутому розділі про DNS і SEO вище.

Що означає помилка DNS_PROBE_FINISHED_NXDOMAIN?

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

Як очистити DNS-кеш на комп’ютері?

Для очищення DNS-кешу в ОС Windows виберіть ipconfig /flushdns у командному рядку. На macOS — sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder у терміналі. Для Chrome окремо — сторінка chrome://net-internals/#dns.

Який публічний DNS кращий?

Однозначного переможця немає — все залежить від задачі: Cloudflare і Google орієнтовані на швидкість без фільтрації, Quad9 додає базовий захист від шкідливих доменів, AdGuard DNS блокує рекламу на рівні мережі. Повне порівняння адрес та особливостей — у таблиці вище.

Навіщо потрібні SPF, DKIM і DMARC?

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

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

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