Дефект кэша DNS Azure 2021 г.: лавина повторов как тест на подотч

Краткое изложение

С 21:21 UTC по 22:00 UTC 1 апреля 2021 года сервис Azure DNS испытывал проблемы с доступностью. Microsoft заявила, что большинство зависимых служб восстановилось к 22:30 UTC. В синхронном уведомлении для сообщества был указан приблизительный период воздействия с 21:30 до 22:30, тогда как независимый мониторинг зафиксировал тревогу около 21:20. Это разные точки наблюдения, не обязательно противоречащие друг другу. [1][2]
Microsoft описала аномальный всплеск DNS-запросов со всего мира, нацеленных на набор доменов, размещённых в Azure. Публично не был назван злоумышленник, намерения, ботнет или подтверждённая распределённая атака типа «отказ в обслуживании». Первопричина всплеска должна оставаться необъяснимой за пределами описания Microsoft. [2][4][5]
Microsoft заявила, что определённая последовательность событий выявила дефект кода, снизивший эффективность кэшей Edge DNS Azure. В публичных материалах не раскрыты кодовый путь, ключ кэша, коэффициент попаданий, затронутая популяция граничных узлов или объём серверной работы, созданный каждым промахом. [2][4][5]
По мере перегрузки службы DNS клиенты учащали повторные запросы. Microsoft сообщила, что система подавления объёмных всплесков считала эти повторы легитимными и потому не отбрасывала их. Это свидетельствует о петле обратной связи с усилением повторов, но не даёт точной покадровой реконструкции. [2][4]
Microsoft заявила, что мониторинг обнаружил снижение доступности, к работе подключились инженеры, и служба DNS автоматически восстановилась к 22:00 UTC. Было признано, что время восстановления превысило целевой проектный показатель. Затем были изменена логика подавления для защиты от чрезмерных повторов и перечислены в качестве следующих шагов исправление дефекта кэша и улучшение обнаружения аномального трафика. [2][4][5]
Инцидент затронул плоскость управления сетью, а не одно приложение. Пользователи испытывали перебои с разрешением имён, используемых Azure, Dynamics, Xbox Live и другими сервисами Microsoft. Корректная сервисная запись не помогала, когда работающий авторитативный путь не возвращал надёжных ответов. [1][3][6]
Текущая документация Azure описывает глобальную anycast-сеть DNS, функции надёжности и элементы управления для клиентов. Эти материалы объясняют архитектуру и распределение ответственности, но не могут служить доказательством точной реализации 2021 года или завершения работ по устранению. [7]-[13]
Стандарты DNS разделяют авторитативное обслуживание и рекурсивное разрешение и документируют, как кэширование, отсутствие ответа и повторы формируют нагрузку. Особенно уместен RFC 4697, поскольку поведение повторов резолверов может создавать избыточную работу для авторитативных серверов. Стандарты не показывают, какие клиенты или резолверы внесли какую долю во время данного инцидента. [14]-[22]
Ответственность следует за контролем. Инженеры Azure DNS контролировали код кэша, ёмкость граничных узлов, формирование трафика, классификацию средств подавления и автоматику восстановления. Команды сервисов Microsoft контролировали общие зависимости DNS. Операторы резолверов и клиентов контролировали поведение повторов и кэша. Клиенты контролировали некоторые решения по мониторингу и делегированию, но не могли проверить или исправить внутренний дефект Azure.
Для достоверного ремонта необходимы привязанные ко времени доказательства: коэффициенты попадания в кэш по классам запросов, частота повторов, насыщение граничных узлов, изменения зон обслуживания anycast, поведение правил подавления, проверки заведомо валидного разрешения, повосстановление служб и тесты на повторяемость. Ничто из этого не следует выводить из одной лишь статусной метки.

Хронология содержит несколько часовых отметок

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

Позднейшее описание инцидента от Microsoft помещает проблему доступности Azure DNS в промежуток с 21:21 UTC до 22:00 UTC 1 апреля 2021 года и указывает, что большинство служб восстановилось к 22:30 UTC. Exoprise воспроизвела эти данные и сообщила, что её собственный мониторинг DNS и серверов поднял тревогу около 21:20. [2] Современное уведомление сотрудника Microsoft на странице сообщества, опубликованное ещё в процессе реагирования, описывало воздействие на клиентов примерно с 21:30 UTC до 22:30 UTC.

