Атака на корневые DNS-серверы 2002: проверка подотчётности

Резюме

21 октября 2002 года распределённая атака типа «отказ в обслуживании» существенно ухудшила важные маршруты к системе корневых серверов DNS. CAIDA зафиксировала резкие изменения времени приёма-передачи из указанных точек мониторинга, причём длительность варьировалась в зависимости от логического идентификатора корневого сервера. [1]
Позднее ICANN охарактеризовала девять из тринадцати логических адресов корневых серверов как «затопленные». Эта атрибутированная формулировка свидетельствует о масштабе атаки, но не доказывает, что девять полноценных сервисов исчезли по всему миру или что все резолверы и пользователи пострадали. [5]
CAIDA пришла к выводу, что заметное влияние на глобальную работу сети было незначительным. Рекурсивное кэширование, поведение повторных попыток и множественность логических идентификаторов корневых серверов помогли отделить серьёзную нагрузку на серверы и маршруты от повсеместных сбоев транзакций. [1][20][21]
Пакетный анализ CAIDA охватывал каналы корневых серверов E, I, K и M с десятиминутными интервалами, начавшимися вскоре после события. Эти наблюдения являются прямым доказательством для отслеживаемых каналов, а не переписью всех экземпляров корневых серверов, резолверов, маршрутов или приложений. [2][3]
RFC 2870 и RFC 3258 показывают, что производительность, разнообразие подключений, журналирование, сотрудничество и распределённое авторитативное обслуживание были признанными средствами контроля ещё до атаки. Они не доказывают, что каждый оператор внедрил все эти средства на момент атаки. [8][9]
Более поздние документы по эникасту, RSSAC, SSAC и руководства для крупных авторитативных серверов предлагают критерии исправления и измерения. Они служат материалом для последующего сравнения, а не ретроактивными юридическими обязательствами или доказательством точной топологии 2002 года. [6][10]-[16]
Ответственность распределялась между операторами корневых серверов, транзитными сетями и сетями доступа, операторами резолверов и координационными органами. Ни одна организация не контролировала все серверы, маршруты, кэши, фильтры или пользовательские транзакции.
Стандарт подотчётности является эксплуатационным: записи определяют полномочия, а достижимые маршруты, корректные ответы, непрерывность резолвинга, ограниченные меры по смягчению и многовекторные доказательства восстановления подтверждают непрерывность обслуживания.

Запись о полномочиях — не гарантия обслуживания

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

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

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

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

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

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

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

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

Что наблюдалось 21 октября 2002 года

Современный отчёт CAIDA об измерениях сообщил о резком ухудшении времени приёма-передачи примерно в 22:00 UTC. С точки наблюдения UCSD все отслеживаемые корневые серверы, кроме I и M, показали изменение производительности, но длительность не была одинаковой. CAIDA сообщила, что эффекты длились около часа для F, G и L, примерно от пяти до десяти минут для A и B и чуть более десяти минут для J.[1]

Эти наблюдения свидетельствуют о серьёзном событии. Они не дают универсальной карты обслуживания корневых серверов из каждой сети. Измерения опирались на мониторы в Сан-Диего и Сан-Хосе и, следовательно, описывали сервис, видимый через определённые маршруты из определённых мест. Корневой адрес, который плохо отвечал с одного монитора, мог быть в другом состоянии для резолвера, использующего другого вышестоящего провайдера, другой маршрут или географический путь. И наоборот, корень, который выглядел отзывчивым с точки измерения, мог быть трудно достижимым из другой сети.

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

CAIDA также пришла к выводу, что заметное влияние на глобальную работу сети было незначительным.[1] Этот вывод ограничивает любой пересказ атаки. Он исключает отношение к серьёзному трафику и изменениям производительности корневых серверов как к автоматическому доказательству повсеместного отказа пользователей. Он также требует объяснения: архитектура DNS содержит буферы между авторитативным корневым адресом и отдельной транзакцией, прежде всего рекурсивное кэширование и доступность нескольких идентификаторов корневого сервиса.

История оператора D-Root независимо определяет 21 октября 2002 года как дату массированной атаки и отмечает, что операторы впоследствии подготовили анализ события.[4] Эта запись подтверждает дату и эксплуатационное признание инцидента. Сама по себе она не устанавливает одинаковых условий на каждом корневом идентификаторе или каждом физическом экземпляре.

