Курс администрирования DNS — Лабораторное окружение

Урок 1

Разрешение имён, кэширование и резолверы

Цель упражнения

Пронаблюдать разницу между кэшированным ответом рекурсивного резолвера и авторитативным ответом, и измерить в реальном времени убывание TTL на собственном домене.

Почему это важно

Почти каждый тикет «DNS не работает» на самом деле — недопонимание кэширования: изменение было внесено правильно, но резолвер (у провайдера, публичный или локальный ОС) всё ещё отдаёт устаревший закэшированный ответ. Умение доказать, где именно находится устаревший ответ, — самый востребованный диагностический навык этого курса.

Команды для выполнения / что проверить

# Запросите свой домен через резолвер провайдера/по умолчанию, отметьте TTL
dig yourdomain.com A

# Запросите ту же запись напрямую у публичного резолвера, сравните TTL
dig @1.1.1.1 yourdomain.com A
dig @8.8.8.8 yourdomain.com A

# Запросите авторитативный NS-сервер напрямую (минуя всё кэширование)
dig @ns1.yourdnsprovider.com yourdomain.com A +norecurse

# Наблюдайте убывание TTL: повторяйте запрос каждые 10с и сравнивайте поле TTL
watch -n 10 "dig @1.1.1.1 yourdomain.com A | grep -A1 ANSWER"

Измените IP-адрес A-записи в панели управления, затем повторно выполните рекурсивный запрос до и после истечения TTL — убедитесь, что видите СТАРОЕ значение, пока TTL не достигнет нуля, а затем НОВОЕ.

Дополнительные заметки (по ролям)

Sysadmin: также пригодится systemd-resolve --flush-caches (или dscacheutil -flushcache на macOS), чтобы доказать, что локальное кэширование на уровне ОС — отдельный слой от кэша резолвера: два кэша, две точки сброса, часто путают.
DevOps: в контейнеризированных/k8s-окружениях именно собственный кэш CoreDNS (отдельный от TTL upstream) обычно и является проблемным слоем — kubectl logs на поде CoreDNS плюс dig изнутри пода — эквивалентное упражнение.
Security-adjacent: здесь же уместно ввести DoH/DoT — повторите запрос dig @1.1.1.1, используя kdig +tls @1.1.1.1 yourdomain.com (если установлен knot-dnsutils) или curl к https://cloudflare-dns.com/dns-query, и сравните — тот же ответ, другой транспорт, другой уровень приватности.

← Вернуться к Уроку 1

Урок 2

Делегирование, glue-записи и избыточность

Цель упражнения

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

Почему это важно

Неправильно настроенное или хромое делегирование незаметно ровно до тех пор, пока не перестаёт быть таковым — некоторые резолверы кэшируют рабочий путь и маскируют проблему неделями, пока кэш не истечёт и пользователи внезапно не потеряют доступ к домену. Это причина №1, которую проверяет категория CAT-INFRA в NODA.

Команды для выполнения / что проверить

# Пройдите цепочку делегирования вручную: root -> TLD -> ваш NS
dig +trace yourdomain.com

# Убедитесь, что говорит РОДИТЕЛЬСКАЯ зона о ваших NS-серверах
dig yourdomain.com NS @a.root-servers.net    # (или соответствующий TLD-сервер из вывода +trace)

# Убедитесь, что говорят о себе ВАШИ NS-серверы (должно совпадать)
dig yourdomain.com NS @ns1.yourdnsprovider.com

# Проверьте glue: отдаёт ли родитель A/AAAA для ваших NS без второго запроса?
dig yourdomain.com NS +additional

# Обнаружение хромого делегирования: запросите каждый NS напрямую, все должны отвечать авторитативно
for ns in $(dig +short yourdomain.com NS); do echo "== $ns =="; dig @$ns yourdomain.com SOA +norecurse; done

Несовпадение NS на стороне родителя и на вашей стороне, либо любой NS-сервер, не отвечающий авторитативно, — это и есть признак хромого делегирования.

Дополнительные заметки (по ролям)