Более позднее обновление сотрудника на той же странице говорило о всплеске трафика на DNS-серверах Microsoft и задействовании отказоустойчивых возможностей DNS. [1]

Эти метки времени измеряют разное:

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

Современный репортаж The Register процитировал приблизительное начало в 21:30 UTC и сообщил, что Microsoft перенаправила трафик на отказоустойчивые возможности DNS на время расследования. Были описаны последствия в основных географических регионах, причём из зоны воздействия исключались правительственное облако Microsoft и сервисы в Китае. [3] TechCrunch отдельно сообщил о сбоях, затронувших множество продуктов Microsoft, и процитировал признание Microsoft проблемы с порталом Azure и сервисами Azure. [6]

Публичные данные не устанавливают единого момента восстановления для каждого имени, резолвера, региона или сервиса. DNS-кэши могут делать момент сбоя и восстановления неодновременными. Резолвер с тёплым ответом может продолжать обслуживать имя после падения авторитативной доступности. Резолвер с холодным кэшем откажет немедленно. Когда авторитативный сервис улучшается, негативное или сбойное состояние на клиентах и промежуточных резолверах всё ещё способно задерживать видимое восстановление. Microsoft сама разграничила автоматическое восстановление DNS в 22:00 и восстановление большинства сервисов в 22:30. [2]

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

Аномальный всплеск — не доказанная атака

Microsoft заявила, что Azure DNS получил аномальный всплеск запросов со всего мира, нацеленных на набор доменов, размещённых в Azure. [2][4] Это описание объёма и распределения целей. Само по себе оно не устанавливает, кто генерировал трафик, был ли умысел злонамеренным, подделывались ли адреса источников и подпадает ли событие под ту или иную классификацию отказа в обслуживании.

В некоторых публикациях использовался язык атаки. Цитируемая здесь техническая документация не содержит образцов пакетов, отчёта об атрибуции или заявления Microsoft с указанием конкретной DDoS-кампании. Поэтому будущий доказательный стандарт узок:

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

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

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

Дефект кэша изменил стоимость каждого запроса

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

Microsoft заявила, что эффективность её граничного кэша DNS снизилась из-за дефекта кода, проявившегося при одной конкретной последовательности событий. [2][4][5] Эта фраза информативна, но неполна. Она не говорит, пропускали ли затронутые запросы кэш ответов, обходили ли негативный кэш, вызывали ли повторные обращения к серверной части, конкурировали ли за разделяемое состояние, инвалидировали ли записи или потребляли иной дефицитный ресурс. Она не указывает, были ли уязвимы все граничные узлы или только подмножество, достигнутое по определённым anycast-путям.

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

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

Это основная петля обратной связи, поддерживаемая изложением Microsoft:

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

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

RFC 1034 и RFC 1035 устанавливают кэширование как фундаментальную часть работы DNS. [17][18] RFC 2308 определяет негативное кэширование, чтобы резолверы не повторяли бесконечно один и тот же запрос о несуществовании. [19] Более поздние стандарты, такие как RFC 8020 и RFC 8198, описывают способы сокращения ненужного негативного трафика запросов в определённых условиях. [21][22] Ни один из этих документов не доказывает, что дефект Azure касался негативных ответов. Они лишь показывают, что повторное использование запросов, состояние кэша и повторяющиеся промахи — признанные эксплуатационные переменные.

Легитимные повторы всё равно могут быть небезопасны в совокупности

Наиболее значительное признание Microsoft состояло в том, что клиентские повторы считались легитимным DNS-трафиком и потому не отбрасывались системами подавления объёмных всплесков. [2][4]

«Легитимный» может означать несколько вещей. Пакет может иметь правдоподобный источник. Запрос может соответствовать протоколу. Клиент может быть авторизован использовать рекурсивный резолвер. Запрошенный домен может существовать. Ничто не гарантирует, что неограниченный совокупный поток повторов безопасен для ослабленного авторитативного сервиса.

