Типичные ошибки 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 →