Sysadmin: если вы сами администрируете BIND, named-checkzone отлавливает многие такие проблемы до публикации — используйте как предварительную проверку, а не только как разбор после инцидента.
DevOps: мульти-провайдерный DNS (например, Route53 + Cloudflare как secondary) требует побайтово идентичного набора NS с обеих сторон — CI-проверка, сравнивающая вывод dig NS между провайдерами перед деплоем, ловит расхождение раньше клиентов.
Security-adjacent: злоумышленник, зарегистрировавший освободившееся имя NS-сервера из устаревшей/удалённой NS-записи, может перехватить делегированный трафик — именно поэтому NODA помечает осиротевшие, но всё ещё делегированные NS-записи как Critical, а не как косметическую проблему.

← Вернуться к Уроку 2

Урок 3

Механика зоны

Цель упражнения

Разобраться в семантике SOA serial, выполнить и проверить передачу зоны (AXFR), убедиться, что вторичные серверы синхронизированы.

Почему это важно

Устаревший или не увеличивающийся serial незаметно ломает синхронизацию вторичных серверов — они считают, что ничего не изменилось, и бесконечно отдают устаревшие данные. Это тихая, труднозаметная поломка вплоть до аудита (или разгневанного клиента).

Команды для выполнения / что проверить

# Прочитайте текущий SOA serial + таймеры
dig yourdomain.com SOA +short

# Сравните serial на primary и на каждом secondary — должны совпадать после любого изменения
for ns in $(dig +short yourdomain.com NS); do echo "== $ns =="; dig @$ns yourdomain.com SOA +short; done

# Попытка передачи зоны (должна УДАСТЬСЯ только с авторизованного IP secondary, ПРОВАЛИТЬСЯ с остальных)
dig axfr yourdomain.com @ns1.yourdnsprovider.com

# С вашего лабораторного сервера (должно быть отклонено, если AXFR правильно ограничен):
dig axfr yourdomain.com @ns1.yourdnsprovider.com

Внесите небольшое изменение записи, увеличьте serial по конвенции вашего провайдера (обычно YYYYMMDDnn) и повторяйте сравнение secondary-серверов, пока все не совпадут.

Дополнительные заметки (по ролям)

Sysadmin: успешная передача зоны с произвольного IP — реальная и распространённая ошибка конфигурации; относитесь к успешной передаче с лабораторного сервера как к находке для исправления, а не как к удобству.
DevOps: если данные зоны управляются как код (Terraform/IaC), увеличение serial должно быть автоматизировано частью пайплайна — вручную поддерживаемый serial КОГДА-НИБУДЬ забудут обновить.
Security-adjacent: это именно та проверка, что стоит за Check «AXFR / Zone Transfer» NODA (CAT-SEC) — открытая передача зоны отдаёт злоумышленнику весь ваш DNS-след одним запросом, включая похожие на внутренние имена хостов, полезные для разведки.

← Вернуться к Уроку 3

Урок 4

Типы записей за пределами базовых

Цель упражнения

Корректно составить и проверить A/AAAA, граничные случаи сосуществования с CNAME, MX, TXT, SRV и CAA-записи.

Почему это важно

Большинство администраторов знают A/MX/TXT; CAA и правило сосуществования CNAME — это именно то, с чего начинается «мастер-уровень» — CAA в частности является самым новым широко значимым типом записи и определяет, кто вообще вправе выпускать TLS-сертификат для вашего домена.

Команды для выполнения / что проверить

# Базовые адресные записи
dig yourdomain.com A
dig yourdomain.com AAAA

# Проверка правила сосуществования CNAME — CNAME должна быть ЕДИНСТВЕННОЙ записью на этом имени
dig www.yourdomain.com CNAME
dig www.yourdomain.com ANY    # не должно показывать ничего другого на этом имени

# MX
dig yourdomain.com MX +short

# SRV (пример: сервис объявляет себя через DNS)
dig _sip._tcp.yourdomain.com SRV

# CAA — кто уполномочен выпускать сертификаты для этого домена
dig yourdomain.com CAA +short

Добавьте CAA-запись, ограничивающую выпуск одним CA (например, 0 issue "letsencrypt.org"), затем убедитесь через dig, что она видна, прежде чем полагаться на неё — и учтите, что CAA проверяется CA в момент выпуска, а не браузерами в момент подключения.

Дополнительные заметки (по ролям)