RFC 4697 документирует поведение резолверов, способное создавать чрезмерную нагрузку запросов на авторитативные серверы. Он описывает шаблоны, в которых резолверы повторяют запросы слишком агрессивно, опрашивают несколько серверов или продолжают работу, когда более дисциплинированный ответ снизил бы нагрузку. [20] Документ появился за много лет до инцидента с Azure. Его уместность не в том, что Azure обязательно нарушила какой-то предписанный алгоритм. Он устанавливает, что усиление повторов на границе «резолвер—авторитативный сервер» — это известный класс эксплуатационных сбоев.

Хроника Azure оставляет несколько вопросов без ответа:

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

Без этих измерений «чрезмерные повторы» — полезная категория, но не полный диагноз.

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

Microsoft заявила, что немедленно после инцидента обновила логику объёмного подавления, чтобы защитить сервис DNS от чрезмерных повторов. [2][4] Проверяемый отчёт показал бы, какой сигнал изменился, как новое правило отличает безвредный повтор от вредного совокупного поведения, какие тесты на ложные срабатывания были проведены и как операторы могут отключить или настроить контроль, если он блокирует легитимные имена.

Авторитативное обслуживание и рекурсивное разрешение — разные области контроля

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

Корневой резолвер на устройстве обычно спрашивает рекурсивный резолвер. Рекурсивный резолвер может ответить из кэша. Если у него нет пригодного ответа, он следует по цепочке делегирования и запрашивает авторитативные серверы для соответствующей зоны. RFC 1034 и RFC 1035 определяют эти роли и обмен сообщениями между ними. [17][18]

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

Поэтому один и тот же симптом может иметь разные причины:

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

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

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

Anycast распределяет запросы, но не делает каждый узел равноценным

Текущая документация Microsoft утверждает, что Azure DNS использует глобальную сеть серверов имён и anycast для направления каждого запроса на ближайший доступный DNS-сервер. [7] Руководство Microsoft по anycast в Windows Server объясняет общий шаблон: несколько площадок анонсируют один и тот же сервисный адрес, а маршрутизация выбирает путь. [9]

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

RFC 9199 объясняет, почему крупные авторитативные сервисы обычно используют несколько серверов, anycast и балансировку нагрузки. Он также предостерегает от предположения о единой универсальной модели развёртывания. Размещение резолверов, маршрутизация, пиринг и форма зоны обслуживания влияют на то, какой экземпляр получает трафик. [14]

Во время всплеска запросов anycast может распределять нагрузку, но он также способен создавать неравномерный опыт:

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

Публичный RCA-отчёт Microsoft не раскрывает, затронул ли дефект кэша каждый узел, менялись ли маршруты, означали ли «отказоустойчивые возможности DNS» перемещение зон обслуживания или имели ли одни серверы лучшую эффективность кэша, чем другие. [1][2]

Фраза «перенаправили трафик на наши отказоустойчивые возможности DNS» появилась в современной статусной отчётности. [3] Она слишком широка, чтобы установить, что изменилось. Достоверный технический отчёт связал бы эту фразу с доказательствами:

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

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

Предоставление устаревших данных — опция, а не предполагаемое лекарство

Когда авторитативные серверы не могут ответить, рекурсивный резолвер может иметь просроченную копию ранее валидного ответа. RFC 8767 определяет ограниченный метод предоставления устаревших данных для повышения устойчивости в оговорённых условиях. [15]

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

Предоставление устаревших данных связано с компромиссами:

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

Негативное кэширование имеет аналогичные границы. RFC 2308 снижает число повторяющихся запросов для известных негативных ответов. RFC 8020 разрешает резолверу останавливаться ниже валидированной ветви NXDOMAIN. RFC 8198 позволяет агрессивно использовать DNSSEC-аутентифицированные записи об отказе для синтеза дополнительных негативных ответов. [19][21][22]

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

Вопрос, основанный на доказательствах, не «Почему каждый резолвер не смог выдать устаревшее?», а:

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

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

