Контроль изменений у регистраторов и подмена DNS в 2019 году

Резюме

Открытые материалы 2019 года описывают общий класс отказов общей инфраструктуры, а не одну доказанную кампанию. CISA выпустила оперативную директиву после сообщений об инцидентах вмешательства в DNS; Mandiant опубликовала исследование инцидентов с указанием источника; ICANN выпустила предупреждение для сообщества, заявив, что нет признаков компрометации её собственных систем; Cisco Talos отдельно задокументировала Sea Turtle в апреле и вернулась к этой кампании в июле. Их утверждения об исполнителях, жертвах, техниках, географии и степени уверенности должны оставаться связанными с организациями, которые их сделали.[1][3][4][5][6]
Январская директива CISA сделала проблему контроля конкретной для большинства гражданских федеральных агентств исполнительной власти США. Агентствам требовалось провести аудит публичных записей DNS, сменить учётные данные для учётных записей, способных менять DNS, включить многофакторную аутентификацию там, где она доступна, и отслеживать данные Certificate Transparency по сертификатам, связанным с доменами агентств. Эти меры не означали, что каждое охваченное агентство было скомпрометировано.
Они определили средства контроля авторизации, наблюдения и восстановления, которые агентствам следовало проверить после того, как был зафиксирован класс вмешательства в инфраструктуру.[1][2]
Mandiant сообщила о манипуляциях с записями DNS, затронувших десятки государственных, телекоммуникационных и интернет-инфраструктурных доменов в нескольких регионах. Talos отдельно оценила, что Sea Turtle действовала как минимум с начала 2017 года по первый квартал 2019 года, сообщив о не менее чем 40 пострадавших организациях в 13 странах, и разграничила основные цели и инфраструктурных провайдеров, использовавшихся как промежуточные цели. Talos прямо отделила Sea Turtle от DNSpionage и сообщила об отсутствии доказательств компрометации серверов корневой зоны.[4][5]
Знакомое доменное имя и сертификат, принимаемый браузером, могут сосуществовать с несанкционированным состоянием DNS, потому что две эти проверки отвечают на ограниченные вопросы. DNS сообщает клиенту, куда, по данным опубликованной инфраструктуры, должно вести имя. Сертификат может показать, что отвечающая конечная точка владеет сертификатом, действительным для этого имени по правилам удостоверяющего центра. Ни один из этих результатов сам по себе не доказывает, что регистрант намеревался произвести предшествующее изменение регистратора, делегирования или зоны.
Talos сообщила, что сертификаты помогали некоторым перенаправленным сервисам выглядеть для пользователей подлинными.[5]
Соответствующий путь контроля идёт от учётной записи регистранта через регистратора и, для состояния домена, хранимого реестром, через транзакцию EPP к реестру; далее он достигает делегирования в родительской зоне, авторитетного DNS-сервиса, рекурсивных резолверов и конечной точки, выбранной возвращёнными записями. Выдача сертификатов и доверие браузера или приложения действуют параллельно этому пути. Поэтому ответственность нельзя приписывать «DNS», как если бы это был один администратор: каждая организация контролирует собственную границу авторизации, публикации, обнаружения, доказательств или отката.[13][14]
Наблюдения за записями NS, A, AAAA, MX, TTL и DS не взаимозаменяемы. Изменение NS может изменить сервис, являющийся авторитетным; изменение A или AAAA может перенаправить хост без изменения делегирования; изменение MX влияет на маршрутизацию почты; TTL влияет на срок хранения в кэше, а не на авторитетность назначения; запись DS участвует в цепочке DNSSEC между родителем и потомком. Говорить, что «DNS изменился», не указывая запись, зону, интерфейс управления и время наблюдения, значит скрывать и технику, и ответственного оператора.[15][16]
Ответственность должна следовать за практическим контролем, а не за институциональной близостью. Регистранты контролируют гигиену учётных записей и независимое утверждение; регистраторы контролируют аутентификацию клиентов, учётные данные EPP, уведомления и эскалацию поддержки; реестры контролируют приём и фиксацию изменений на уровне реестра и публикацию состояния делегирования; авторитетные операторы контролируют обслуживаемые данные зоны и откат; удостоверяющие центры контролируют выдачу по своим политикам; полагающиеся организации контролируют мониторинг и реагирование.
Координирующие органы могут рекомендовать или требовать защитные меры, но они не управляют каждым доменом и не утверждают каждую транзакцию.[3][7][8]
Это по своей сути аргумент о сетевой инфраструктуре. Если убрать выделение DNS, авторизацию регистратора и реестра, публикацию делегирования, авторитетно обслуживаемое состояние, поведение резолверов и доверие к сертификатам, тезис об ответственности рушится. Осталась бы общая история о компрометации учётной записи, которая не может объяснить, как несанкционированное состояние стало операционной реальностью для пользователей. Поэтому решающее доказательство — не просто украденные учётные данные, а то, какая инфраструктура приняла изменение, что она опубликовала, кто мог это наблюдать и как быстро можно было восстановить задуманное состояние.

Граница доказательств намеренно узкая

Отчётность 2019 года следует читать как последовательность публичных предупреждений о категории отказа контроля DNS. Её нельзя сжимать в единый инцидентный нарратив. У CISA, Mandiant, ICANN и Talos были разные роли, разные доказательные базы и разные аудитории. CISA обязала федеральные агентства выполнить конкретные защитные действия. Mandiant описала исследование инцидентов. ICANN предупредила участников экосистемы доменных имён и рекомендовала проверки. Talos представила выводы, относящиеся к конкретной кампании Sea Turtle.

Сходство отчётов делает сравнение полезным, но сходство не доказывает общих операторов, одинаковых жертв или общей технической последовательности.[1][3][4][5]

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

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

Доступная публичная отчётность не даёт полной истории транзакций для каждого пострадавшего домена. Она не раскрывает каждое утверждение регистратора, событие реестра, пересмотр авторитетной зоны, кэш резолвера или обмен при проверке сертификата. Поэтому утверждения об исполнителях и жертвах должны сохранять исходную атрибуцию. Количество и географическая характеристика Mandiant — это отчётность Mandiant, а даты кампании, число организаций и число стран Talos принадлежат оценке Sea Turtle от Talos.[4][5] Ни то ни другое нельзя молча применять к каждому инциденту, который лёг в основу директивы CISA.

Одинаково важны два отрицательных вывода. ICANN заявила, что у неё нет признаков компрометации её собственных систем.[3] Talos сообщила об отсутствии доказательств того, что серверы корневой зоны были атакованы или скомпрометированы.[5] Эти заявления не позволяют перейти от доказательств отказов контроля на уровне домена, регистратора, реестра или провайдера к безосновательному утверждению, что сам глобальный корень DNS был захвачен. Они также обостряют вопрос ответственности: серьёзное перенаправление может происходить через более узкие операционные интерфейсы без компрометации корня или координирующего института.

Как знакомое имя может вести к несанкционированной инфраструктуре

Пользователь может ввести правильный домен, увидеть ожидаемое написание и всё равно быть направлен туда, куда регистрант не разрешал. Имя, введённое пользователем, — только начало процесса разрешения. Рекурсивный резолвер следует делегированию, видимому в DNS, запрашивает авторитетный сервис, выбранный этим состоянием, и возвращает соответствующие адресные данные или данные маршрутизации почты. Если на управляющем уровне было принято и опубликовано несанкционированное изменение, обычное поведение DNS может честно доставить неверный операционный результат.

Предположим, родительское делегирование изменено на серверы имён, контролируемые несанкционированной стороной. Резолверы, следующие делегированию, будут запрашивать ответы у этих серверов имён. Либо делегирование может остаться неизменным, а кто-то с доступом к существующему авторитетному DNS-сервису изменит запись A или AAAA. В этом случае регистратор и реестр могут вообще не показать изменений, однако пользователи всё равно могут быть направлены на другую конечную точку. Третий случай может касаться изменения MX, влияющего на почту, тогда как веб-сайт продолжает разрешаться нормально.

Видимый симптом зависит от конкретного изменённого состояния, а не от широкой метки «вмешательство в DNS».

Транспортная безопасность начинается после того, как разрешение имени выбрало конечную точку. Браузер обычно проверяет, предъявляет ли конечная точка сертификат, чей идентификатор покрывает запрошенное имя, ведёт ли он к принятому якорю доверия и соответствует ли он применимым проверкам действительности. Этот процесс обычно не сверяется с планируемым реестром серверов регистранта и не спрашивает, была ли недавняя транзакция регистратора утверждена через внутренний процесс изменений организации.

Контроль над соответствующим путём проверки домена может поэтому создавать обстоятельства, при которых сертификат выдаётся по правилам удостоверяющего центра для инфраструктуры, которую регистрант не намеревался авторизовать. Полученный сертификат может быть криптографически действительным и заставлять браузер показывать обычный индикатор защищённого соединения. Этот индикатор говорит нечто важное о сертификате и зашифрованном соединении, но не удостоверяет легитимность предшествующего изменения DNS.