Sysadmin: случайное сосуществование CNAME с другой записью на том же имени — классическая ошибка в панелях управления, которые не проверяют правило RFC на своей стороне — всегда проверяйте через dig ANY после добавления CNAME.
DevOps: SRV-записи важнее в окружениях с активным service discovery (SIP, XMPP, некоторые паттерны Kubernetes ingress) — если ваш стек не использует service discovery через DNS, этот тип записи может быть просто неприменим; не форсируйте упражнение там, где реального применения нет.
Security-adjacent: CAA без тега iodef означает, что вы не получите уведомление о попытке неавторизованного выпуска сертификата — добавьте его (0 iodef "mailto:security@yourdomain.com") для более полной конфигурации.

← Вернуться к Уроку 4

Урок 5

DNSSEC I: цепочка доверия

Цель упражнения

Подписать зону, пронаблюдать появление DS-записи у родителя и полностью проверить итоговую цепочку доверия.

Почему это важно

Это самый цитируемый «пробел в лучших практиках» во всей индустрии (см. собственные исследования NODA) — большинство операторов либо никогда не включают DNSSEC, либо включают один раз и никогда не проверяют, что цепочка реально валидируется. Наблюдение за появлением собственной DS-записи — лучший обучающий момент курса.

Команды для выполнения / что проверить

# До подписи: убедитесь, что DNSKEY ещё не существует
dig yourdomain.com DNSKEY +short

# Включите DNSSEC в панели провайдера (один клик на Cloudflare/Route53/большинстве современных хостов), затем:
dig yourdomain.com DNSKEY +short
dig yourdomain.com DS +short          # запрашивается у РОДИТЕЛЯ

# Полная проверка цепочки (нужен валидирующий резолвер)
delv yourdomain.com A                 # delv сообщит "fully validated" или покажет, где именно цепочка рвётся

# Убедитесь, что публичный валидирующий резолвер согласен
dig @1.1.1.1 yourdomain.com A +dnssec +cd    # наличие флага AD = валидировано

delv (входит в состав BIND) — самый прямой инструмент для этого: он проходит реальную цепочку доверия, а не просто проверяет «включён ли DNSSEC».

Дополнительные заметки (по ролям)

Sysadmin: при самостоятельном хостинге BIND named-checkzone и dnssec-verify должны выполняться как проверка перед публикацией, а не постфактум.
DevOps: публикация DS-записи у родителя обычно остаётся ручным или полуручным шагом у регистратора, даже если подпись зоны автоматизирована — это единственная часть пайплайна, которая у большинства регистраторов сопротивляется полной автоматизации; документируйте это явно в runbook.
Security-adjacent: флаг AD от публичного резолвера необходим, но недостаточен — всегда перепроверяйте через delv или второй независимый валидатор (например, dnsviz.net), прежде чем считать цепочку надёжной, поскольку неправильно настроенный резолвер может ложно сообщить об успешной валидации.

← Вернуться к Уроку 5

Урок 6

DNSSEC II: эксплуатация и режимы отказа

Цель упражнения

Выполнить ротацию ключа и намеренно сломать DNSSEC, чтобы распознавать его реальные признаки отказа.

Почему это важно

Развёртывания DNSSEC почти всегда ломаются именно в моменты эксплуатации — ротация ключей, смена алгоритма — а не на этапе первоначальной настройки. Это разрыв между «я включил» и «я умею эксплуатировать», и именно здесь происходит большинство реальных сбоев DNSSEC в продакшене.

Команды для выполнения / что проверить

# Базовая проверка: убедитесь, что текущая валидация чистая
delv yourdomain.com A

# Инициируйте ротацию ключа в панели провайдера, затем наблюдайте за переходом:
dig yourdomain.com DNSKEY +short      # ищите два ключа одновременно во время перекрытия ротации
dig yourdomain.com DS +short          # убедитесь, что DS обновляется у родителя ПОСЛЕ, а не до появления нового DNSKEY

# Намеренно сломайте (только на лабораторном домене — никогда на продакшн-зоне):
# например, оставьте DS-запись устаревшей относительно ротированного ключа, или испортите подпись вручную, если провайдер позволяет прямое редактирование записей
dig yourdomain.com A +dnssec          # наблюдайте SERVFAIL и точную ошибку у валидирующего резолвера
delv yourdomain.com A                 # delv точно покажет, какое звено цепочки нарушено

Цель — распознать паттерн SERVFAIL от валидирующего резолвера (обычно именно это конечные пользователи описывают как «домен X не работает») и проследить его до конкретного разорванного звена через delv, а не гадать.