Концентрация зависимостей заставила один сбой DNS выглядеть как множество отказов сервисов

Инцидент был виден через Azure, Dynamics, Xbox Live и другие сервисы Microsoft, потому что разрешение имён лежало в основе нескольких сервисных путей. Вопросы-ответы Microsoft назвали Azure, Dynamics и Xbox Live. [1] Exoprise воспроизвела сообщение Microsoft 365, где перечислялись Teams и более широкий набор затронутых продуктов. [2] The Register и TechCrunch независимо описали массовые жалобы на доступ к различным ресурсам Microsoft. [3][6]

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

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

Общая зависимость порождает несколько вопросов подотчётности:

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

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

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

Мониторинг обнаружил деградацию, но обнаружение — не сдерживание

Microsoft заявила, что снижение доступности сервиса запустило системы мониторинга и привлекло инженеров. [2] Exoprise сообщила, что её внешний монитор поднял тревогу около 21:20, незадолго до более позднего начала окна DNS, указанного провайдером (21:21). [2]

Такое совпадение по времени говорит о том, что проблема была не только в обнаружении. Сервис автоматически восстановился к 22:00, но Microsoft признала, что длительность превысила его проектный показатель. Тогда уместный вопрос — что операторы могли сделать после обнаружения.

Полезная система обнаружения должна разделять как минимум следующие сигналы:

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

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

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

Это различие в управлении:

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

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

Восстановление превысило проектный показатель

Заявление Microsoft о том, что восстановление превысило проектный показатель, необычайно полезно, поскольку раскрывает внутренний стандарт, не сообщая числового значения. [2][5]

Это заявление поднимает четыре вопроса.

Во-первых, что измерял проектный показатель? Он мог относиться к доступности авторитативных ответов, времени до автоматического восстановления, времени до вмешательства оператора или полному восстановлению сервиса. Эти вещи не взаимозаменяемы.

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

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

В-четвёртых, как был валидирован ремонт? Microsoft перечислила исправление дефекта кода, чтобы запросы могли эффективно обрабатываться в кэше, и улучшение автоматического обнаружения и подавления аномального трафика. [2][4] Список рабочих элементов — не свидетельство завершения.

Надлежащее закрытие привязало бы каждый критерий к тесту:

Критерий	Необходимые доказательства
Исправление дефекта кэша	Тест воспроизведения триггерной последовательности, эффективность кэша до и после, идентификаторы кода и развёртывания
Защита от повторных запросов	Контролируемая нагрузка повторов, сохранение легитимных ответов, доля ложных срабатываний, порог отката
Обнаружение аномалий	Задержка обнаружения по классам запросов, чувствительность и доказательства ложных тревог
Ёмкость пограничных узлов	Запас по насыщению на каждом узле при сниженной эффективности кэша
Автоматическое восстановление	Многократные прогоны вброса неисправностей и распределение времени восстановления
Восстановление сервисов	Внешнее зондирование репрезентативных имён Microsoft и клиентов в сетях резолверов

Без этих доказательств читатели могут знать, что Microsoft намеревалась улучшить, но не насколько снижен риск.

SLA — не замена доказательств по инциденту

Azure публикует SLA для зон DNS. Текущий документ определяет доступность сервиса и потенциальные сервисные кредиты в оговорённых контрактных условиях. [13] Он полезен для идентификации правовой и коммерческой границы на сегодня.

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

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

Поэтому учёт подотчётности должен вести три реестра раздельно:

Техническая доступность: что возвращали авторитативные и рекурсивные системы.
Воздействие на клиента: какие функции отказали, для кого и как долго.
Контрактное средство правовой защиты: какие условия, измерения и процедуры подачи претензий применялись.

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

Клиенты контролировали архитектуру, но не дефект Azure

Текущее руководство Azure по надёжности описывает ответственность провайдера и клиента. Azure управляет платформой DNS, тогда как клиенты настраивают зоны, записи, делегирование и некоторые решения по отказоустойчивости. [8][12]

Клиенты могут предпринять полезные шаги:

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

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

