За несколько лет работы домена в его DNS-зоне накапливаются записи из разных эпох. A-запись на старый хостинг, MX от почтового сервиса, который когда-то пробовали, TXT для подтверждения, добавленная неизвестно кем, или CNAME на давно закрытый интернет-магазин. Желание навести порядок понятно: лишние записи путают. Но одна строка, удалённая с мыслью «наверное, уже не нужна», способна остановить почту или сделать важный сервис недоступным.
Почему «старая на вид» запись может всё ещё работать
Рядом с DNS-записью не пишут, кто, когда и зачем её добавил. Поэтому имена вроде old, test или srv2 снаружи выглядят мусором, а на деле к ним может подключаться внутренняя система, бухгалтерская программа или кассовое приложение. Особенно обманчивы TXT-записи: часть из них нужна для разового подтверждения, но некоторые сервисы периодически проверяют, что запись на месте. Если она исчезнет, сервис может посчитать, что вы больше не владеете доменом, и отключить интеграцию.
Почтовые записи требуют отдельного внимания. SPF, DKIM и DMARC внешне похожи на обычные текстовые строки, однако удаление любой из них приводит к тому, что ваши письма начинают попадать в спам у получателей. Ключ DKIM обычно находится в имени вида selector._domainkey, и многие принимают его за непонятный остаток.
Реальная ситуация: клиника после переезда сайта
Частная клиника в Ташкенте перенесла сайт на новый хостинг, и администратор решил почистить зону misol.uz. Он удалил все A-записи, указывавшие на старый сервер, в том числе mail.misol.uz. Сайт на новом месте работал отлично, но на следующий день сотрудники регистратуры пожаловались, что почтовые приложения на телефонах не подключаются: в настройках был указан именно mail.misol.uz, а почта всё ещё жила на старом сервере. Проблему решили за несколько часов, но письма пациентов всё это время оставались без ответа. Проверка назначения каждого имени перед удалением предотвратила бы этот сбой.
Как проверить запись перед удалением
Первый шаг — зафиксировать текущее состояние зоны целиком. Скопируйте все записи со страницы DNS в кабинете и сохраните в отдельный файл с датой. Затем проверьте, что каждая запись отдаёт сейчас. Команды ниже работают в Linux, macOS или WSL на Windows:
# Основные записи
dig +short A misol.uz
dig +short MX misol.uz
dig +short TXT misol.uz
dig +short TXT _dmarc.misol.uz
# Куда указывает конкретный поддомен
dig +short CNAME shop.misol.uz
dig +short A mail.misol.uz
# Если в Windows нет dig
nslookup -type=MX misol.uzЧтобы понять, работает ли что-то на IP-адресе из A-записи, можно отправить запрос прямо туда. Параметр --resolve у curl привязывает имя к указанному адресу, не трогая DNS:
curl -I --resolve old.misol.uz:443:203.0.113.10 https://old.misol.uz/Если пришёл ответ и в нём видно работающее приложение, сначала выясните, кто им пользуется. Если ответа нет или сервер уже выключен, запись, скорее всего, действительно не нужна.
Вопросы для каждого типа записи
| Тип записи | Что выяснить до удаления |
|---|---|
| A / AAAA | Работает ли сейчас сервис на этом IP, подключаются ли к имени устройства или программы? |
| MX | На каком сервере сейчас почта и совпадает ли с ним этот MX? |
| TXT | Это SPF, DKIM, DMARC или подтверждение сервиса, и проверяет ли сервис её повторно? |
| CNAME | Открыт ли ещё ваш аккаунт во внешнем сервисе, на который указывает запись? |
| CAA | Опирается ли на эту запись центр, выпускающий SSL-сертификаты? |
Иногда опаснее не удалить: висящий CNAME
У чистки зоны есть и обратная сторона. Если shop.misol.uz через CNAME указывал на внешнюю платформу магазина, а аккаунт там вы закрыли, запись «повисает». На некоторых платформах посторонний человек может открыть новый аккаунт и привязать к себе именно этот поддомен — и под вашим именем откроется чужая страница. Это называется захватом поддомена и удобно для фишинга. Поэтому, отказываясь от сервиса, сразу удаляйте указывающий на него CNAME, но прежде убедитесь, что сервис действительно закрыт.
Безопасный порядок удаления
Вместо мгновенного удаления сомнительной записи лучше действовать поэтапно — так при ошибке можно быстро откатиться.
- Сохраните полную копию зоны и запишите дату изменения.
- За сутки снизьте TTL записи до 300 секунд, чтобы возврат распространился быстро.
- Спросите разработчика, бухгалтера и пользователей почты об этом имени.
- Удалите запись и одну-две недели следите за жалобами, ошибками и почтовыми журналами.
- Если проблем нет, оставьте копию в архиве и задокументируйте изменение.
Шаг со снижением TTL часто пропускают. Если TTL записи — сутки, а вы, поняв ошибку, вернули её, часть пользователей ещё какое-то время будет видеть проблему: в кеше их провайдеров сохранился ответ об отсутствии записи. Заранее спланированное изменение заметно сокращает время восстановления.
Привычка держать зону в порядке
Чтобы такие вопросы не возникали в будущем, полезно вести простую таблицу DNS-изменений: имя записи, тип, значение, кто добавил, зачем и когда пересмотреть. В небольшой организации достаточно одного общего документа. На странице DNS в кабинете sayt.uz записи легко добавлять и удалять, но помнить, чьё решение стоит за каждой из них, будет именно такая таблица. Пересмотр зоны раз-два в год и аккуратное удаление неиспользуемых сервисов поддерживают стабильность и домена, и почты.