Дополнительные заметки (по ролям)

Sysadmin: знайте, автоматизирует ли ваш провайдер ротацию по расписанию (Cloudflare/Route53) или требуется ручная ротация — именно при ручной ротации чаще всего случается ошибка порядка DS-до-DNSKEY.
DevOps: если DS-записи управляются как код, ротация ДОЛЖНА быть двухшаговым деплоем (опубликовать новый DNSKEY, дождаться распространения и истечения старого TTL, ЗАТЕМ обновить DS) — один атомарный IaC-apply, делающий оба шага сразу, — самая частая самопричинённая авария DNSSEC.
Security-adjacent: RFC 8624 регулирует выбор алгоритма — при тестировании смены алгоритма (а не просто ротации ключа) убедитесь, что регистратор/родитель действительно поддерживает новый алгоритм в DS-записях; поддерживают не все.

← Вернуться к Уроку 6

Урок 7

DNS как поверхность атаки

Цель упражнения

Проверить собственную инфраструктуру на открытую рекурсию и уязвимости, смежные с cache poisoning.

Почему это важно

Открытый резолвер на контролируемой вами инфраструктуре может быть незаметно использован в reflection/amplification DDoS-атаке против третьей стороны — вы становитесь невольным участником, и это полностью предотвратимо одной настройкой.

Команды для выполнения / что проверить

# Проверьте, отвечает ли ВАШ сервер на рекурсивные запросы от произвольных источников (не должен, для авторитативного-only сервера)
dig @your-lab-box-ip google.com A         # с машины, ОТЛИЧНОЙ от самого сервера

# Убедитесь, что рекурсия отключена на авторитативном-only сервере (пример для BIND)
grep -i recursion /etc/bind/named.conf.options    # должно показывать "recursion no;"

# Проверьте, не уязвим ли ваш домен к использованию в качестве усилителя отражения через ANY-запросы
dig yourdomain.com ANY @ns1.yourdnsprovider.com +norecurse

# Базовая проверка размера ответа — больше размер ответа = больше коэффициент усиления при злоупотреблении
dig yourdomain.com ANY +norecurse | wc -c

Если шаг 1 возвращает реальный ответ с машины, не имеющей права запрашивать ваш сервер, — рекурсия открыта и требует немедленного исправления. Это именно та проверка, что стоит за Open Recursor Check в NODA (CAT-SEC).

Дополнительные заметки (по ролям)

Sysadmin: recursion no; (BIND) или эквивалентный ACL в Unbound/PowerDNS — это исправление; проверяйте с внешней точки (ваш AWS-сервер, если используете Вариант A), а не только с localhost, поскольку тесты с localhost не выявляют внешнюю доступность.
DevOps: если NS-серверы находятся за балансировщиком/файрволом, убедитесь, что ACL применяется именно на самом DNS-сервере, а не только на сетевом уровне — случайно открытое правило файрвола (частое при отладке) не должно быть единственной защитой от открытого резолвера.
Security-adjacent: RFC 5358 (рекомендательный, не источник MUST/SHALL по собственной Методологии NODA, раздел 10) — канонический источник здесь; ссылайтесь на него в рекомендациях по устранению, но не трактуйте как жёсткое требование соответствия.

← Вернуться к Уроку 7

Урок 8

SPF подробно

Цель упражнения

Составить корректную SPF-запись, намеренно превысить лимит в 10 запросов и распознать возникающий сбой.

Почему это важно

Лимит SPF в 10 DNS-запросов (RFC 7208 §4.6.4) — самая частая реальная причина отказа SPF: записи органически разрастаются по мере добавления сервисов, незаметно превышают лимит, и SPF начинает возвращать permerror для всех — часто незамеченным месяцами.

Команды для выполнения / что проверить

# Прочитайте текущую SPF-запись
dig yourdomain.com TXT +short | grep spf1

# Подсчитайте запросы вручную — каждый из этих механизмов стоит 1 запрос: include, a, mx, ptr, exists, redirect
# (единой команды dig для этого нет — разбирайте запись термин за термином)

# Проверьте реальным SPF-валидатором (инструмент /mailauth на MarinaDNS делает именно это)
# либо вручную разрешите каждую цель 'include:', подсчитывая вложенные include