Более поздний пакетный анализ CAIDA даёт ещё один ограниченный взгляд. В нём рассматривался трафик, собранный с каналов, обслуживающих корневые серверы E, I, K и M, начиная вскоре после атаки, а наблюдения группировались по десятиминутным интервалам. Распределения запросов и наблюдаемых клиентов — это прямые измерения с этих каналов.[2] Более широкая работа CAIDA по корневому трафику объясняет набор данных и методологию, в рамках которых сидят эти наблюдения.[3]

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

Таким образом, три описания из конкретных источников могут сосуществовать без противоречий:

CAIDA наблюдала изменения производительности маршрутов, продолжительность которых различалась по корневым идентификаторам, с её точек мониторинга.[1]
Позднее CAIDA проанализировала пакеты и видимых клиентов на выбранных каналах E, I, K и M с десятиминутными интервалами.[2]
Сравнение ICANN 2007 года описывало девять из тринадцати логических адресов корневых серверов как затопленные во время атаки 2002 года.[5]

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

Почему «девять из тринадцати» — лишь начало исследования

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

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

Формулировку ICANN следует сохранить в её атрибутированном виде: девять из тринадцати логических адресов корневых серверов были описаны как затопленные.[5] «Затопленные» означает, что атака перегрузила важные сервисные маршруты или пропускную способность. Это не определяет универсальной границы отказа. Это не говорит, что все авторитативные мощности, связанные с каждым адресом, отказали повсюду. Это не раскрывает решения каждого резолвера о повторной попытке или состояние его кэша. Это не подсчитывает завершённые транзакции.

Подсчёт серверных адресов упускает по крайней мере четыре измерения.

Во-первых, он упускает точку наблюдения. Достижимость относительна: резолвер достигает адреса через конкретный маршрут из конкретной сети. Отказ ответа, наблюдаемый в Калифорнии, свидетельствует о этом маршруте и времени, но не является прямым наблюдением из Европы, Африки, Азии или другой североамериканской сети.

Во-вторых, он упускает время. Зафиксированные CAIDA изменения производительности длились не одинаково долго.[1] Подсчёт без временного интервала может объединить краткое ухудшение на одном адресе с более длительным состоянием на другом и сделать их операционно идентичными.

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

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

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

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

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

Кэширование резолверов отделяет нагрузку на инфраструктуру от ущерба пользователям

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

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

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

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

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

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

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

Ограниченный вывод, о котором сообщила CAIDA — что заметное влияние на глобальную работу сети было незначительным, — соответствует этой многослойной модели.[1] Его не следует обобщать до утверждения, что никто из пользователей не пострадал, поскольку точные показатели отказов на уровне пользователей недоступны. Не следует и отбрасывать его в пользу драматичного подсчёта адресов. Это свидетельство того, что более широкая система, включая кэши и оставшуюся авторитативную достижимость, продолжала предоставлять значительный сервис, несмотря на сильное давление.

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

Распределённая эксплуатация меняет принадлежность устойчивости

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

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

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

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

Ни одна роль не может заменить все остальные.

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

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

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

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

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

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

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

Пропускная способность и разнообразие были признанными мерами контроля ещё до атаки

Событие 2002 года не произошло в концептуальном вакууме. RFC 2870, опубликованный до атаки, излагал эксплуатационные требования к корневым серверам имён. Он касался обслуживания, соответствующего стандартам, пропускной способности выше измеренного пикового спроса, разнообразия подключений, исключительно авторитативного режима работы, журналирования и сотрудничества при анализе безопасности.[8]

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

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

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

RFC 3258, опубликованный в апреле 2002 года, описывал использование разделяемых юникаст-адресов для распределения авторитативного сервиса имён.[9] Такая схема позволяет анонсировать сервисный адрес из нескольких точек, а маршрутизация определяет, какая точка получит запрос. Она также создаёт свои эксплуатационные границы: важно размещение, важно поведение маршрутизации, а авторитативные данные должны оставаться согласованными во всём распределённом сервисе.

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

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

Таким образом, атака проверяет цепочку, а не отдельное средство контроля:

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

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