Talos сообщила, что операторы Sea Turtle перенаправляли трафик после получения контроля над записями DNS и в некоторых случаях использовали сертификаты, которые делали перенаправленный сервис подлинным для браузера.[5] Этот вывод принадлежит отчётности Talos о кампании; его не следует обобщать на каждый инцидент, обсуждаемый CISA, ICANN или Mandiant. Тем не менее требование CISA отслеживать данные Certificate Transparency показательно. Наблюдение за сертификатами может выявить последствие смены контроля над доменом, даже если сама модификация DNS была пропущена основным мониторингом организации.[1]

Таким образом, подлинно выглядящее соединение может стоять в конце несанкционированной, но технически согласованной цепочки. Резолвер следует опубликованному состоянию DNS. Конечная точка предъявляет сертификат, принятый для запрошенного имени. Браузер шифрует сессию. Каждый компонент может выполнять свою узкую протокольную функцию, хотя общий результат противоречит намерению организации. Отказ ответственности находится в разрыве между протокольно действительным состоянием и авторизованным состоянием — и в том, сохранили ли контролирующие это состояние организации достаточно доказательств, чтобы выявить, сдержать и отменить изменение.

Отдельные потоки отчётности в 2019 году

Январь: оперативная директива CISA

22 января 2019 года CISA выпустила чрезвычайную директиву 19-01 в ответ на серию зафиксированных инцидентов вмешательства в инфраструктуру DNS. Её обязательная аудитория — большинство гражданских федеральных агентств исполнительной власти США, а не каждый регистратор, реестр или частный оператор в мире. Директива предписывала агентствам провести аудит публичных записей DNS, сбросить учётные данные для учётных записей, способных изменять DNS, включить многофакторную аутентификацию там, где она доступна, и отслеживать данные Certificate Transparency по сертификатам, выданным в связи с доменами агентств.[1]

Эти требования раскрывают модель отказа, которую CISA хотела проверить в агентствах. Аудит сравнивает задуманные записи с внешне видимым состоянием. Смена учётных данных учитывает возможность того, что существующие административные секреты больше не заслуживают доверия. Многофакторная аутентификация добавляет ещё одну границу авторизации, хотя и не гарантирует защиту от любой компрометации. Мониторинг Certificate Transparency даёт точку наблюдения за пределами учётной записи регистратора и авторитетного DNS.

Сопроводительные материалы CISA трактовали проблему как межграничный инфраструктурный риск, а не как основание считать, что каждое агентство или каждый слой DNS отказал одинаково.[2]

Директива — это доказательство того, что угроза требовала срочной операционной проверки. Она не является решением об ответственности одного исполнителя за каждый precipитирующий инцидент. Она также не устанавливает, что каждое охваченное агентство обнаружило вредоносные записи. Её доказательная ценность уже и полезнее: она определяет средства контроля, которые крупный государственный оператор счёл необходимыми, когда доверие к административному состоянию DNS больше нельзя было предполагать.

Январь: исследование инцидентов Mandiant

Январская отчётность Mandiant была отдельным исследовательским потоком. Компания сообщила о волне перехватов DNS, затронувших десятки государственных, телекоммуникационных и интернет-инфраструктурных доменов в нескольких регионах. Она описала, как злоумышленники получали доступ, позволявший менять записи DNS, и направляли трафик на инфраструктуру под контролем злоумышленников.[4]

Эти утверждения должны оставаться атрибутированными Mandiant. «Десятки» — не универсальная цифра для всех инцидентов, позже упомянутых CISA или ICANN, и географическую характеристику Mandiant не следует переносить на отдельно подсчитанных жертв Sea Turtle у Talos. Отчёт подтверждает существование широкой проблемы манипуляции записями DNS и помогает объяснить, почему доступ к регистраторам, реестрам или DNS-операторам мог иметь последствия, выходящие за пределы обычного взлома учётной записи. Сам по себе он не доказывает, что каждая организация пережила одинаковое изменение записи, certifikátную последовательность или точку компрометации.

Разница между ролью Mandiant и CISA существенна. Mandiant описала наблюдения и оценённую картину инцидентов. CISA перевела публичный риск в обязательные федеральные действия. Рассматривать их как один отчёт значило бы стереть различие между атрибутированными выводами исследователя и защитной директивой государственного органа.

Февраль: предупреждение ICANN для экосистемы

Предупреждение ICANN от 15 февраля привлекло внимание к риску в экосистеме регистрации доменов. Оно ссылалось на директиву CISA, исследование Mandiant и другие публичные сообщения, при этом заявляя, что у ICANN нет признаков компрометации её собственных систем.[3] Это предложение — не сноска, которую можно отбросить. Оно определяет институциональную границу утверждения ICANN.

ICANN рекомендовала меры, включая многофакторную аутентификацию для административного доступа, проверку записей регистрации домена и серверов имён, улучшение гигиены учётных данных и мониторинг важного состояния домена.[3] Эти рекомендации отражали координирующую позицию ICANN, но не означали, что ICANN управляет учётной записью регистратора, авторитетной зоной или процессом восстановления для каждого пострадавшего имени. Регистратор может обслуживать клиентский интерфейс и канал EPP. Реестр может хранить объект домена и делегирование родительской зоны. Отдельный провайдер может размещать авторитетную зону.

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

Более ранняя работа Консультативного комитета по безопасности и стабильности ICANN уже обсуждала перехват доменов, регистрационные сервисы, блокировки, аутентификацию и границы аварийного восстановления.[7][8] Руководство для регистрантов также подчёркивало защитные практики учётных записей и важность документации при попытке восстановить перехваченный домен.[9][10] Февральское предупреждение, таким образом, не изобрело проблему контроля. Оно показало, что ранее признанные регистрационные риски стали достаточно срочными, чтобы потребовать новой проверки всей экосистемы.

Апрель: Talos выделяет Sea Turtle как отдельную кампанию

В апрельском отчёте Cisco Talos описала Sea Turtle как отдельную операцию, действовавшую как минимум с начала 2017 года по первый квартал 2019 года. Talos сообщила о не менее чем 40 пострадавших организациях в 13 странах и отделила основные цели от вторичных инфраструктурных провайдеров, включая регистраторов, телекоммуникационные компании, интернет-провайдеров и один реестр.[5] Эти числа и классификации — оценка Talos по Sea Turtle; они не являются итогами по каждому DNS-инциденту, обсуждавшемуся в 2019 году.

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

Talos прямо отличила Sea Turtle от DNSpionage.[5] Схожее использование манипуляций DNS не делает кампании взаимозаменяемыми. Sea Turtle также должна оставаться отделённой от всей совокупности событий, стоящих за директивой CISA, и от каждого инцидента, описанного Mandiant. Talos дополнительно сообщила об отсутствии доказательств того, что серверы корневой зоны были атакованы или скомпрометированы. Значение кампании возникло из контроля над более узкими, но мощными инфраструктурными зависимостями, а не из контроля над корнем DNS.

Июль: Talos возвращается к Sea Turtle

Talos вернулась к Sea Turtle в июле в отдельном дополнительном отчёте.[6] Эту более позднюю публикацию следует рассматривать как ещё одну временную отметку в отчётности Talos по конкретной кампании, а не как разрешение объединить Sea Turtle с DNSpionage, добавить несвязанные инциденты CISA к числу её жертв или задним числом считать каждое апрельское наблюдение фактом, установленным всеми остальными источниками.

Апрельский и июльский отчёты выполняют разные хронологические функции. Апрельский отчёт изложил основную характеристику кампании Talos, её охват и различие инфраструктурных провайдеров. Июльский отчёт показал, что Talos продолжала отслеживать и освещать операцию после первоначального публичного раскрытия.[5][6] Любое добавленное наблюдение относится к этой более поздней дате отчётности и к доказательной базе Talos. Раздельное рассмотрение публикаций сохраняет, когда утверждение стало публичным, чья уверенность его поддерживала и на какие решения о реагировании можно было разумно опираться.

Сквозной путь управления DNS

Контроль изменений DNS нельзя оценивать на одной консоли, потому что операционный путь пересекает несколько независимо администрируемых систем. Одна и та же компания может выполнять более одной роли, но роли остаются аналитически разными.

Регистрант начинает с организационного намерения. Он решает, кто может управлять доменом, каких регистратора и DNS-провайдеров использовать, какие серверы имён и записи должны существовать и как следует утверждать изменения. Его самые сильные доказательства — назначенные администраторы, отдельные контакты восстановления, защищённые учётные данные, внутренние утверждения и независимо поддерживаемая запись ожидаемого состояния DNS. Если регистрант не может установить, что он намеревался сделать, восстановление становится труднее, даже если провайдер сохранил технически полные журналы.