# Симулируйте превышение лимита: добавьте достаточно механизмов include:, чтобы превысить 10, затем проверьте на permerror
# через реальную тестовую отправку (mail-tester.com или аналог) или специализированный инструмент подсчёта SPF-запросов

Исправляйте через «уплощение» (замена include: на его разрешённые IP-диапазоны напрямую, принимая компромисс по обслуживанию) или удаление неиспользуемых include — никогда не полагайтесь на то, что количество останется под 10 по мере добавления новых сервисов.

Дополнительные заметки (по ролям)

Sysadmin: каждый добавленный сторонний сервис (email-маркетинг, helpdesk, CRM), отправляющий почту «от вашего имени», обычно требует include в SPF — ведите журнал изменений, поскольку через 2 года никто не вспомнит их все, когда лимит будет превышен.
DevOps: если SPF управляется как код, дешёвая страховка — шаг CI, подсчитывающий количество запросов перед мержем — именно это автоматизирует собственный SPF Lookup Limit Check в NODA (CAT-MAIL).
Security-adjacent: домен, вообще НЕ отправляющий почту, всё равно должен публиковать v=spf1 -all (нулевая политика) — RFC 7208 §10.1 явно это рекомендует, и NODA оценивает эту проверку как безусловную именно по этой причине (раздел 6.3 Методологии).

← Вернуться к Уроку 8

Урок 9

DKIM подробно

Цель упражнения

Сгенерировать пару ключей DKIM, опубликовать запись селектора и проверить, что реальное подписанное письмо валидируется.

Почему это важно

Имена селекторов DKIM не стандартизированы (RFC 6376) — в отличие от SPF/DMARC, здесь нет фиксированного имени записи для проверки, из-за чего DKIM сложнее всего аудировать извне и легче всего незаметно настроить неправильно.

Команды для выполнения / что проверить

# Сгенерируйте пару ключей DKIM (пример с OpenSSL)
openssl genrsa -out dkim_private.pem 2048
openssl rsa -in dkim_private.pem -pubout -out dkim_public.pem

# Опубликуйте публичный ключ как TXT-запись по адресу: selector._domainkey.yourdomain.com
dig selector._domainkey.yourdomain.com TXT +short

# Отправьте реальное тестовое письмо через провайдера, настроенного подписывать этим ключом, затем изучите заголовки:
# найдите заголовок DKIM-Signature:, отметьте теги 's=' (селектор) и 'd=' (домен)

# Проверьте, что подпись валидируется относительно опубликованного ключа
dig $(echo "your-selector")._domainkey.yourdomain.com TXT +short
# сверьте вручную или через валидатор (opendkim-testkey, mail-tester.com)

Убедитесь, что имя селектора в реальном заголовке DKIM-Signature точно совпадает с опубликованным — это самая частая ошибка настройки DKIM.

Дополнительные заметки (по ролям)

Sysadmin: периодически ротируйте ключи DKIM (раз в год — разумный минимум) — публикуйте новый селектор рядом со старым, переключите отправку, ЗАТЕМ удалите старую запись селектора, повторяя паттерн ротации DNSSEC из Урока 6.
DevOps: если используете транзакционного email-провайдера (SendGrid, Postmark и т.д.), они управляют приватным ключом и дают вам только DNS-запись для публикации — ваша задача проверка, а не генерация; не предполагайте, что нужно запускать openssl самостоятельно в такой настройке.
Security-adjacent: согласно собственной Методологии NODA (раздел 6.3), проверка DKIM без найденного ключа на угаданном селекторе разрешается в Informational, а не в жёсткий Fail — отсутствие подписи на распространённом имени селектора не равнозначно подтверждённому отсутствию DKIM, поскольку имена селекторов произвольны.

← Вернуться к Уроку 9

Урок 10

DMARC подробно

Цель упражнения

Развернуть DMARC через полный цикл политики (none → quarantine → reject) и прочитать реальный агрегированный (RUA) отчёт.

Почему это важно

Переход сразу к p=reject без предварительного наблюдения за отчётами p=none рискует заблокировать собственную легитимную почту (забытый сторонний отправитель, CRM, внутренний сервис) — сама поэтапность существует именно для того, чтобы выявить и устранить такие пробелы до того, как они станут инцидентом.

Команды для выполнения / что проверить

# Прочитайте текущую DMARC-запись
dig _dmarc.yourdomain.com TXT +short

