Проверка DNS-записей

Записи и то, для чего они на самом деле

«Распространение» — неверное слово

Самая полезная вещь, которую стоит понять про DNS, потому что она превращает непредсказуемое ожидание в число, которым вы управляете.

Ничто никуда не распространяется. Нет ни рассылки, ни раздачи, ни волны обновлений, катящейся по интернету. У вашего сервера имён новое значение появляется в тот же миг, как вы нажали «сохранить». Время уходит на другое: каждый резолвер в мире держит кешированную копию старого ответа и сохранит её, пока не истечёт выданный ему TTL.

Так что задержка не загадочна — это ровно тот TTL, который был опубликован, когда каждый резолвер спрашивал в последний раз. Если у вашей записи TTL был 3600 секунд, одни резолверы переспросят через пять минут, другие через час, — отсюда и ощущение, что изменение доходит до людей неравномерно.

Отсюда и порядок действий для любого планового изменения:

1. За сутки снизьте TTL до 300 секунд. Дождитесь, пока истечёт старый TTL, чтобы все подхватили короткий.
2. Внесите изменение. Теперь оно занимает пять минут, а не сутки.
3. Когда всё уляжется, верните TTL обратно.

Поднимать его обратно стоит потому, что низкий TTL означает больше запросов, большую задержку при промахе кеша и более тяжёлую аварию, если ваши серверы имён окажутся недоступны, — ни у кого не останется пригодного кешированного ответа, на который можно опереться.

Почтовые записи — там и сидит большинство проблем

Верят ли вашей почте, определяют три записи TXT. Их часто настраивают неправильно, и провал безмолвен: письма уходят в спам, а не отбиваются, так что никто вам об этом не скажет.

SPF

Перечисляет серверы, которым дозволено отправлять почту от вашего домена. Ошибки, по убыванию частоты:

• Две записи SPF. RFC 7208 требует, чтобы получатели считали это постоянной ошибкой, так что проверка проваливается целиком. Слейте их в одну.
• Больше десяти DNS-запросов. Каждый include: считается, а includes вкладываются. Почтовый провайдер плюс маркетинговая платформа плюс служба поддержки — и вы уже там, а превышение приводит к провалу проверки.
• Окончание на `~all` или `?all`. Оба означают «вероятно, не мы, но поступайте как знаете». Отклонить получателей просит только -all.

DKIM и DMARC

DKIM подписывает каждое письмо ключом, открытая половина которого живёт в записи TXT под именем селектора вроде selector1._domainkey.example.com — чтобы её найти, надо знать селектор, поэтому её и нет в запросе выше по умолчанию. DMARC живёт по адресу _dmarc.example.com и сообщает получателям, что делать, когда SPF и DKIM расходятся, и куда слать отчёты.

Запросите _dmarc.yourdomain.com в инструменте выше. Если ничего не вернулось, у получателей нет никаких указаний, и по любому письму, подделывающему вас, они будут решать сами.

Правило CNAME на вершине домена

CNAME не может сосуществовать ни с какой другой записью для того же имени. У вершины домена обязаны быть записи SOA и NS, значит, у вершины не может быть CNAME, — отчего направить example.com на SaaS-провайдера неудобно, а www.example.com тривиально.

Обходные пути зависят от провайдера: ALIAS, ANAME или «уплощение» CNAME — все они разрешают цель на стороне сервера и отвечают записью A. Они работают, они не стандартизованы, и знать о них стоит до того, как вы потратите на это полдня.

Смежное

Когда записи указывают куда надо, проверьте сертификат, который узел на самом деле предъявляет, и какие заголовки он возвращает. А чтобы выяснить, какой сети принадлежит адрес, на который указывает запись, на это ответит поиск по ASN.