Регистратор предоставляет обращённую к регистранту учётную запись и обычно действует как клиент, выделяющий состояние домена, хранимое реестром. Его обязанности включают аутентификацию клиентов, разделение привилегий, защиту учётных данных EPP, журналирование транзакций, уведомления об изменениях и путь эскалации, способный реагировать, когда обычная учётная запись подозревается в компрометации.

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

EPP предоставляет структурированный канал, через который регистратор может создавать, обновлять, передавать или иным образом управлять объектом домена в реестре. RFC 5731 определяет команды объекта домена и семантику статусов; он не решает, обладал ли человек или система, инициировавшая разрешённую команду, подлинной организационной авторизацией регистранта.[13] Протокольно действительное исполнение — это доказательство того, что принятая команда произошла, а не решающее доказательство легитимности лежащего в основе решения.

Реестр фиксирует состояние домена на уровне своего домена верхнего уровня, применяет серверные статусы там, где уместно, и публикует делегирование родительской зоны, полученное из принятых данных. Это операционный журнал и хранитель записей для этого слоя, а не верховный судья задуманной онлайн-идентичности каждой организации. Его ответственность касается того, были ли изменения приняты по авторизованным каналам, были ли доступны более строгие ограничения или внеполосные процедуры, какие доказательства транзакций были сохранены и как быстро спорное состояние можно было остановить или отменить.

Делегирование связывает родительскую зону с авторитетным сервисом дочернего домена. Данные NS на родительской стороне указывают серверы имён, к которым должны обращаться резолверы, а glue-адреса могут публиковаться, когда необходимо сделать эти серверы имён достижимыми. Данные DS, когда они есть, связывают аутентифицированное представление родителя с материалом DNSSEC у потомка. Это мощные утверждения, но они не содержат каждую запись, обслуживаемую дочерней зоной.

Авторитетный DNS-оператор публикует операционные ответы дочерней зоны. Это может быть регистратор, регистрант или независимый управляемый DNS-провайдер. Его система часто может менять записи A, AAAA, MX, TXT и другие без какого-либо обновления EPP или транзакции реестра. Эта граница критична: неизменная история реестра не доказывает, что обслуживаемая зона осталась неизменной. Журналы доступа авторитетного оператора, история версий, снимки зоны, средства утверждения и возможность отката могут быть единственным прямым доказательством изменения на уровне записи.

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

Конечная точка, выбранная DNS, участвует в отдельном уровне сертификатов и приложений. Удостоверяющие центры решают, выдавать ли сертификат по своим правилам проверки. Системы Certificate Transparency создают внешний канал наблюдения. Браузеры и приложения решают, принимать ли предъявленный сертификат и устанавливать зашифрованное соединение. Эти средства могут выявлять или ограничивать злоупотребления, но не заменяют записи утверждений регистратора, доказательства транзакций реестра или историю авторитетной зоны.

У каждого звена своя функция отката. Регистрант может отозвать полномочия и предоставить доказательства задуманного состояния. Регистратор может защитить клиентскую учётную запись и внести корректирующие изменения в реестр. Реестр может ограничить или отменить состояние, хранимое на его уровне. Авторитетный оператор может восстановить предыдущую версию зоны. Резолверы обычно удаляют кэшированные данные по применимым TTL, а срочные вмешательства могут требовать дополнительной координации. Удостоверяющие центры могут действовать в рамках своих процессов отзыва и выдачи.

Ни один участник не может надёжно реконструировать или отменить всю цепочку без доказательств и сотрудничества с остальными.

Типы записей должны оставаться отдельными основаниями ответственности

Отчёт об инциденте, в котором сказано только «запись DNS была изменена», оставляет центральный вопрос контроля без ответа. Тип записи, зона, в которой она появилась, интерфейс, использованный для её изменения, и время наблюдения определяют и операционный эффект, и вероятного держателя доказательств.

Утверждение обNSкасается авторитетности серверов имён. Данные NS родительской зоны могут перенаправить разрешение к другому авторитетному сервису. Дочерняя зона также обычно содержит набор NS в вершине, и эти два представления могут различаться при ошибке, переходе или злоупотреблении. Доказательство того, что наблюдатель получил ответ от неожиданного сервера имён, не доказывает автоматически, что реестр был скомпрометирован. Следователи должны определить, изменилось ли родительское делегирование, были ли задействованы кэшированные данные, изменился ли glue и не обслуживал ли сам ожидаемый авторитетный провайдер изменённую информацию.

Утверждение обAсвязывает имя с IPv4-адресом, а утверждение обAAAA— с IPv6-адресом. Любое из них может перенаправить веб- или прикладную конечную точку без изменения делегирования домена. Администратор зоны у авторитетного провайдера может менять эти записи напрямую. Доказательство изменения записи A поэтому нельзя пересказывать как доказательство транзакции EPP, компрометации регистратора или изменения реестра, если только подтверждающие записи не устанавливают этот путь. Наблюдения IPv4 и IPv6 также должны оставаться раздельными, потому что клиенты могут выбирать разные семейства адресов и видеть разные пункты назначения.

Утверждение обMXкасается маршрутизации почты. Его изменение может направить электронную почту на другую принимающую инфраструктуру, даже если веб-записи A и AAAA остаются правильными. Пункт назначения, указанный в записи MX, затем требует собственного разрешения адреса. Инцидент с почтовой маршрутизацией, следовательно, может затрагивать набор записей MX, адресные записи почтового хоста или и то и другое. Его не следует описывать как перенаправление веб-сайта, если веб-записи тоже не изменились.

Утверждение оTTLкасается срока жизни в кэше. TTL не назначает правомерного оператора и сам по себе не направляет трафик к пункту назначения. Он влияет на то, как долго резолверы могут повторно использовать ответ, и потому воздействует на распространение, устойчивость, наблюдение и откат. Низкий TTL может позволить изменённым данным быстрее распространяться и позже быстрее очищаться; высокий TTL может дольше оставлять прежние данные в кэшах. Ни одно значение само по себе не доказывает злого умысла. Исторические наблюдения TTL полезны только в привязке к конкретному набору записей, ответу и времени.

Утверждение оDSкасается делегирования DNSSEC. Данные DS у родителя связывают делегирование потомка с ключевым материалом DNSSEC и помогают установить аутентифицированную цепочку доверия. RFC 5910 определяет, как связанные с DNSSEC данные могут быть представлены в EPP, а основные спецификации DNSSEC описывают, как валидаторы аутентифицируют DNS-данные через настроенную цепочку.[14][15][16] Валидация DNSSEC может показать, что ответ согласуется с этой цепочкой; она не устанавливает, что организация намеревалась совершить каждое действие по выделению, создавшее текущее состояние цепочки.

Поэтому DNSSEC — не универсальный ответ на скомпрометированные полномочия выделения. Если неавторизованный оператор может использовать канал, который регистратор, реестр или DNS-провайдер принимает как авторизованный, этот оператор может изменить делегирование или состояние, связанное с DNSSEC. Получившаяся цепочка доверия может затем аутентифицировать состояние, противоречащее намерению регистранта. Операционное руководство по DNSSEC подчёркивает аккуратное управление ключами, делегированием и ротацией именно потому, что доступность и подлинность зависят от скоординированного состояния через административные границы.[17]

Более поздние стандарты об усилении авторизации EPP и операциях DNSSEC могут информировать нынешнее проектирование контроля, но их нельзя считать доказательством того, что каждый оператор развернул эти средства во время событий 2019 года.[18][21] Исторический вопрос ответственности остаётся конкретным: какой интерфейс принял спорное изменение, какая система его опубликовала, какие доказательства его зафиксировали, и какая сторона могла его отменить?

Наконец,делегирование— это составное операционное утверждение, а не синоним каждой записи DNS. Оно охватывает указание родителя на авторитетные серверы имён и может включать glue и связь DNSSEC. Вредоносная запись A, обслуженная существующим авторитетным провайдером регистранта, — серьёзная компрометация DNS, но это не обязательно изменение делегирования. Напротив, изменённое делегирование может сместить контроль над многими ответами дочерней зоны, не требуя редактирования каждой прежней записи A, AAAA или MX по отдельности.

Эти различия определяют, какие выводы можно делать ответственно. Неожиданный адрес доказывает наблюдаемый ответ, а не его историю авторизации. Неожиданный сервер имён указывает на расхождение делегирования или авторитетности, а не автоматически на компрометацию корневой зоны. Сертификат, принятый для имени, устанавливает результат на уровне сертификата, а не утверждение DNS-транзакции.

Только объединённая хронология записей регистратора, истории EPP и реестра, состояния родительской зоны, версий авторитетной зоны, наблюдений резолверов и сертификатных доказательств может показать, как несанкционированное административное состояние стало сетевым состоянием, которое реально получили пользователи.

Алерты 2019 года превратили каждую границу контроля в границу доказательств