# Начните с режима наблюдения:
# v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

# После 1-2 недель реального почтового трафика изучите агрегированный RUA-отчёт (приходит как XML-вложение)
# Ищите: незнакомые исходные IP, сбои выравнивания SPF/DKIM на почте, которую вы ПРИЗНАЁТЕ легитимной

# Ужесточайте политику после того, как отчёты станут чистыми:
# v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-reports@yourdomain.com
# ... затем в итоге:
# v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

# Проверьте, что каждый этап действительно опубликован
dig _dmarc.yourdomain.com TXT +short

Используйте pct= для постепенного наращивания (например, 25/50/100), а не для мгновенного перевода всего домена на reject — это самый безопасный реальный паттерн внедрения.

Дополнительные заметки (по ролям)

Sysadmin: RUA-отчёты приходят как сжатый (gzip) XML — парсер (их много бесплатных, либо напишите свой скрипт) оправдан, как только объём превышает пару писем в день; читать сырой XML вручную не масштабируется.
DevOps: если почта отправляется из нескольких конвейеров (транзакционная почта приложения, платформа маркетинга, служба поддержки), каждый должен независимо проходить выравнивание SPF или DKIM — сбои DMARC часто указывают на ровно один забытый конвейер, а не на общедоменную ошибку конфигурации.
Security-adjacent: реальная ценность DMARC — анти-спуфинг, а не доставляемость сама по себе — согласно Методологии NODA (раздел 6.3), DMARC остаётся безусловной проверкой независимо от наличия MX, поскольку домен, не отправляющий почту, — ещё более привлекательная цель для спуфинга и всё равно нуждается в опубликованной политике.

← Вернуться к Уроку 10

Урок 11

Reverse DNS и репутация почты (выпускной урок)

Цель упражнения

Настроить корректные PTR-записи, проверить FCrDNS (Forward-Confirmed reverse DNS) и выполнить полный аудит домена как выпускное упражнение курса.

Почему это важно

Reverse DNS — самая недооценённая тема в массовых DNS-сертификациях, несмотря на то что это важнейший сигнал доставляемости: многие почтовые серверы отклоняют или помечают как спам письма с IP-адресов без PTR-записи или с несовпадающей PTR-записью — независимо от корректности SPF/DKIM/DMARC.

Команды для выполнения / что проверить

# Обратный поиск: в какое имя хоста разрешается ваш отправляющий почту IP?
dig -x your.mail.server.ip +short

# Прямое подтверждение: разрешается ли это имя хоста обратно в тот же IP? (FCrDNS)
dig +short the-ptr-hostname.example.com A

# Итоговое выпускное упражнение — пройдите все проверки предыдущих уроков по своему домену за один проход:
dig yourdomain.com A AAAA MX TXT NS SOA CAA +noall +answer
dig yourdomain.com DNSKEY DS +short
dig _dmarc.yourdomain.com TXT +short
dig selector._domainkey.yourdomain.com TXT +short
dig -x your.mail.server.ip +short

# Или проще: пропустите весь домен через саму NODA
# https://noda.marinadns.io — те же проверки, один сводный отчёт

Выпускное задание намеренно построено так: «пройдите свой домен через всё, что изучили, а затем через NODA — и сравните, совпадают ли ваши ручные находки с автоматическим отчётом».

Дополнительные заметки (по ролям)

Sysadmin: PTR-записи задаёт тот, кто контролирует IP-блок (обычно хостинг/облачный провайдер, а не ваш DNS-провайдер) — частая точка путаницы; вы часто не можете исправить PTR в той же панели, где управляете прямыми записями.
DevOps: при отправке почты с эфемерной облачной инфраструктуры (автомасштабируемые инстансы, контейнеры) PTR-записи, привязанные к конкретному IP, становятся реальным операционным ограничением — выделенный стабильный исходящий IP (или сервис-релей) обычно необходим именно потому, что PTR не может следовать за эфемерной инфраструктурой.
Security-adjacent: несовпадение FCrDNS — классический эвристический признак спам-фильтров; даже при идеальных SPF/DKIM/DMARC несовпадающая или отсутствующая PTR может серьёзно испортить доставляемость — относитесь к этому как к четвёртой составляющей наравне с трио email-аутентификации, а не как к второстепенной детали.

← Вернуться к Уроку 11