Разделяемый юникаст и опасность переписывания топологии на день атаки

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

RFC 4786 позже определил эксплуатационную модель эникаста, при которой один и тот же сервисный адрес анонсируется из нескольких дискретных точек.[10] RFC 7094 развил дальнейшие архитектурные соображения для распределения эникаста, включая взаимосвязь между топологией, маршрутизацией и поведением сервиса.[11] RFC 7720 позже описал требования к протоколу и развёртыванию для сервиса корневых имён.[12]

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

Они не являются лицензией на проецирование более позднего развёртывания назад. Доказательства не подтверждают ни утверждения о повсеместном корневом эникасте на 21 октября 2002 года, ни полной карты распределения по идентификаторам на день атаки. Публикация RFC 3258 до события устанавливает, что распределение на основе разделяемого юникаста было задокументированным методом.[9] Она не устанавливает всеобщего внедрения.

Фактологический бюллетень ICANN 2007 года сравнил более позднюю корневую атаку с событием 2002 года и приписал меньшее влияние на пользователей в более поздней атаке отчасти внедрению эникаста и улучшению координации операторов, достигнутому после 2002 года.[5] Это сравнение поддерживает вывод, что распределение и координация стали более значимыми средствами обеспечения устойчивости. Оно не превращает более поздние меры в ретроактивные обязанности и не доказывает, что какое-то одно исправление объясняет все различия между событиями.

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

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

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

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

Измерение должно указывать свои часы, слой и точку наблюдения

Доказательства 2002 года демонстрируют, почему подотчётность инфраструктуры требует дисциплинированного языка измерений. Утверждение о «корне» может относиться по крайней мере к пяти различным объектам:

Слой измерения	Что он может установить	Что он не может установить сам по себе
Нагрузка на канал и пакеты	Объём трафика и видимые клиенты на отслеживаемом канале в течение заданного интервала	Условия на каждом корневом канале или успешность пользовательских транзакций
Производительность маршрута	Достижимость или ухудшение ответа от указанного монитора к логическому адресу	Достижимость от каждого резолвера или региона
Авторитативный сервис	Возвращал ли наблюдаемый экземпляр своевременные, корректные DNS-ответы	Состояние кэша и поведение нижестоящих резолверов
Рекурсивный резолвер	Продолжалось ли разрешение через кэши, повторные попытки и доступные корни	Условия, испытываемые каждым приложением или пользователем
Завершённая транзакция	Успешно ли выполнилась конкретная пользовательская операция из заданной сети	Глобальное состояние каждого базового компонента DNS

Отчёт CAIDA о событии находится в основном в слое производительности маршрута. Он сообщил об изменениях времени приёма-передачи около 22:00 UTC и различной кажущейся длительности среди отслеживаемых корневых серверов.[1] Эти измерения являются веским доказательством, будучи выражены как наблюдения с указанных площадок. Они становятся слабее, если превращаются в утверждения о глобальной доступности.

Более поздний анализ E, I, K и M находится на слое канала и пакетов. Его десятиминутные группировки предоставляют часы, а отслеживаемые каналы — масштаб.[2] Контекст набора данных объясняет, как были собраны такие наблюдения корневого трафика.[3] Анализ может охарактеризовать, что видели эти каналы. Он не может установить каждое физическое происхождение, каждый маршрут или каждый результат резолвера.

Отчёт ICANN «девять из тринадцати» является сводкой по логическим адресам.[5] Он отражает широту давления на указанные сервисы, но не заменяет доказательств о маршрутах, экземплярах, резолверах или транзакциях.

Поэтому достоверная реконструкция инцидента должна прикреплять четыре квалификатора к каждому основному утверждению:

Объект:Относилось ли наблюдение к логическому адресу, физическому или топологическому экземпляру, каналу, маршруту, резолверу или транзакции?
Точка наблюдения:Из какой сети или с какой позиции мониторинга оно велось?
Метрика:Было ли доказательство объёмом трафика, временем приёма-передачи, долей ответов, корректностью, поведением тайм-аутов или завершённым разрешением?
Интервал:Когда началось состояние, как измерялась длительность и когда было подтверждено восстановление?

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