Реакция 2019 года показала, что «владелец домена» был слишком неточной единицей ответственности. CISA обязала затронутые федеральные агентства провести аудит публичных записей DNS, сбросить учётные данные для учётных записей, способных изменять DNS, включить многофакторную аутентификацию там, где она доступна, и отслеживать данные Certificate Transparency.

Её сопроводительное руководство поместило эти меры в более широкую работу по обнаружению и ограничению вмешательства в DNS-инфраструктуру.[1][2] Аналогично ICANN призвала регистрантов и операторов проверять записи домена и серверов имён, усилить административный доступ и отслеживать несанкционированные изменения, заявив, что у неё нет признаков компрометации её собственных систем.[3]

Эти меры пересекли несколько независимо управляемых систем. Регистрант мог защитить свою учётную запись, но не мог проверить привилегированную активность поддержки регистратора. Регистратор мог аутентифицировать клиента и передать команду EPP, но не мог определить, что каждый рекурсивный резолвер ещё хранит в кэше. Реестр мог записать принятое обновление и опубликовать делегирование, не зная, отражало ли решение регистратора об авторизации реальное намерение регистранта. Авторитетный DNS-оператор мог восстановить зону, но не мог отозвать неожиданно выданный сертификат.

Поэтому ответственность должна следовать за практическим контролем, сохранёнными доказательствами, видимостью отказа и реальными полномочиями на восстановление.

Сторона	Практический контроль	Доказательства, которые следует сохранять	Видимость отказа	Полномочия на восстановление
Регистрант	Административные учётные записи, назначенные контакты, утверждение задуманных изменений, выбор провайдера и внутреннее разделение обязанностей	История доступа к учётной записи, события регистрации и восстановления MFA, изменения контактов, внутренние утверждения, уведомления провайдера и независимые снимки ожидаемого состояния DNS	Может сравнивать задуманную конфигурацию с панелями провайдера, уведомлениями и внешними наблюдениями, но может не видеть внутренности регистратора, реестра или авторитетного оператора	Может сбросить свои учётные записи, заменить контакты, отозвать внутренний доступ и запросить восстановление; обычно не может напрямую переписать записи реестра, журналы провайдера или записи удостоверяющего центра
Регистратор	Аутентификация клиентов, привилегированный доступ поддержки, блокировки на стороне регистратора, клиентские учётные данные EPP, подача обновлений домена и эскалация в реестр	События аутентификации, хронология поддержки, журналы привилегированного доступа, идентификаторы транзакций EPP, значения объекта до и после, история статусов, уведомления и аварийные действия	Может видеть активность клиентской учётной записи и EPP, но не всегда сразу видит все авторитетные ответы, кэшированные ответы или последующее использование сертификатов	Может заморозить изменения клиента, сбросить учётные данные, восстановить управляемые регистратором настройки, подать корректирующие команды EPP и задействовать аварийные процедуры реестра
Реестр	Приём изменений EPP, серверный статус домена, публикация делегирования родительской зоны, процедуры блокировки реестра и, где предлагается, внеполосное подтверждение	Записи сервера EPP, идентификаторы транзакций клиента и сервера, история статуса домена, история делегирования и DS, утверждения блокировок и отметки времени публикации	Может видеть, что подал спонсирующий регистратор и что принял реестр, но не обязательно, отражало ли представленное подлинную организационную авторизацию	Может отклонить или отменить разрешённые изменения, наложить серверные ограничения, восстановить записанное состояние и координировать исключительное восстановление в рамках своих технических и политических полномочий
Авторитетный DNS-оператор	Администрирование зоны, публикация авторитетных записей, операции подписывания, журналирование, контроль версий и откат	Версии зоны, тикеты изменений, административные и API-журналы, история подписывания DNSSEC, журналы ответов, где сохраняются, отметки времени публикации и записи отката	Может видеть обслуживаемую им зону и собственные административные события, но не обязательно изменения у регистратора, реестра, удостоверяющего центра или на рекурсивном уровне	Может восстановить предыдущую утверждённую зону, ротировать скомпрометированные учётные данные оператора и проверить авторитетный сервис; сам не может исправить изменённое родительское делегирование или запись DS
Удостоверяющий центр	Проверка контроля домена, выдача сертификатов, отзыв и сохранение записей проверки	Метод и результат проверки, отметки времени запроса и выдачи, идентификаторы сертификатов, активность отзыва и связанные аудиторские записи	Может видеть, было ли выполнено условие проверки, но не то, имела ли сторона, его выполнившая, организационную авторизацию	Может остановить, отозвать или заменить сертификаты по своим процедурам; не может восстановить DNS или определить всю цепочку владения инцидентом
Полагающаяся сторона	Внешний мониторинг DNS и сертификатов, реагирование приложений, управление сессиями, защита учётных данных и коммуникация с пользователями	Наблюдения резолверов, предупреждения Certificate Transparency, журналы приложений и идентичности, уведомления об инцидентах, сбросы и пост-ремонтные проверки	Может увидеть пользовательское перенаправление, аномалии аутентификации или изменения сертификатов раньше, чем провайдер подтвердит причину на уровне управления	Может защитить своих пользователей и системы, аннулировать сессии, сбросить учётные данные, ограничить затронутые сервисы и сообщить о риске; не может переписать инфраструктуру другого оператора
Публичный или координирующий орган	Директивы, рекомендации, каналы отчётности, координация сектора и требования в рамках определённого мандата	Уведомления, отметки времени рекомендаций, представления, записи координации и ответы о соблюдении	Может агрегировать отчёты организаций, но обычно не имеет полного доступа к частным операционным журналам	Может координировать и требовать ограниченные действия там, где уполномочен; не управляет каждой учётной записью регистранта, регистратором, реестром, сервером имён или удостоверяющим центром

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

Отчётность Mandiant, два расследования Talos и федеральные предупреждения описали пересекающиеся аспекты класса отказов, но не установили, что каждый наблюдавшийся инцидент принадлежал одной кампании или следовал идентичной цепочке.[4][5][6] Talos отличила Sea Turtle от DNSpionage и сообщила об отсутствии доказательств компрометации серверов корневой зоны.[5] Эта граница важна: ответственность следует проверять против фактического контроля и доказательств стороны, а не приписывать коллективно «DNS».

Контроль регистранта после январских и февральских предупреждений

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

Более раннее руководство ICANN уже подчёркивало блокировки регистратора, защиту учётных записей и точность контактной информации, а руководство по восстановлению — важность документации, когда перехваченное имя нужно восстановить.[7][9][10]

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

Проектирование восстановления заслуживает такого же внимания, как проектирование входа. Регистрация, удаление и восстановление MFA должны создавать долговечные записи и независимые уведомления. Процесс поддержки, способный отключить MFA после слабых биографических вопросов, может стать параллельной системой аутентификации с меньшей надёжностью, чем основной вход. Адрес восстановления, размещённый исключительно внутри затронутого домена, может также стать ненадёжным, когда маршрутизация почты или делегирование оспариваются.

Руководство ICANN для регистрантов и по восстановлению поддерживает ведение точной, пригодной для использования контактной документации и документации владения, но публичные материалы не показывают, какие конкретные жертвы внедрили эти практики до алертов 2019 года.[9][10]

Независимый мониторинг расширяет видимость регистранта за пределы панели провайдера. Регистрант должен сохранять запись ожидаемого состояния и сравнивать её с авторитетными ответами и наблюдениями из нескольких внешних сетей. Это не делает регистранта ответственным за учётные данные EPP регистратора, серверные средства реестра, журналы внешнего DNS-оператора или решение удостоверяющего центра о проверке. Это даёт регистранту доказательства для обнаружения расхождения и обращения к правильному оператору за действием.

Контроль изменений у регистратора стал центральной проверкой ответственности

Регистратор находится на значимой границе: он переводит авторизацию клиента в изменения, которые может принять реестр. Поэтому ответственность регистратора выходит за пределы того, был ли правильным обычный пароль клиента. Она включает аутентификацию клиентов, обработку MFA и восстановления, привилегированный доступ поддержки, внутренние административные инструменты, защиту клиентских учётных данных EPP, уведомления об изменениях и способность эскалировать чрезвычайную ситуацию.

SAC040 поместил аутентификацию, операционную безопасность и защиту регистрационных сервисов в центр мер против злоупотреблений за годы до событий 2019 года.[8] Алерты 2019 года сделали доказательные последствия труднее игнорируемыми. Если появилось несанкционированное изменение, следователям нужно было знать, пришло ли оно через обычный клиентский интерфейс, процесс восстановления, сотрудника поддержки, внутреннюю привилегированную учётную запись или канал регистратора к реестру. Общая аудиторская запись о том, что «учётная запись изменилась», не различала эти возможности.

