DNS на хостингу: як неправильні записи крадуть ваш трафік і що з цим робити

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

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

Що таке DNS і чому це найважливіша штука, про яку ніхто не думає

DNS (Domain Name System) - це телефонна книга інтернету. Коли хтось вводить vashdomen.com, браузер не розуміє людських слів. Йому потрібна IP-адреса - числова, як 185.230.63.107. DNS-сервер перетворює текстовий домен на цю адресу за мілісекунди.

Здавалося б, налаштував один раз - і забув. Але ні. DNS-записи - це жива система, яка потребує уваги. Ось основні типи, які вам варто знати:

• A-запис - зв'язує домен з IPv4-адресою вашого сервера. Найголовніший запис.
• AAAA-запис - те саме, але для IPv6. Якщо ваш хостинг підтримує IPv6, ігнорувати цей запис - гріх.
• CNAME - псевдонім, що перенаправляє один домен на інший. Класика для субдоменів типу www або blog.
• MX-запис - маршрут для електронної пошти. Помилка тут - і ваші листи летять у космос.
• TXT-запис - текстова інформація, критична для SPF, DKIM і підтвердження власності домену.

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

П'ять помилок у DNS, які з'їдають ваш трафік прямо зараз

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

1. Забутий www-CNAME. Домен vashdomen.com працює, а www.vashdomen.com - ні. Половина відвідувачів бачить помилку. Google індексує обидві версії, знаходить дублі, карає обидві.
2. Застарілий A-запис після міграції. Ви переїхали на новий хостинг, змінили A-запис, але забули про субдомен mail.vashdomen.com. Пошта досі йде на старий сервер, якого вже не існує.
3. Занадто високий TTL. TTL (Time to Live) каже кешуючим серверам, скільки зберігати запис. Якщо TTL - 86400 секунд (24 години), після зміни IP ваш сайт буде недоступний цілу добу для частини користувачів.
4. Відсутній або неправильний SPF-запис. Без SPF ваші email-розсилки - потенційний спам. Gmail та Outlook перевіряють SPF у 100% випадків з лютого 2024 року.
5. Конфлікт між CNAME і кореневим доменом. Технічно CNAME не можна ставити на кореневий домен (так званий apex). Хтось ставить - і DNS починає поводитися непередбачувано.

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

Як правильно налаштувати DNS: покрокова інструкція без зайвого жаргону

Добре, діагноз поставлений. Тепер - лікування. Я розіб'ю процес на конкретні кроки, які підходять для 90% ситуацій.

Крок 1. Відкрийте DNS-менеджер. Це може бути панель реєстратора домену (Namecheap, GoDaddy, nic.ua) або панель хостингу (cPanel, Plesk, DirectAdmin). Якщо DNS делеговано на хостинг - змінюйте записи саме там.

Крок 2. Перевірте A-запис. Він повинен вказувати на актуальну IP-адресу вашого сервера. Не знаєте IP? Зайдіть у панель хостингу або напишіть у підтримку - вони дадуть за 2 хвилини.

Крок 3. Додайте CNAME для www. Значення - ваш кореневий домен. Виглядає так: www → vashdomen.com. Просто? Так. Але забувають про це приголомшливо часто.

Крок 4. Налаштуйте MX-записи. Якщо використовуєте Google Workspace, значення будуть типу aspmx.l.google.com з пріоритетом 1. Для кожного поштового сервісу - свої записи. Перевіряйте офіційну документацію.

Крок 5. Додайте TXT-записи для SPF і DKIM. Мінімальний SPF виглядає так: v=spf1 include:_spf.google.com ~all (для Google). DKIM-ключ генерує ваш поштовий провайдер.

Крок 6. Знизьте TTL перед змінами. Поставте 300 секунд (5 хвилин) за добу до планованих змін. Після того як нові записи поширяться - поверніть TTL на 3600 (1 година) або вище.

Золоте правило: після будь-яких змін у DNS перевіряйте результат через інструменти типу dnschecker.org, MXToolbox або командою dig у терміналі.

Інструменти для діагностики DNS, які заощадять вам нерви

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

Мій фаворит - зв'язка MXToolbox + DNSChecker. Перший показує проблеми, другий - чи побачив світ ваші виправлення. Весь процес займає 3-5 хвилин, але може врятувати дні простою.

Cloudflare та подібні CDN: панацея чи додатковий рівень хаосу

Окремо хочу поговорити про Cloudflare. Мільйони сайтів використовують його як DNS-проксі та CDN. І це чудово - до першої помилки.

Коли ви підключаєте Cloudflare, ви фактично делегуєте DNS на їхні сервери. Це означає, що зміни потрібно робити в панелі Cloudflare, а не в реєстратора. Звучить очевидно? Я особисто бачив, як досвідчені розробники годинами змінювали записи у Namecheap, забувши, що DNS давно на Cloudflare. Нічого не працювало. Нерви горіли.

Ще одна пастка - помаранчева хмаринка (proxy status). Якщо вона увімкнена, трафік йде через Cloudflare. Для вебсайту - чудово, бо працює кешування та захист від DDoS. Але для MX-записів або FTP - катастрофа. Ніколи не проксюйте MX-записи через Cloudflare. Пошта зламається миттєво.

Корисні практики при роботі з Cloudflare:

• MX, TXT для пошти - завжди сіра хмаринка (DNS only).
• A-запис для основного сайту - помаранчева хмаринка (Proxied).
• Субдомени для API або внутрішніх сервісів - сіра хмаринка, щоб уникнути зайвих затримок.
• Регулярно перевіряйте, чи не «з'їв» Cloudflare ваші оригінальні записи після автоматичного імпорту.

DNS і SEO: зв'язок, який ігнорують навіть маркетологи

Google офіційно враховує час завантаження сторінки як фактор ранжування. А що впливає на час завантаження ще до того, як сервер отримає запит? Правильно - DNS lookup time.

Середній час DNS-резолвінгу - 20-120 мілісекунд. Здається мало? Але помножте на кількість зовнішніх ресурсів (шрифти, скрипти аналітики, CDN-зображення) - і ви легко додаєте 300-500 мс до загального часу завантаження. Для Google це різниця між першою та другою сторінкою видачі.

Що можна зробити:

1. Використовуйте швидкий DNS-провайдер. Cloudflare, Google Public DNS (8.8.8.8), або Quad9. Вони обробляють запити за 10-15 мс замість 50-80 мс у типового реєстратора.
2. Додайте DNS prefetch у HTML. Рядок <link rel="dns-prefetch" href="//fonts.googleapis.com"> змушує браузер резолвити домен заздалегідь.
3. Мінімізуйте кількість зовнішніх доменів. Кожен новий домен - це додатковий DNS-запит. Три зайвих скрипти - це +100 мс мінімум.
4. Увімкніть DNSSEC. Це не прискорює, але захищає від DNS-спуфінгу. Google враховує безпеку як сигнал довіри.

Швидкий DNS - це найдешевший спосіб прискорити сайт. Жодних змін у коді, жодних оптимізацій картинок. Просто правильні налаштування.

А тепер перевірте свій сайт

Ось що я пропоную: прямо зараз відкрийте dnschecker.org, введіть свій домен і подивіться, що там коїться. Потім зайдіть на mxtoolbox.com/supertool і прогоніть повну діагностику. Ви здивуєтесь, скільки «невидимих» проблем там ховається.

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

Яке у вас зараз значення TTL на A-записі? Якщо ви не знаєте відповіді - це саме та проблема, про яку ми щойно говорили.