Более поздние публикации RSSAC предлагают критерии сравнения для придания большей согласованности ожиданиям от корневого сервиса и измерениям. Работа RSSAC по сервисным ожиданиям описывает систему корневых серверов с точки зрения предоставляемого сервиса, а её общая структура измерений стремится к сопоставимым данным у разных операторов.[13], [14] RFC 9199 аналогичным образом предоставляет более поздние эксплуатационные соображения для крупных систем авторитативных DNS-серверов.[16]

Эти более поздние документы не должны представляться как обязательства, регулировавшие каждого оператора в 2002 году. Их ценность — ретроспективная и ориентированная на будущее: они показывают, как можно структурировать доказательства, чтобы будущее событие было легче объявить, сравнить и закрыть.

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

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

Практический контроль определяет практическую подотчётность

Распределённый сервис нуждается в модели ответственности, которая следует за реальным контролем. Эту модель можно сформулировать без утверждений о вине.

Субъект	Основные средства контроля	Ожидаемые доказательства
Операторы корневых серверов	Размещение экземпляров, авторитативная ёмкость, разнообразие вышестоящих провайдеров, локальная фильтрация, мониторинг и реагирование на инциденты	Состояние каждого экземпляра и канала, поведение ответов, контекст маршрута, сроки смягчения и доказательства восстановления
Транзитные и пиринговые сети	Пропускная способность маршрутов, распространение маршрутов, управление перегрузками и фильтрация в пределах сетевого домена	Изменения маршрутов и трафика, затронутые маршруты, действия по фильтрации и достижимость из соответствующих сетей
Сети доступа	Контроль на границе клиентов и правдоподобие исходных адресов в пределах их доменов	Масштаб внедрения, исключения, результаты проверки и наблюдения, связанные с атакой, где доступны
Операторы рекурсивных резолверов	Поведение кэша, повторные попытки, корневые подсказки и мониторинг разрешения, ориентированный на пользователя	Успех, зависящий от кэша, шаблоны тайм-аутов и повторных попыток, результаты выбора корневого сервера и восстановление резолвера
Координационные и консультативные органы	Общие ожидания, обмен информацией, форматы доказательств и анализ после инцидентов	Своевременные уведомления, общая терминология, сопоставимые измерения, зафиксированные решения и ограниченные выводы
Конечные пользователи	Запросы приложений и локальные наблюдения	Симптомы транзакций без ожидания, что пользователи реконструируют скрытое состояние инфраструктуры

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

Транзитные и пиринговые сети контролируют, может ли трафик достигать авторитативных мощностей по конкретным маршрутам. Они могут влиять на перегрузку, доступность маршрутов и перемещение спроса между площадками. Представленные доказательства не реконструируют каждое решение о маршруте или пиринге во время атаки 2002 года, поэтому не следует делать выводов о каком-либо конкретном вмешательстве в маршрут.

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

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

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

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

Консультативный документ SSAC о риске DDoS и скоординированных мерах контроля DNS, наряду с институциональной записью, реагирующей на эту работу, иллюстрируют более позднее развитие этого координационного слоя.[6], [7] Рамочная программа снижения угроз для операторов корневых серверов аналогичным образом отражает распределённую модель, в которой устойчивость возникает из средств контроля операторов и сотрудничества, а не из единого командного пункта.[15]

Владение средствами контроля должно оцениваться через три вопроса.

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

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

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

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

Входная фильтрация — это обязанность вышестоящей сети, а не универсальное лекарство

Фильтрация исходных адресов заслуживает места в анализе, потому что трафик типа «отказ в обслуживании» может использовать слабые места далеко от атакуемого сервиса. RFC 2827 описывает входную фильтрацию, призванную сократить трафик с поддельными исходными адресами.[17] RFC 3704 развивает соображения по фильтрации, включая осложнения, создаваемые многосетевыми сетями и асимметричной маршрутизацией.[18] RFC 4732 рассматривает отказ в обслуживании как общеинтернетную инженерную проблему, требующую внимания во многих частях сети.[19]

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

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

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

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

Поэтому уместны следующие ограниченные вопросы:

Внедрила ли сеть средства проверки достоверности исходных адресов в пределах того домена, которым она реально могла управлять?
Были ли поняты и протестированы исключения для многосетевого подключения и асимметричных маршрутов?
Собрали ли операторы доказательства, показывающие, что средства контроля принимали или отклоняли?
Можно ли было коррелировать изменения фильтрации с улучшением легитимного обслуживания?
Не привело ли смягчение к перемещению вредоносного трафика в другое место или к новым отказам достижимости?

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

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

Координация — это эксплуатационный контроль, а не претензия на центральное командование

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

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

Записи 2002 года показывают, почему важны общие доказательства. CAIDA описала производительность маршрутов с указанных мониторов.[1] Её более поздний анализ описал пакеты на выбранных корневых каналах.[2] ICANN суммировала логические адреса.[5] D-Root зафиксировал событие в истории операторов.[4] Каждый отчёт полезен, но их разные объекты должны согласовываться осторожно.

Более поздние публикации SSAC, RSSAC и операторов можно рассматривать как ответы на эту проблему доказательств. Они подчёркивают скоординированные средства контроля, сервисные ожидания, общие измерения и снижение угроз.[6], [13]-[15] Их актуальность заключается в повышении будущей наблюдаемости и реагирования. Их не следует использовать для заявления, что все эти механизмы были обязательными или внедрёнными в октябре 2002 года.

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

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

Измеримый тест устойчивости и восстановления

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

Обоснованный тест подотчётности можно организовать в семь связанных этапов.

1. Целостность полномочий

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

Целостность полномочий необходима, но недостаточна. Прохождение этого этапа доказывает, что система указывает на предполагаемые сервисы. Это не доказывает, что эти сервисы достижимы.

2. Достижимость из различных сетей

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

Наблюдения CAIDA демонстрируют, почему эта дисциплина важна. Зафиксированные изменения времени приёма-передачи были реальными измерениями с конкретных мониторов.[1] Современная оценка устойчивости должна расширить количество и разнообразие таких перспектив, но она всё равно должна сопротивляться утверждениям о большей географии, чем покрывают мониторы.

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

3. Пригодный к использованию авторитативный сервис

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

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

RFC 2870 предоставляет контекст до события в отношении пропускной способности, разнообразия подключений, журналирования и сотрудничества.[8] RFC 3258 предлагает раннюю распределённую сервисную модель и её проблемы с маршрутизацией и согласованностью.[9] Более поздние документы по эникасту и корневому сервису уточняют сравнение.[10]-[12] Ни один из них не заменяет телеметрии, специфичной для атаки.

4. Непрерывность резолверов

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

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

RFC 1034 и RFC 1035 предоставляют основу для поведения резолверов и кэширования, создающих эту границу.[20], [21] Точное состояние кэша глобальной популяции резолверов во время события 2002 года остаётся неизвестным, поэтому его нельзя реконструировать только по серверным данным.

5. Завершение легитимных транзакций

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

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

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

6. Средства контроля источника трафика и маршрутов

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

RFC 2827 и RFC 3704 определяют принципы входной фильтрации и их эксплуатационные ограничения.[17], [18] RFC 4732 помещает смягчение отказа в обслуживании в распределённый инженерный контекст.[19] Доказательства на этом этапе не должны предполагать, что весь атакующий трафик использовал поддельные источники. Они должны показывать, какие средства контроля были доступны, где они применялись и сохраняли ли изменения легитимный трафик.

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

7. Скоординированное объявление и восстановление

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

Более поздняя работа RSSAC по измерениям предлагает основу для сопоставимых доказательств корневой системы, а руководства по снижению угроз для операторов и для крупных авторитативных серверов предоставляют дополнительные точки сравнения.[13]-[16] Эти более поздние материалы должны направлять текущие ожидания, не будучи ложно представлены как ретроактивные обязательства на день атаки.

Восстановление должно требовать согласия нескольких индикаторов:

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

Ни один индикатор не может доказать всю цепочку. Вместе они могут поддержать ограниченное, воспроизводимое объявление.