Поэтому каждое чувствительное действие регистратора должно создавать неизменяемую или независимо защищённую историю изменений. Эта история должна идентифицировать аутентифицированного субъекта, действующую привилегированную учётную запись, если она отличается, состояние MFA, использованный путь восстановления или поддержки, старые и новые значения, соответствующее состояние блокировки, идентификаторы клиентских и серверных транзакций, возвращённые EPP, и отправленные клиенту уведомления.

Доменное отображение EPP предоставляет определённую семантику обновлений и статусов, делая изменения объекта домена записываемыми структурированно.[13] Когда данные DNSSEC выделяются через EPP, его отдельное расширение аналогично делает добавления, удаления и замены данных безопасности событиями, которые можно логировать и сверять.[14]

Привилегированная поддержка заслуживает отдельного рассмотрения, потому что она часто существует именно для случаев, когда обычная аутентификация отказывает. Аварийный доступ может быть необходим, но он не должен исчезать в нерасчленённой записи службы поддержки. Хронология поддержки должна показывать, кто открыл обращение, какие доказательства были представлены, кто утвердил любое обходное действие, какое изменение было сделано, когда уведомили регистранта и произошло ли независимое обратное подтверждение по телефону или иному внеполосному каналу. Общие идентификаторы поддержки и изменяемые заметки мешают и ответственности, и восстановлению.

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

Регистратору также нужен документированный аварийный путь эскалации к реестру и авторитетному оператору. Этот путь должен позволять замораживать спорное изменение, пока записи сохраняются, а не поощрять многократные правки, уничтожающие хронологию. Регистратор должен уметь определять последнее проверенное состояние и связывать каждую попытку ремонта с записью транзакции EPP. Ничто из этого не устанавливает, что контроль регистратора отказал в каждом инциденте 2019 года; публичная отчётность не даёт полного набора журналов регистраторов или внутренних решений. Это устанавливает, какие доказательства необходимы для ограниченного вывода.

Записи реестра: операционные полномочия без суверенного владения

Реестр фиксирует объекты доменов, принимает или отклоняет изменения от авторизованных клиентов-регистраторов и публикует соответствующее состояние делегирования в свою зону. RFC 5731 определяет клиентские и серверные значения статусов и семантику обновлений и передач доменов.[13] Эти статусы позволяют провести важное различие: ограничение на стороне регистратора и ограничение, наложенное реестром, — это не один и тот же контроль, даже когда оба неформально называют «блокировкой».

Запись реестра — авторитетное доказательство того, что его системы приняли и опубликовали. Она не является решающим доказательством того, что человек или организация действительно намеревались произвести изменение. Аутентифицированная сессия регистратора может показать маршрут, по которому пришла транзакция; она не решает, была ли учётная запись регистратора, путь поддержки или внутренняя привилегия использованы надлежаще. Поэтому реестр — это журнал и операционный хранитель записей, а не суверенный владелец легитимности домена.

Эта роль журнала всё же несёт существенные обязанности. Реестр должен сохранять историю серверных статусов, спонсирующего регистратора, принятые идентификаторы транзакций, прежнее и результирующее делегирование, соответствующие отметки времени и любые изменения DS. Если спорное обновление отменяется, отмена не должна перезаписывать исходное событие. Снимки до и после, а также хронология только на добавление позволяют следователям различать исходное несанкционированное состояние, действия по сдерживанию и окончательное восстановление.

Сервис блокировки реестра может создать более сильное трение, применяя серверные ограничения и требуя внеполосного процесса, прежде чем изменения с высоким эффектом будут приняты. Точная реализация различается, поэтому одна метка не является доказательством конкретного контроля. Доказательства должны показывать, какие статусы были активны, какие категории изменений они покрывали, кто запросил снятие, кто подтвердил его, через какой независимый канал и на какое окно времени. Блокировку реестра всё же могут подорвать недостатки регистрации, подтверждения, аварийного обхода или привилегированного управления; ни один контроль не безотказен.

Восстановление реестра также имеет пределы. Реестр может ограничить или восстановить объект домена и перепубликовать данные делегирования, но он не контролирует автоматически дочернюю зону, кэшированное состояние резолверов, сертификаты, сессии приложений или учётные данные, уже раскрытые в другом месте.

Рамочная модель ICANN для ответов реестров даёт координирующий контекст для угроз безопасности, но не делает каждый реестр универсальным командующим инцидентом.[12] Отчёт Инициативы по содействию безопасности DNS 2021 года предлагает более поздний ретроспективный анализ контроля и не должен считаться доказательством средств, развёрнутых в реестрах в 2019 году.[11]

Доказательства авторитетного DNS и восстановление с учётом TTL

Авторитетный DNS-оператор контролирует, что его серверы публикуют из зоны под его управлением. Это обслуживаемое состояние — операционная реальность, которую видят резолверы, с учётом делегирования и кэширования. Ответственность на этом уровне требует большего, чем текущий экспорт файла зоны. Оператор должен сохранять версионированные снимки зоны, административные и API-журналы доступа, запросы изменений, идентичность утвердившего, время публикации, события подписывания и действия отката.

Снимки записей до и после должны охватывать записи, существенные для инцидента, и окружающий контекст делегирования. Они должны включать время сбора, точку наблюдения, TTL, результат проверки DNSSEC, где применимо, и достаточно происхождения, чтобы отличить отображение панели провайдера от ответа, реально обслуженного авторитетной системой. Цель — не предполагать, что каждый зафиксированный инцидент изменил каждый тип записи. Цель — задокументировать, какое состояние изменилось в рассматриваемом случае.

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

DNSSEC добавляет ещё один слой доказательств, но не схлопывает цепочку ответственности. Его основные спецификации описывают аутентификацию DNS-данных и валидацию через настроенную цепочку доверия.[15][16] Операционное руководство объясняет аккуратность, требуемую при подписывании и управлении ключами.[17] Если авторизованные каналы выделения скомпрометированы и через эти каналы изменено делегирование или состояние DS, получившаяся цепочка может аутентифицировать состояние, не представляющее истинного намерения организации.

Поэтому запись восстановления нуждается и в истории подписывания дочерней зоны, и в истории DS на родительской стороне, с отметками времени и происхождением транзакций. RFC 9364 обсуждает более позднюю автоматизацию начальной настройки DNSSEC; это более поздний стандартный контекст, а не доказательство того, что такая автоматизация защищала организации, обсуждаемые в 2019 году.[21]

Сертификаты могли выглядеть действительными, не доказывая организационного согласия

Реакция 2019 года также выявила предел того, что может устанавливать действительный сертификат. CISA потребовала от агентств отслеживать данные Certificate Transparency, а публичная отчётность об инцидентах описала случаи, когда перенаправленные сервисы использовали сертификаты, выглядевшие действительными для браузеров.[1][4][5] Это не означает, что сертификаты были обязательно поддельными. Если условие проверки контроля домена удостоверяющего центра было выполнено, пока контроль DNS был несанкционированным, выдача могла быть технически действительной по процессу удостоверяющего центра, но лишённой авторизации затронутой организации.

Удостоверяющий центр должен сохранять метод проверки, полученные доказательства, время запроса, результат проверки, выдающий аккаунт, идентификаторы сертификата и любое последующее действие по отзыву или замене. Эти записи отвечают, следовал ли удостоверяющий центр своей процедуре контроля домена. Сами по себе они не отвечают, кто внутри регистранта намеревался сделать запрос и был ли контроль домена легитимным.

Мониторинг Certificate Transparency даёт регистрантам и полагающимся сторонам независимый канал обнаружения. Предупреждение следует сохранять с идентификатором сертификата, наблюдаемыми именами, отметкой времени журнала, временем доставки предупреждения и результатом разбора. Предупреждение — не доказательство того, что сертификат был вредоносным или использовался в инциденте; это повод сравнить выдачу с известной организационной активностью. Аналогично отсутствие предупреждения не доказывает, что состояние DNS осталось правильным.

Полагающиеся стороны контролируют другую часть восстановления. Они могут изучать журналы резолверов, приложений и идентичности; приостанавливать затронутые потоки аутентификации; аннулировать сессии; сбрасывать учётные данные; предупреждать пользователей; подтверждать, что сервисы достигают задуманных систем после ремонта DNS.

Текущая таксономия доверия к доменам CISA помогает описывать более широкий риск инфраструктуры домена, контролируемой противником, но это сегодняшний аналитический контекст, а не доказательство того, что какая-либо организация обнаружила или развернула в 2019 году.[20] Руководство NIST по развёртыванию DNS аналогично даёт операционный контекст; его не следует читать как перечень средств контроля, действовавших во время алертов.[19]

Блокировка регистратора, блокировка реестра и пределы каналов восстановления

«Заблокируйте домен» — полезный совет только тогда, когда контроль назван точно. Блокировка регистратора обычно соответствует клиентскому запрету передачи или другому ограничению, управляемому регистратором. Она может снизить риск несанкционированной передачи, но ограничение передачи не обязательно предотвращает каждое изменение серверов имён, DNS-хостинга, контактов или DNSSEC, доступное через скомпрометированную учётную запись. Активные значения статусов и покрываемые операции должны проверяться, а не выводиться из ярлыка на панели.[13]