Авторитативный DNS с несколькими провайдерами может снизить одну общую моду отказа, но добавляет риски синхронизации зон, делегирования, DNSSEC, контроля доступа и аварийного переключения. RFC 9199 подчёркивает контекст, а не один предписанный дизайн. [14] Второй провайдер, разделяющий маршрутизацию, доступ к регистратору, автоматизацию или операционный персонал, может не быть независимым в значимых аспектах.

Уместное решение клиента — документированное принятие риска:

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

Устойчивость клиента — это слой защиты. Это не оправдание для инфраструктурного оператора оставить собственный дефект и поведение подавления неизмеренными.

Ответственность следует за контролем и доступом к доказательствам

Публичная запись поддерживает распределение на основе контроля.

Инженеры Azure DNS

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

Управление инцидентами Microsoft

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

Владельцы сервисов Microsoft

Команды, управляющие Azure, Dynamics, Xbox Live, Microsoft 365 и связанными поверхностями управления, контролировали дизайн своих зависимостей и внешний мониторинг. Они не контролировали дефект DNS, но могли определить, разделяют ли критически важные имена, страницы статуса и инструменты восстановления один и тот же авторитативный путь.

Операторы рекурсивных резолверов и клиентов

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

Клиенты

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

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

Контрфактический анализ показывает, какие элементы управления важны

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

Если бы аномальный всплеск произошёл без дефекта кэша

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

Если бы дефект кэша появился без всплеска

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

Если бы повторы были ограничены немедленно

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

Если бы каждый резолвер выдавал устаревшие ответы

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

Если бы клиенты использовали двух авторитативных провайдеров

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

Если бы было доступно больше граничной ёмкости

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

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

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

Источники создают полезный контур, но оставляют решающую внутреннюю запись недоступной.

Они не устанавливают:

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

Текущая документация Microsoft не может заполнить эти исторические пробелы. Она описывает сегодняшний сервис и рекомендуемые практики. [7]-[13] RFC определяют поведение протоколов и эксплуатационные опции. [14]-[22] Независимые отчёты сохраняют заявления и симптомы, но не имеют внутренней телеметрии Azure. [2]-[6]

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

Ремонт должен быть проверяем как последовательность

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

Воспроизвести

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

Измерить

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

Сдержать

Применить ограниченное формирование повторов и контроль аномального трафика. Протестировать заведомо валидные имена, холодные и тёплые состояния кэша, негативные ответы, ответы DNSSEC и поведения нескольких резолверов. Измерить ложные срабатывания.

Восстановить

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

Верифицировать зависимые сервисы

Зондировать репрезентативные имена Azure, плоскости управления Microsoft и клиентские имена с нескольких рекурсивных резолверов и сетей доступа. Отличать восстановление DNS от восстановления приложений.

Откатить

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

Сохранить доказательства

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

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

Заключение

Сбой Azure DNS в апреле 2021 года не объяснялся одним лишь объёмом трафика.

Microsoft заявила, что аномальный всплеск запросов выявил дефект кода, снизивший эффективность граничного кэша DNS. Ухудшение сервиса заставило клиентов повторять запросы. Эти повторы были легитимным трафиком, поэтому объёмное подавление первоначально не отбрасывало их. Сервис восстановился автоматически, но не в пределах проектного показателя. Затем Microsoft изменила защиту от повторов и заявила, что исправит дефект кэша и улучшит обнаружение аномалий. [2][4][5]

Эта последовательность выявляет проблему подотчётности сетевой инфраструктуры с несколькими слоями:

Всплеск был триггером, описанным Microsoft, а не доказанной атакой.
Дефект кэша был внутренним способствующим условием, увеличившим работу.
Легитимное поведение повторов усилило нагрузку на границе «резолвер—авторитативный сервер».
Логика подавления первоначально не сдерживала этот совокупный валидный трафик.
Общая зависимость от DNS превратила один сбой разрешения в множество видимых отказов сервисов.
Метрики восстановления не соответствовали напрямую опыту каждого пользователя.

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

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

Клиенты должны тестировать решения непрерывности, которые они реально могут контролировать.

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

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