Эта структура делает исправление измеримым. «Добавить эникаст», «увеличить пропускную способность» или «улучшить координацию» — неполные обещания. Исправление должно указывать, какую границу отказа оно адресует и какие доказательства покажут, что оно сработало. Дополнительные экземпляры должны улучшить достижимость или изоляцию отказов. Бо́льшая пропускная способность должна увеличить используемый запас на заданных маршрутах. Фильтрация должна сократить вредоносный трафик, не исключая легитимных источников. Координация должна сократить время обнаружения, согласовать масштаб и произвести сопоставимые доказательства восстановления.

Атака выявила проблему непрерывности, а не суверенитета

Событие 2002 года можно неверно истолковать как спор о том, какая организация контролирует корень. Такая постановка упускает границу эксплуатационного отказа.

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

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

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

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

Тот же подход ограничивает претензии на предотвращение. Никакие представленные доказательства не показывают, что один оператор или организация могли предотвратить атаку в одиночку. Бо́льшая мощность на одном корневом сервере не контролировала бы трафик на других. Фильтрация в одной сети доступа не ограничила бы все источники. Кэширование на резолверах не сохраняло бы данные бесконечно. Сама по себе координация не создала бы пропускную способность. Устойчивость возникла из совокупного эффекта множества средств контроля.

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

Что публичные доказательства не могут установить

Несколько важных фактов остаются неизвестными из представленной документации.

Личность и мотив атакующего не установлены. Полная совокупность вовлечённых систем или источников неизвестна. Доказательства не позволяют приписать атаку какому-либо названному лицу, организации или классу субъектов.

Точные скорости пакетов на каждом корневом идентификаторе и физическом экземпляре недоступны. Пакетная работа CAIDA охватывала каналы E, I, K и M, начавшись вскоре после атаки, и организовывала наблюдения по десятиминутным интервалам.[2] Эти данные не следует распространять на неотслеживаемые каналы.

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

Полная физическая топология, активная на 21 октября 2002 года, не перечислена. Более позднее расширение эникаста не может заполнить этот пробел. Было бы неточно описывать более позднюю модель распределения как повсеместно присутствовавшую во время атаки.

Состояния кэшей резолверов и точные показатели отказов, видимых пользователям, недоступны. Вывод CAIDA о незначительном влиянии является важным ограничением, но не переписью каждого резолвера или пользователя.[1] Некоторые транзакции могли не пройти; документация не даёт их универсальной количественной оценки.

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

Эффективность каждого постинцидентного исправления также нельзя предполагать. Более позднее сравнение ICANN связывало снижение влияния на пользователей в атаке 2007 года отчасти с внедрением эникаста и координацией операторов после 2002 года.[5] Это поддерживает ограниченное сравнение, а не универсальное утверждение, что каждое более позднее средство контроля работало одинаково хорошо при любых условиях.

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

Главный урок подотчётности

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

CAIDA наблюдала резкое ухудшение производительности около 22:00 UTC и сообщила о различной длительности для разных корневых идентификаторов со своих точек наблюдения.[1] Её более поздний пакетный анализ задокументировал трафик на выбранных каналах E, I, K и M.[2] История D-Root подтвердила эксплуатационную значимость события.[4] ICANN позже резюмировала масштаб атаки, описав девять из тринадцати логических адресов корневых серверов как затопленные.[5] Тем не менее, CAIDA пришла к выводу, что видимое глобальное эксплуатационное влияние было незначительным.[1]

Эти факты согласуются, когда систему рассматривают как цепочку. Логические адреса идентифицируют сервисы; они не идентичны полным физическим развёртываниям. Маршруты определяют, какую мощность может достичь резолвер. Распределённые авторитативные экземпляры создают альтернативы, но зависят от топологии и согласованности. Рекурсивное кэширование снижает непосредственную зависимость от живых корневых запросов. Транзитные сети и сети доступа контролируют части пути трафика и границу достоверности источника. Измерения определяют, являются ли выводы локальными, региональными или общесистемными.

Координация связывает автономных операторов во время смягчения и восстановления.

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

Более поздние работы по эникасту, измерениям RSSAC и снижению угроз можно оценивать как ответы на эту проверку.[10]-[16] Их не следует превращать в мифологию дня атаки или ретроактивные юридические обязанности. Их ценность в том, что они делают контроль и доказательства более явными.

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

Атака на корневые DNS-серверы 2002 года сделала устойчивость распределённого сервиса проверкой подотчётности

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