Блокировка реестра обычно накладывает ограничения на уровне реестра и может требовать дополнительного подтверждения, прежде чем реестр примет указанные изменения. Эта дополнительная граница может оставаться эффективной, когда обычная учётная запись регистратора скомпрометирована, но она не абсолютна. Её ценность зависит от целостности регистрации, диапазона защищаемых операций, отделённости канала подтверждения, средств контроля привилегированного обхода и качества аварийных процедур.

Данные авторизации передачи представляют связанную, но более узкую проблему контроля. RFC 9154 позже усилил обработку авторизационной информации передачи EPP. Поскольку он появился после алертов 2019 года, он полезен как более поздний стандартный контекст, а не доказательство того, что усиленный механизм был развёрнут во время описываемых событий.[18] Средства контроля передачи также не следует путать со средствами контроля обычных обновлений или публикации делегирования.

MFA ограничена аналогичным образом. Она может снизить вероятность того, что одного украденного пароля достаточно, поэтому CISA и ICANN подчёркивали её в реакции 2019 года.[1][3] Её эффект зависит от того, какие учётные записи покрыты, используют ли привилегированная поддержка и API-доступ эквивалентные защитные меры, как утверждаются изменения регистрации и как работает восстановление. Слабый канал восстановления может нейтрализовать сильный фактор входа. Скомпрометированная аутентифицированная сессия, злонамеренный инсайдер или плохо управляемый аварийный обход могут обойти предположение, что «MFA была включена».

Соответствующее доказательство — не сегодняшняя галочка, а история регистрации, вызовов, восстановления и обхода на момент изменения.

Реконструкция инцидента от предотвращения до долговечного доказательства

Защитимая последовательность реагирования разделяет шесть функций, которые часто сжимают в одну инструкцию «защитить и восстановить DNS».

Предотвращение — установить границы контроля до спорного изменения.
Организация должна инвентаризировать свои домены, регистраторов, реестры, авторитетных DNS-провайдеров, удостоверяющие центры, ответственный персонал и аварийные контакты. Ей следует определить ожидаемое состояние серверов имён, адресов, почтовой маршрутизации и DNSSEC; применить блокировки регистратора или реестра с надлежащим охватом; защитить клиентские и привилегированные учётные записи; отделить запрос от утверждения; защитить каналы восстановления. Директива CISA 2019 года сосредоточилась на аудите записей, смене учётных данных, MFA и мониторинге Certificate Transparency, тогда как предупреждение ICANN и более раннее руководство по безопасности дали более широкий контекст контроля регистрации.[1][3][7][8] Эти меры снижают риск, но не доказывают, что несанкционированное изменение невозможно.
Обнаружение — сравнить задуманное состояние с независимо наблюдаемым состоянием.
Мониторинг должен сочетать уведомления регистратора и реестра, проверки авторитетной зоны, независимые рекурсивные наблюдения и предупреждения Certificate Transparency. Каждому наблюдению нужны отметка времени, точка наблюдения, значение записи, TTL и результат проверки. Мониторинг из нескольких сетей помогает отличать локальную проблему резолвера, кэшированные данные и широко опубликованное авторитетное изменение. Обнаруженное различие следует рассматривать как аномалию, требующую проверки, а не как немедленное доказательство вредоносной активности или конкретного исполнителя.
Сдерживание — остановить дальнейшие изменения, сохраняя хронологию.
Как только изменение оспорено, соответствующие операторы должны ограничить дальнейшие модификации, сохранить активные сессии и журналы, где это безопасно возможно, отключить или сбросить скомпрометированные учётные данные и задействовать установленные пути эскалации регистратора, реестра, DNS-провайдера и удостоверяющего центра. Реагирование должно избегать неконтролируемых повторных правок, которые скрывают, какое действие произвело какое состояние. Журналы привилегированного доступа, заметки поддержки, идентификаторы EPP и копии уведомлений должны быть защищены до того, как обычные циклы хранения или сброс учётных записей сотрут полезный контекст.
Откат — восстановить последнее утверждённое состояние на каждом затронутом уровне.
Восстановление должно начинаться с проверенного базового состояния, а не просто с самого последнего значения на панели. Регистратор и реестр должны сверить статус домена, делегирование и историю транзакций; авторитетный оператор должен восстановить утверждённое содержимое зоны; восстановление DNSSEC должно сверить состояние подписывания потомка с состоянием DS родителя; удостоверяющие центры должны оценить неожиданную выдачу по своим процедурам. Время отката следует фиксировать относительно прежних TTL, после чего проводить авторитетные и рекурсивные проверки с нескольких точек. Исправленная зона ещё не доказывает полного восстановления, если остаются устаревшие ответы, неверные данные DS, неотозванные сертификаты или раскрытые учётные данные.
Коммуникация — сообщить каждой затронутой стороне, что известно, не опережая доказательства.
Уведомления об инциденте должны указывать затронутый сервис, наблюдаемый временной интервал, состояние, о котором известно, что оно изменилось, действие по сдерживанию, любое требование сброса учётных данных и следующую точку проверки. Регистрантам, провайдерам, полагающимся сторонам и публичным органам могут требоваться разные уровни детализации. Коммуникация должна отделять подтверждённые операционные факты от атрибутированных оценок. Она не должна подразумевать, что пострадал каждый клиент, что каждый отчёт 2019 года описывал одного исполнителя или что один отказ контроля объясняет весь вред. Координирующие органы могут запрашивать действия и агрегировать отчёты, но эти функции не переносят на них операционный контроль над каждым доменом.[2][3][6]
Долговечное доказательство — сохранить запись, переживающую сам ремонт.
Итоговый набор доказательств должен содержать снимки записей DNS до и после; клиентские и серверные идентификаторы транзакций EPP; историю статуса домена у регистратора и реестра; журналы привилегированного доступа; события регистрации, удаления и восстановления MFA; внеполосные утверждения; полную хронологию поддержки; историю делегирования, DNSSEC и DS; независимые наблюдения DNS с нескольких точек; предупреждения Certificate Transparency; записи проверки и выдачи удостоверяющего центра; журналы авторитетной зоны и доступа; уведомления об инциденте; записи сброса учётных данных; результаты проверки после ремонта. Каждый элемент должен нести источник, время сбора, информацию о целостности и хранителя. Если запись не существует или не была сохранена, это отсутствие следует констатировать, а не реконструировать как уверенность.

Вместе эти записи могут показать разницу между задуманным состоянием, принятым состоянием реестра, опубликованным авторитетным состоянием, кэшированными наблюдениями и выдачей сертификата. Они могут установить, когда отказ стал видимым, какой оператор имел полномочия на восстановление на каждом этапе и распространилось ли исправленное состояние как ожидалось. Они не могут автоматически раскрыть недоступные внутренние журналы, нераскрытое владение решениями, полный набор пострадавших организаций или долю вреда, вызванную каждым способствующим отказом контроля. Эти вопросы остаются ограниченными реально сохранёнными доказательствами.

Что доказывает DNSSEC — и чего он не доказывает

DNSSEC сужает важный вопрос, но не отвечает на весь вопрос ответственности. Валидирующий резолвер использует подписи, записи DNSKEY, записи DS и настроенную цепочку доверия, чтобы определить, согласуется ли набор записей с криптографической авторитетностью, представленной этой цепочкой. Успешная валидация поддерживает аутентификацию происхождения данных и целостность внутри этой конфигурации. Она не устанавливает, что руководители регистранта утвердили изменение, что регистратор следовал своей внутренней процедуре авторизации или что опубликованные записи отражают деловое намерение организации.[15][16]

Это различие прямо относится к алертам о вмешательстве 2019 года. Если несанкционированная сторона лишь подменяет неподписанные данные, пока легитимная цепочка DNSSEC остаётся целой, валидирующий резолвер должен отклонить несовпадение как ложное. Поэтому DNSSEC может сделать некоторые формы внеполосного изменения существенно труднее и заметнее. Но это отличается от злоумышленника, получившего контроль над авторизованным каналом выделения, системой управления зоной или инфраструктурой подписывания.

Скомпрометированный авторизованный канал может создавать криптографически согласованное, но организационно неверное состояние. Если злоумышленник может заставить легитимного подписанта подписать изменённые адресные, почтовые или серверные записи, получившиеся подписи могут пройти валидацию, потому что система подписывания аутентифицировала данные, которые ей было поручено опубликовать. Если злоумышленник может использовать авторизованный путь регистратора к реестру для замены делегирования и информации DS, родитель может опубликовать новую цепочку, ведущую к ключам, контролируемым через скомпрометированный процесс.

Валидатор может тогда видеть внутренне согласованные подписи, хотя изменение не утверждалось регистрантом.

