Типові помилки DNS

Коротка відповідь: Класика: редагування DNS не в того провайдера, CNAME на apex зони, MX на CNAME чи IP, два SPF-записи, забутий www, міграція з високим TTL і очікування миттєвих змін. Для кожної є просте запобігання.

Огляд

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

Що потрібно мати

• Перш ніж щось чіпати, підтвердьте, який провайдер авторитетний: dig +short NS example.com.

Покрокова інструкція

Помилки — і що робити натомість:

1. Редагування неавторитетної зони. Записи, змінені в реєстратора, нічого не дають, якщо NS вказує інде — завжди спершу перевіряйте NS.
2. CNAME на @. Заборонено поруч з іншими apex-записами; використайте A-запис або ALIAS/ANAME вашого провайдера (деталі).
3. MX → CNAME чи MX → IP. Обидва некоректні; вказуйте MX на ім’я з A-записом (деталі).
4. Два SPF-записи. Об’єднайте в один рядок v=spf1, інакше SPF падає повністю (деталі).
5. Забутий www (або голий домен) під час направлення сайту — половина відвідувачів отримує помилку (обидва записи).
6. Міграція з TTL 86400. Знизьте TTL за добу, інакше старий сервер обслуговує трафік ще день (гайд перемикання).
7. Повне ім’я в полі «host» — виходить www.example.com.example.com.
8. Видалення незнайомих записів. Верифікаційні TXT і DKIM-селектори схожі на сміття, але несуть навантаження — спершу аудит, потім чистка.

Типові проблеми

• «У мене працює, а в клієнтів ні»: розсинхрон кешів під час спливання TTL — порівняйте відповіді кількох резолверів.
• Запис виправлено, а досі зламано: негативні/позитивні кеші; звірте з авторитетним NS, що правка справді на місці.

Коли звертатися в підтримку

Не впевнені, чи безпечна зміна запису, або бачите дивний резолвінг у бік вашого сервера Cloud2Y після правки? Відкрийте тикет із доменом і описом змін — друга пара очей: дешева страховка.

Часті запитання

Яка найпоширеніша помилка DNS?

Редагування записів у провайдера, що не є авторитетним для домену. Завжди спершу перевіряйте NS-записи — зміни, зроблені деінде, інтернет мовчки ігнорує.

Чи безпечно видаляти незнайомі DNS-записи?

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

Навіщо знижувати TTL перед змінами й підвищувати після?

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

Схожі статті

• Як працює DNS
• Як зменшити проблеми з поширенням DNS
• Як діагностувати домен, що не відкривається
• DNS FAQ

Потрібна допомога? Звернутися в підтримку Cloud2Y →