Ещё один вариант — удаление записи DS через очевидно авторизованное изменение. В зависимости от кэширования, времени и политики резолвера это может перевести делегирование из валидированного состояния в незащищённое, а не создать прямо недействительную подпись. Переход может быть подозрительным, и мониторинг может его выявить, но один DNSSEC не решает, было ли удаление легитимной ротацией, аварийным ремонтом или несанкционированным понижением. Для любого из этих более узких отказов компрометация корня DNS не требуется.

Поэтому операционное руководство по DNSSEC рассматривает подписывание как постоянную дисциплину, а не одноразовый переключатель безопасности. Генерация, хранение, активация, вывод из эксплуатации и ротация ключей должны оставаться скоординированными с публикацией DNSKEY, состоянием DS на родительской стороне, сроками действия подписей и кэшированием резолверов. RFC 6781 рассматривает эти операционные обязанности, а более поздний RFC 9364 даёт дополнительный контекст DNSSEC, который нельзя проецировать назад как доказательство того, что организации реализовали во время инцидентов 2019 года.[17][21]

Форензическая уверенность зависит от сохранения перехода, а не только от наблюдения финального валидного ответа. Следователям понадобятся выровненные по времени доказательства старых и новых наборов DNSKEY, подач DS и родительской публикации, времени начала и истечения подписей, событий генерации зоны, активности системы подписывания, инструкций регистратора, транзакций реестра и авторитетных ответов, наблюдавшихся из независимых сетей. План ротации ключей может объяснить изменение; записи о том, что план был выполнен, могут его обосновать.

Без этих записей «плановая ротация» и «несанкционированное перевыделение» могут оставить похожие публичные следы после схождения кэшей.

То же доказательное требование относится к аварийному восстановлению. Восстановить вчерашний файл зоны недостаточно, если вчерашнее делегирование, состояние DS или ключи подписывания больше не авторитетны. Реагирующие должны знать, какой уровень изменился, когда изменился, какие учётные данные или системы его авторизовали и были ли состояния родителя и потомка восстановлены в безопасном порядке.

Руководство NIST по развёртыванию подчёркивает необходимость рассматривать безопасность DNS как операционную систему, включающую авторитетный сервис, резолверы, криптографический материал, мониторинг и восстановление, а не как одну протокольную функцию.[19]

Директива CISA отражала эту более широкую реальность, требуя от агентств провести аудит записей DNS, сбросить учётные данные, способные их менять, включить многофакторную аутентификацию там, где она доступна, и отслеживать данные Certificate Transparency.[1] Её сопроводительное руководство также рассматривало безопасность учётных записей, проверку записей и наблюдение как связанные средства контроля.[2] Эти меры не утверждали, что DNSSEC не важен. Они признавали, что аутентифицированные данные не могут компенсировать ненадёжный путь авторизации.

Вопрос сертификатов следует той же логике. Манипуляция DNS может направить пользователя на инфраструктуру, контролируемую исполнителем, пока знакомый домен остаётся в адресной строке. Если контроль над путём проверки домена также позволяет валидно выдать сертификат по правилам удостоверяющего центра, браузер может показать внешне обычное защищённое соединение. Это не значит, что сертификат был подделан. Это значит, что окружающее состояние контроля позволило выдать или использовать сертификат в контексте, который организация не намеревалась создавать.

Talos описала такое подлинно выглядящее перенаправление в отчётности о Sea Turtle, не утверждая компрометации серверов корневой зоны.[5][6]

Следовательно, DNSSEC — это свидетельство настроенной криптографической авторитетности, а не декларация организационной легитимности. Его самый сильный вклад в ответственность — сделать соответствующие вопросы более точными: какой ключ подписал обслуживаемый набор записей? Какая запись DS связывала этот ключ с родителем? Кто мог изменять эти объекты? Какая процедура ротации применялась? Что независимые резолверы наблюдали до, во время и после инцидента? Эти вопросы превращают «DNSSEC был включён» из лозунга в проверяемое описание контроля.

Статус EPP, выделение DNSSEC и значение блокировки

EPP предоставляет протокольный словарь, через который регистраторы и реестры управляют объектами доменов. RFC 5731 определяет команды домена, авторизационную информацию и значения статусов, которые могут запрещать или сигнализировать отдельные операции, включая обновления и передачи.[13] Эти термины важны, потому что «домен был заблокирован» иначе слишком расплывчато для вывода об ответственности.

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

Это различие объясняет, почему блокировка регистратора может быть ценной, но не решающей. Она может остановить рутинные изменения или передачи и создать дополнительное действие, которое должно произойти до модификации. Однако если привилегированные учётные данные регистратора, процесс поддержки или доступ EPP скомпрометированы, злоумышленник может действовать через тот же канал, которому разрешено изменять клиентский статус. Блокировка реестра может добавить разделение, требуя действия на стороне реестра, прежде чем указанные изменения продолжатся, особенно когда снятие зависит от независимого подтверждения.

Даже тогда её сила покоится на фактических процедурах аутентификации, эскалации и исключений, стоящих за значением статуса.

RFC 5910 расширяет EPP словарём для выделения информации DNSSEC.[14] Он позволяет обмену регистратора и реестра представлять данные безопасности, связанные с доменом, включая материал, используемый для поддержания отношений доверия родителя и потомка. Это делает выделение DNSSEC более структурированным и потенциально более аудируемым. Это не удостоверяет, что человеческий запрос был легитимным, что учётная запись регистратора не была скомпрометирована или что реестр независимо проверил намерение регистранта.

Соответствующий вопрос 2019 года, следовательно, не в том, существовал ли EPP. EPP был установленным интерфейсом, через который многие регистраторы и реестры обменивались состоянием домена. Вопрос в том, какие средства контроля окружали каждую значимую команду: кто её инициировал, как запросивший аутентифицировался, утвердил ли её другой человек, применил ли реестр серверное ограничение, какое уведомление было отправлено и какие неизменяемые записи сохранились. Соответствие протоколу может сосуществовать с отказом авторизации.

Более ранняя работа ICANN по безопасности уже описывала перехват доменов как проблему, включающую аутентификацию, регистрационные записи, практики регистраторов, блокировки, восстановление и аварийную поддержку.[7][8] Руководство для регистрантов также подчёркивало защиту учётных записей и практические защитные меры до периода алертов 2019 года.[9] Отдельное руководство по восстановлению делало акцент на документации, потому что восстановление перехваченного домена зависит от доказательства прежнего контроля и реконструкции правильной конфигурации.[10] Эти материалы устанавливают, что проблема контроля была известна.

Они не доказывают, что каждая пострадавшая организация эффективно использовала каждую защитную меру.

Авторизация передачи заслуживает столь же аккуратного рассмотрения. Передаточные учётные данные предназначены для авторизации перемещения между регистраторами; они не являются универсальным одобрением каждого обновления DNS. RFC 9154 позже усилил обработку авторизационной информации EPP, используемой при передачах.[18] Он полезен как свидетельство того, как стандартная работа развивалась после накопления слабостей и операционного опыта. Он не может установить, что его защита существовала у конкретного регистратора или реестра в окне отчётности с января по июль 2019 года.

Та же хронологическая граница относится к RFC 9364 и отчёту Инициативы ICANN по содействию безопасности DNS, выпущенному в 2021 году.[11][21] Они могут прояснить более позднее мышление об операциях DNSSEC, координации экосистемы и обязанностях безопасности. Их нельзя цитировать как современное доказательство того, что жертва 2019 года имела зрелую процедуру ротации, что регистратор требовал более строгой авторизации передачи или что реестр использовал конкретный рабочий процесс блокировки.

Рамочная модель ICANN для операторов реестров, отвечающих на угрозы безопасности, предлагает ещё одну форму контекста контроля.[12] Она показывает, как возможности уровня реестра могут быть важны во время события безопасности, но рамочная модель — не доказательство того, что конкретный реестр получил своевременный запрос, предпринял конкретное действие или мог предотвратить первоначальное изменение. Различие между доступными полномочиями и осуществлёнными полномочиями остаётся существенным.

Для инцидентов 2019 года доказательства EPP были бы особенно ценны, потому что они могли бы связать публичный переход DNS с подотчётным операционным событием. Запись транзакции могла бы идентифицировать спонсирующего регистратора, тип команды, объект домена, отметку времени и результат. Поддерживающие записи могли бы показать аутентифицированную учётную запись, исходную систему, утверждение, переход блокировки и уведомление.

Без этой цепочки публичные наблюдатели могут видеть, что делегирование изменилось, но не могут определить, дала ли действующую авторитетность учётная запись регистратора, внутренняя административная система, интерфейс реестра или другой уровень.

Коды статусов и расширения DNSSEC, таким образом, — несущий доказательства словарь, а не автоматические результаты безопасности. Они помогают следователям описать, что система приняла. Ответственность по-прежнему зависит от того, какая организация могла наложить, снять или обойти ограничение; какая организация сохранила соответствующие записи; и остался ли контроль независимым от учётных данных, наиболее вероятно подлежащих компрометации.

Пути учётных данных столь же неполны. Публичный отчёт может констатировать, что злоумышленники получили доступ, достаточный для изменения DNS, не раскрывая, был ли этот доступ получен через учётную запись регистранта, администрирование регистратора, скомпрометированный персонал поддержки, DNS-провайдера, учётные данные EPP или цепную компрометацию нескольких систем. Текущая таксономия доверия к доменам CISA может организовывать возможные пути приобретения, но не может заполнить пробелы в доказательствах конкретного инцидента.[20]

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

Состояние и сохранность журналов остаются неопределёнными. Сильные доказательства включали бы события аутентификации регистратора, записи поддержки, команды и ответы EPP, историю статусов реестра, активность управления зоной, записи подписанта DNSSEC, изменения DS, уведомления, наблюдения авторитетных запросов и события сертификатов. Если одна организация сохраняет только финальный снимок базы данных, а другая — историю только на добавление, их способность объяснять и отменять один и тот же отказ будет резко различаться.

Контроль до события также задокументирован неполно. Публичные рекомендации поддерживают актуальность многофакторной аутентификации, блокировок, гигиены учётных данных, аудита записей, независимого мониторинга и документации восстановления.[2][3][7][8][9][10] Они не показывают, у каких жертв были эти средства, как работали исключения и оставался ли привилегированный нечеловеческий доступ вне их. Отсутствие публичных доказательств не является доказательством отсутствия контроля; пост-инцидентное заявление о существовании контроля не является доказательством того, что он покрывал скомпрометированный путь.

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

Эффективность восстановления не устанавливается объявленным сбросом учётных данных или восстановленной веб-страницей. Следователям нужно подтвердить, что вредоносные записи исчезли, делегирование и состояние DS были правильными, несанкционированные сертификаты были урегулированы, пути доступа закрыты, кэши сошлись и мониторинг не обнаружил рецидива. Июльское описание Talos того, что Sea Turtle продолжала действовать, показывает, почему первоначальный алерт или изолированная очистка не могут считаться доказательством решения более широкой проблемы.[6]

Два отрицательных вывода должны оставаться явными. ICANN заявила, что у неё нет признаков компрометации её собственных систем.[3] Talos заявила, что у неё нет доказательств того, что серверы корневой зоны были атакованы или скомпрометированы.[5] Документированную проблему контроля можно объяснить через более узкий доступ к регистратору, реестру, DNS-оператору и организации, не утверждая компрометации ICANN или корня.

Сертификатные доказательства также должны оставаться ограниченными. Сертификат, выглядевший действительным во время перенаправления, не обязательно подделан. Он может отражать успешную выдачу после контроля над соответствующим путём проверки или использование легитимно выданного сертификата в несанкционированном контексте. Вопрос ответственности — какая сторона могла наблюдать подозрительную выдачу, оспорить её, отозвать или связать с изменением DNS, а не то, сфабриковала ли сама криптография организационное намерение.

Практическая проверка отказа контроля 2019 года

Доказательства 2019 года можно свести к четырём вопросам, специфичным для события.

Предотвратить:Могла ли сторона остановить несанкционированное изменение DNS до публикации? Соответствующие возможности включали строгую аутентификацию привилегированных учётных записей, разделение восстановления учётной записи и рутинного доступа, ограниченные учётные данные EPP, значимые ограничения обновлений, защиту на стороне реестра для изменений высокого риска и независимо подтверждаемые изменения делегирования или состояния DS. Доказательства должны указывать контроль, реально покрывавший путь, а не просто политику с той же меткой.
Обнаружить:Могла ли сторона наблюдать неверное состояние независимо от системы, которая его произвела? Полезные возможности включали сравнение с заведомо хорошими записями, наблюдение авторитетных ответов извне управляемой среды, предупреждения об изменениях серверов имён и DS, обнаружение аномалий аутентификации и EPP, а также мониторинг Certificate Transparency. Директива CISA сделала аудит записей и наблюдение за сертификатами конкретной частью реагирования.[1] Доказательства обнаружения должны показывать, когда появился сигнал, кто его получил и когда началось действие.
Ограничить:Могла ли сторона уменьшить охват или длительность вреда после провала предотвращения? Это зависит от сегментации учётных данных, ограничений на то, какие домены или записи учётная запись могла изменить, независимых средств реестра, быстрых процедур приостановки, сохранённой безопасной конфигурации и коммуникации между регистрантом, регистратором, реестром, DNS-оператором и удостоверяющим центром. Пределы следует оценивать по наблюдаемому эффекту: какие изменения были заблокированы, какие сервисы остались заслуживающими доверия и как долго обслуживалось вредоносное состояние.
Отменить:Могла ли сторона восстановить правильное делегирование, DNSSEC и состояние сервиса, не полагаясь на скомпрометированный канал? Восстановление требовало аутентифицированных аварийных контактов, доказательства прежнего контроля, истории транзакций, заведомо хороших данных зоны и делегирования, безопасной обработки ключей и записей DS, а также скоординированных действий через организационные границы. Руководство ICANN по восстановлению подчёркивает, почему документация центральна, когда обычным отношениям учётной записи больше нельзя доверять.[10]

Сторона может показывать разные результаты по этим четырём возможностям. Регистрант может иметь мало возможностей менять серверный статус реестра, но существенную ответственность за безопасность учётной записи и независимое наблюдение. Регистратор может не управлять авторитетными серверами имён, но контролировать аутентификацию клиентов, доступ EPP и эскалацию. Реестр может не знать деловое намерение регистранта, однако может обладать финальной записью транзакции и способностью накладывать или снимать серверные ограничения.

Авторитетный DNS-оператор контролирует, что отвечают его серверы, и может держать самые точные доказательства публикации зоны и отката. Удостоверяющий центр контролирует выдачу и отзыв в рамках своих правил, а полагающиеся стороны решают, как быстро реагировать на предупреждения о сертификатах и DNS. CISA и ICANN могли выпускать директивы, руководства и координационные предупреждения, но ни одна из них не управляла каждым пострадавшим доменом. Ответственность должна следовать этим различиям в практических полномочиях.

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

Итоговая мера — состояние, с которым реально столкнулись пользователи и резолверы. Корпоративное намерение важно при определении авторизации, но намерение не маршрутизирует пакеты, не отвечает на DNS-запросы и не устанавливает видимое резолвером делегирование. Знакомый домен, валидирующая цепочка DNSSEC или внешне действительный сертификат могут сосуществовать с состоянием, которого организация никогда не хотела, когда авторизованные системы повернуты к неверному результату.

Поэтому алерты 2019 года следует понимать как проверку подотчётности контроля изменений на нескольких операционных границах, а не как доказательство того, что корень DNS, ICANN или каждый реестр отказали. CISA, ICANN, Mandiant и Talos задокументировали разные части публичных материалов; Sea Turtle осталась отдельной от DNSpionage; более поздние стандарты описывают более сильный контекст контроля, а не ретроактивное развёртывание.[1][3][4][5][6][11][18][21]

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

Ответственность следует за стороной, которая могла авторизовать, записать, наблюдать или отменить состояние DNS, и доказательства реально обслуживаемого состояния важнее одних намерений.

Алерты 2019 года о вмешательстве в DNS сделали контроль изменений у регистраторов проверкой ответственности

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

Резюме

Граница доказательств намеренно узкая

Как знакомое имя может вести к несанкционированной инфраструктуре

Отдельные потоки отчётности в 2019 году

Январь: оперативная директива CISA

Январь: исследование инцидентов Mandiant

Февраль: предупреждение ICANN для экосистемы

Апрель: Talos выделяет Sea Turtle как отдельную кампанию

Июль: Talos возвращается к Sea Turtle

Сквозной путь управления DNS

Типы записей должны оставаться отдельными основаниями ответственности

Алерты 2019 года превратили каждую границу контроля в границу доказательств

Контроль регистранта после январских и февральских предупреждений

Контроль изменений у регистратора стал центральной проверкой ответственности

Записи реестра: операционные полномочия без суверенного владения

Доказательства авторитетного DNS и восстановление с учётом TTL

Сертификаты могли выглядеть действительными, не доказывая организационного согласия

Блокировка регистратора, блокировка реестра и пределы каналов восстановления

Реконструкция инцидента от предотвращения до долговечного доказательства

Что доказывает DNSSEC — и чего он не доказывает

Статус EPP, выделение DNSSEC и значение блокировки

Рекомендация, внедрение и внешне проверенный результат

Рекомендация

Внедрение

Внешне проверенный результат

Граница доказательств, которую публичные материалы не закрывают

Практическая проверка отказа контроля 2019 года

Источники

Подробный контекст профиля

Стратегическое сообщество

Альянс лидеров

Брифинг Стратегического сообщества

Обзор Альянса лидеров