Масштабирование корневой зоны DNS
ПредисловиеDNS – исключительно простая система. Ты отправляешь в неё запросы и получаешь ответы. Внутри системы используется столь же простой принцип: получивший запрос DNS-резолвер может не знать ответа, поэтому он, в свою очередь, отправляет запросы глубже в систему и получает ответы. Процесс отправки запроса и получения ответа одинаков и применяется рекуррентно. Всё очень просто.
Однако простоту DNS можно сравнить с простотой шахмат или го. Все они характеризуются ограниченной средой, управляемой небольшим набором строгих правил. Тем не менее, эти игры характеризуются поразительной сложностью.
Простые системы могут обладать очень глубокой сложностью. И это является основной темой исследования формальных систем. Изучение математики в XIX столетии двинулось в сторону головокружительных высот самоанализа. Исследователи пытались ответить на следующий вопрос: Каковы формальные предпосылки, на базе которых была построена вся суперструктура математики? Хорошим примером здесь являются аксиомы Пеано для натуральных чисел. Если взять эти аксиомы и применить к ним операции только из ограниченного и чётко определённого набора, то возможно ли получить каждое известное истинное (доказуемо корректное) утверждение в математике? Попытки ответить на этот вопрос подвигли Уайтхеда и Рассела написать в начале XX столетия фундаментальный трёхтомный труд Principia Mathematica, целью которого было построить всё здание математики, используя только начальные принципы и символическую (математическую) логику. Частично их труд был порождён интересом к логицизму, согласно которому все математические истины являются логическими. При этом математика рассматривалась как «чистая» форма философского исследования, чьи истины не зависели от наблюдателя или естественной системы. Курт Гёдель использовал указанный труд для того, чтобы прощупать границы такого подхода. Его книга «Теоремы о неполноте» (Incompleteness Theorems) содержит две теоремы математической логики, которые демонстрируют врождённые ограничения каждой формальной аксиоматической системы, которая способна смоделировать базовую арифметику. Эти результаты важны как для математической логики, так и для философии математики. Первая теорема о неполноте утверждает, что никакая непротиворечивая система аксиом, чей список теорем может быть составлен при помощи эффективной процедуры, не способна доказать все истины в отношении арифметики натуральных чисел. Для любой такой непротиворечивой формальной системы всегда будут существовать утверждения о натуральных числах, которые являются истинными, но которые нельзя доказать в рамках этой системы. Вторая теорема о неполноте, которая является продолжением первой, показывает, что такая система не может продемонстрировать собственную непротиворечивость.
Учитывая нашу всеобъемлющую веру в управляемые правилами автоматизированные системы, которые в основном заправляют современным цифровым миром, мысль о том, что ограничения такого взгляда на мир были четко установлены Куртом Гёделем в 1931 году, кажется отрезвляющей. Почему я об этом вспомнил? Если перевести работы Гёделя на простой язык, то можно сказать, что любая формальная система, которая обладает достаточной мощностью, чтобы быть полезной, также становится подверженной парадоксам. Или, на ещё более простом языке, любая ограниченная простая система, обладающая достаточной полезностью для выражения составных концепций, также способна на проявление непостижимой сложности. И именно здесь в бой вступает DNS!
Корневая зона
DNS не является словарем какого-либо естественного языка, хотя, когда мы сегодня используем термины вроде «facebook.com» в качестве имени собственного, может произойти смешение двух концепций! DNS представляет собой иерархическое пространство имен. Имена доменов составляются, используя упорядоченную последовательность меток. Такая упорядоченная последовательность меток служит для реализации целого ряда функций, но, возможно, самая полезная из них заключается в том, что её можно использовать в качестве неявной процедуры для трансляции имени домена в связанный с ним атрибут, используя для этого протокол разрешения имен DNS.
Например, я управляю веб-сервером, доступ к которому осуществляется с помощью DNS-имени www.potaroo.net. Если вы укажете это имя в своём браузере (адресной строке браузера), то браузеру сначала потребуется транслировать это имя в IP-адрес, чтобы знать, куда отправлять IP-пакеты для осуществления транзакции с моим сервером. Именно здесь используется структура имени. В данном случае DNS-система отправит корневому серверу запрос на трансляцию имени в соответствующий IP-адрес, а в качестве ответа получит набор серверов имен, которые полномочны, или авторитетны, для зоны «.net». Если запросить любой из этих .net-серверов в отношении того же имени, то в качестве ответа будут получены адреса серверов, которые полномочны для зоны «potaroo.net». Если запросить любой из этих potaroo.net-серверов в отношении того же имени, то в ответ будет прислан искомый IP-адрес. Точно таким же образом можно разложить любое DNS-имя. При этом само имя определяет порядок для процесса разрешения имени.
Для каждой операции по разрешению DNS-имени существует единая начальная точка: корневая зона. Существует направление научной мысли, которое порицает особое отношение к корневой зоне DNS. Это просто ещё одна зона, подобная любой другой. Набор её авторитетных серверов получает запросы и отвечает на них подобно любой другой зоне. В корневой зоне нет никакой магии и повышенное внимание к ней совершенно необоснованно.
Однако, по моему мнению, это ведет к недооценке важности корневой зоны DNS. Систему DNS можно рассматривать как обширную распределенную базу данных. И действительно, она так обширна, что не существует единой статичной карты, которая идентифицирует каждый авторитетный источник информации и набор точек данных, в отношении которых он полномочен. Вместо этого мы используем процесс динамического обнаружения, в ходе которого сначала DNS-имя направляется с целью обнаружения авторитетного сервера, который располагает данными об имени, которое требуется преобразовать, после чего на этот сервер отправляется соответствующий запрос. Такая система прекрасна тем, что запросы на обнаружение и конечный запрос в каждом случае идентичны.
Однако для всего требуется начальная точка. Рекурсивный преобразователь (резолвер) DNS заранее не знает обо всех авторитетных серверах DNS и никогда не будет знать. Но он знает кое-что другое. IP-адрес по крайней мере одного из корневых серверов. С этой начальной точки всё остальное можно построить в процессе работы. Резолвер может запросить у корневого сервера имена и IP-адреса всех остальных корневых серверов (так называемый подготавливающий запрос, priming query) и сохранить этот ответ в локальном кэше. После того, как преобразователь получит имя для разрешения (преобразования), он начинает с отправки корневому серверу запроса на поиск следующей точки в иерархии делегирования имени и продолжает в том же духе.
Работай так система DNS на самом деле, очевидно, что она буквально расплавилась бы через несколько секунд. Что делает такой подход жизнеспособным, так это локальное кэширование. Резолвер DNS сохраняет ответы в локальном кэше и использует эту локально хранящуюся информацию для ответа на последующие запросы в течение всего срока жизни кэшированной записи. Вероятно поэтому более точное утверждение о роли корневых серверов заключается в том, что каждая операция преобразования DNS начинается с обращения к кэшированному состоянию корневой зоны. Если на запрос нельзя ответить с помощью локального кэша, то запрашивается корневой сервер.
Однако на задворках этого утверждения затаилось неудобное замечание. Если корневые серверы станут недоступными, то прекратит работу вся система DNS. Возможно, во многих отношениях это является театральным преувеличением, поскольку такое событие не повлечет за собой внезапного коллапса системы DNS и остального Интернета вместе с ней. В гипотетической ситуации, когда станут недоступными все экземпляры корневых серверов, резорлверы DNS продолжат работу, используя сохраненную в локальном кэше информацию. Однако по мере истечения срока жизни записей кэша они будут удаляться из локальных преобразователей, поскольку не будет происходить их обновления посредством отправки повторных запросов на корневые серверы. Огни DNS будут постепенно гаснуть по мере превышения лимита времени для кэшированных записей. Именно это отличает корневую зону DNS от любой другой зоны. Она является местом главного поиска для всех остальных зон. Именно поэтому она заслуживает особого внимания.
Благодаря локальному кэшированию серверы корневой зоны не запрашиваются при каждом поиске DNS. Теоретически, корневые серверы должны получать запросы только в случае отсутствия данных в кэше. При относительно небольшой корневой зоне и относительно малом наборе резолверов DNS нагрузка на корневую зону не должна быть значительной. Даже если принять во внимание рост базы пользователей Интернета, нагрузка (в виде запросов) не обязательно должна расти. Если следовать данной теории о работе корневого домена DNS, то именно количество резолверов DNS определяет нагрузку корневых серверов.
Однако эта теория не выдерживает проверки практикой. Почему же наблюдается непрерывная тенденция роста количества запросов к совокупности корневых серверов? Общее количество запросов в день, зарегистрированное корневыми серверами, показано на рис. 1.
Рис. 1. Общее количество запросов к корневым серверам в день (данные RSSAC002).
Как представляется, за последние четыре года количество запросов к совокупности корневых серверов увеличилось в три раза. Какие же меры принимаются в ответ на это?
Данные, опубликованные корневыми серверами, используют структуру согласно документу RSSAC002 (https://www.icann.org/en/system/files/files/rssac-002-measurements-root-06jun16-en.pdf) и генерируются независимо большинством операторов корневых серверов. (Термин «большинством» означает, что я не смог найти данные об общем количестве запросов для корней B, E или G и данные о ежедневном количестве кодов ответа для корней A, B, E, F, G или J. Кроме того, нельзя сказать, что такие данные публикуются каждый день.)
Как можно в целом описать корневую службу (https://root-servers.org)? Обескураживающий ответ: как неполную и незаконченную. Можно получить лишь частичную картину того, что происходит в корневой системе, при этом не очень понятно, до какой степени публикуемые данные являются непротиворечивыми по времени, и не ясно, в какой степени они соотносятся с общим массивом данных. Составляют ли публикуемые данные 70% от общего объема? Или 95%? Или что-то в промежутке между этими значениями? Никто не знает. Утверждая, что за последние четыре года количество запросов «как представляется, увеличилось в три раза», я позволил себе значительную вольность при обращении с этим неполным набором данных. Это вызывает сожаление, поскольку без прочного информационного фундамента довольно проблематично выносить важные суждения о характеристиках корневой системы. Например, как повлияло кэширование NSEC на объемы корневых запросов? Или использование локального корневого пространства? Как быстро растет количество запросов? Почему оно растет? Как мы можем на это отреагировать?
Как и с множеством других вещей, с которыми люди сталкиваются в этом мире, мы получаем то, за что заплатили. Корневая служба предоставляется бесплатно, из чистого альтруизма, а не является платной договорной услугой. Поэтому вполне вероятно, что этот искаженный и неполный набор данных представляет собой даже нечто большее, чем можно получить за потраченные деньги!
Масштабирование корневой зоны
Работы по увеличению мощностей корневой зоны никогда не прекращаются. На рис. 1 видно, что в середине 2018 года на большинство корневых серверов подавалось 60 миллиардов запросов в день и это количество возросло до 120 миллиардов в середине 2020 года. Как на это реагируют операторы корневых серверов?
Первый набор ответных реакций на эти проблемы с масштабированием заключался в построении корневых серверов с более высокой сетевой пропускной способностью и увеличенной производительностью. Но поскольку со всей нагрузкой справляются лишь 13 серверов, невозможно обеспечить их масштабирование с той же скоростью, с которой растет Интернет. Потребуется нечто большее. Следующий шаг состоял в переходе от технологии unicast (отправка данных единственному получателю) к технологии anycast (отправка данных ближайшему из группы получателей). Хотя существует лишь 26 уникальных IP-адресов для корневых серверов (13 в протоколе IPv4 и 13 в IPv6), но каждый из обслуживающих их операторов теперь использует технологию anycast для репликации корневого сервиса в разных локациях. Текущее количество инсталляций с корневыми серверами описывается на сайте root-servers.org.
Таблица 1. Инсталляции anycast для корневых серверов (данные на сентябрь 2020 г. – прим. ред.)
В сумме это 1098 площадок, где имеются экземпляры корневых серверов.
Количество серверных систем превышает количество инсталляций, поскольку сегодня обычно задействуют несколько серверных систем в рамках одной инсталляции, а кроме того, компании используют несколько интерфейсных подсистем распределения запросов для распространения входящей нагрузки (в виде запросов) среди многих серверных систем.
Однако даже такой формы распределенной сервисной организации может оказаться недостаточно. Через два года потребуется удвоить мощности корневых сервисов, а ещё через два года понадобится очередное удвоение. И ещё раз, и ещё раз, и ещё раз. Экспоненциальный рост очень трудно выдержать.
Между тем, эта задача, возможно, окажется ещё более сложной и не ограничится простым масштабированием. Необходимо будет подумать о деньгах.
Крупица альтруизма в насквозь коммерциализированном Интернете
Не вызывает сомнений, что используемая корневым сервисом модель является анахронизмом для современного Интернета.
Двенадцать организаций, управляющих экземплярами корневых серверов, делают это без всякой оплаты или компенсации расходов. Когда «Администрация адресного пространства Интернет» (IANA) первый раз регистрировала организации, желающие взять на себя эту роль, Интернет был в основном исследовательским проектом, который лишь делал первые шаги по превращению в глобальную сеть. Выбор операторов корневых серверов был основан на стремлении разместить серверы таким образом, чтобы это размещение соответствовало тогдашнему контингенту пользователей. При этом требовалось обеспечить автономный режим работы без каких-либо обязательств по централизованному финансированию. В то время предполагалось, что эксплуатация корневых серверов не будет финансироваться.
За прошедшие 30 лет Интернет очень сильно поменялся во многих аспектах. Однако один аспект остался неизменным. В нем по-прежнему не существует организованной модели финансирования для корневой службы. Администраторы доменов верхнего уровня, список которых находится в корневой зоне, никак не платят – ни напрямую, ни косвенно – за инфраструктуру, которая поддерживает запросы корневой зоны. Различные резолверы, передающие запросы серверам корневой зоны, также никак за это не платят. Никто ни за что не платит. Эта служба по-прежнему работает из чистой благотворительности.
Совокупные мощности, предоставляемые операторами корневой службы, должны удваиваться приблизительно каждые два года, но это приходится делать без каких-либо общих или запланированных договоренностей о финансировании. И если не произойдёт резких изменений в том, как используется система DNS, это удвоение будет продолжаться. Поэтому со временем задача развертывания новых мощностей, соответствующих растущим нагрузкам, станет всё более накладной.
Однако я должен сказать, что эта проблема точно не является непреодолимой и в ближайшее время нас не ждёт связанный с ней кризис. Корневая служба по-прежнему хорошо справляется с текущими нагрузками (в виде запросов) и даже способна поглотить большинство видов направленных против неё DDoS-атак. Между тем, продолжающееся чрезмерное техническое усложнение корневой системы свидетельствует о тенденции использовать грубую силу, что требует непрерывного роста мощностей. Существуют ли другие подходы, позволяющие снизить объем трафика, поступающего на корневые серверы? Что нам известно обо всех этих запросах, направляемых в корневую зону? Возможно ли использование других подходов для снижения этого трафика? Для ответа на эти вопросы может быть полезно взглянуть на трафик запросов, поступающих на корневые серверы.
Корневые запросы
За последние десятилетия было проведено большое число исследований корневой службы и поведения системы DNS. Если корневые серверы были изначально предназначены для использования только в случае отсутствия данных в кэше преобразователей DNS, то происходящее в корневой зоне не полностью соответствует модели промахов кэша. Мы фактически не очень ясно представляем, что происходит в корневой зоне!
Сообщается, что большинство запросов к корневым серверам приводит к ответам NXDOMAIN (отсутствие запрашиваемого имени/метки – прим. ред.). При просмотре опубликованных данных о кодах ответов создаётся впечатление, что примерно 75% запросов корневой зоны приводят к ответам NXDOMAIN (рис. 2), причём в последние пару лет эта пропорция даже выросла.
Рис. 2. Пропорция ответов NXDOMAIN на запросы в корневую зону в день (данные RSSAC002).
Очень любопытный аспект этого поведения заключается в том, что процентная доля запросного трафика, по-видимому, сильно различается (до 20%) для каждой буквы корневой службы. Во многих отношениях корневые серверы намеренно делают идентичными, и такие колебания профилей запросов корневой зоны довольно необычны.
Согласно сообщению Дуэйна Весселса (Duane Wessels) из компании Versign на состоявшейся в июне 2020 года встрече DNSOARC 32, браузер Chrome генерирует три DNS-запроса, состоящих из одной метки длинной от 7 до 15 символов-букв. До февраля 2015 года используемый этим браузером код генерировал только 10-символьные метки, а переход к рандомизированной длине, а также к рандомизированным меткам произошел в версиях кода за февраль 2015. Механизм браузера отправляет такие запросы при его запуске, а также при изменениях локального IP-адреса и локального DNS-сервера.
Мотивы, по которым браузер Google Chrome это делает, довольно очевидны. Многие интернет-провайдеры выполняют в своих DNS-резолверах замену NXDOMAIN, заменяя ответ «no such domain» (такого домена не существует) на синтетический указатель, ведущий на их собственную страницу поиска, что позволяет им монетизировать все подобные опечатки пользователей. Однако Google не очень хорошо воспринимает такую замену NXDOMAIN. Поиск является основным способом размещения рекламы, а реклама – это главный источник доходов Google. Так каким же образом Google Chrome обнаруживает сетевые среды, в которых происходит замена NXDOMAIN? Всё очень просто. Необходимо протестировать систему DNS, используя собственные запросы с одноразовой случайной строкой, и определить таким образом, происходит ли замена NXDOMAIN.
Такое, казалось бы, безобидное зондирование системы DNS должно по идее быть довольно безвредным. Но браузер Chrome сегодня использует множество людей. По многим оценкам, примерно две трети используемых в современном Интернете браузеров являются браузерами Chrome, и это количество ещё больше возрастает, если учесть такие продукты, как Edge, которые основаны на ядре Chrome. Поэтому неудивительно, что согласно упомянутому выше докладу, доля таких зондирующих запросов составляет сегодня до 50% от совокупного трафика корневых серверов (рис. 3).
Рис. 3. Запросы браузера Chrome к корневой зоне. Информация взята из доклада Intranet Redirect Detector or Pseudo Random Subdomain Attack?, Дуэйн Весселс, Verisign, июнь 2020.
https://indico.dns-oarc.net/event/35/contributions/767/attachments/743/1260/OARC32achromium_queries_root.pdf
Частично сила Интернета основана на расщеплённом характере его сетевой инфраструктуры, в рамках которой многие поставщики сервисных компонентов работают только в выбранной ими нише, а общее слаживание коллективных усилий оставляется на волю рынка. Никто не возглавляет Интернет. Но эта сила может в некоторых случаях превращаться в слабость, особенно когда возникает потребность в изменении структуры издержек. Решение разработчиков Chrome зондировать корневую зону в поисках замен NXDOMAIN с помощью запросов с одноразовыми метками практически не увеличивает предельные издержки для браузера Chrome или пользователей Chrome. В то же время это решение приводит к значительным расходам операторов корневой службы, учитывая тот факт, что на него приходится половина их совокупной нагрузки (от запросов).
Но даже если принять во внимание смещение издержек и выгод, инструменты для исправления ситуации находятся в руках третьих лиц. Если бы все резолверы и их фронтальные балансировщики нагрузки эффективно выполняли NSEC-кэширование (и, предположительно, валидацию DNSSEC), то эти случайные запросы Chrome к верхнему уровню были бы поглощены кэшем NSEC в рекурсивном преобразователе.
В рамках централизованно координируемой среды издержки и выгоды можно было бы сравнивать напрямую, после чего развертывать экономически эффективные решения. Без такого взаимодействия существует слишком мало стимулов для того, чтобы либо группа, занимающаяся разработкой Chrome в рамках корпорации Google, либо операторы рекурсивных преобразователей потратили своё время и силы на снижение нагрузки от этого класса запросов. Поэтому корневые серверы остаются наедине со своей проблемой, не имея никаких средств, чтобы стимулировать любую другую сторону на её решение.
В то же время будет несправедливым приписывать весь этот трафик запросов исключительно браузеру Chrome. Если посмотреть на то, как ответы NXDOMAIN обрабатываются в системе DNS, можно обнаружить, что система DNS сама является частью проблемы. Мы изучили поведение DNS в тех случаях, когда браузер отправлял в DNS запрос, на который ответом было значение NXDOMAIN, проведя этот тест с участием примерно семи миллионов пользователей со всех концов Интернета (https://www.potaroo.net/ispcol/2019-02/nxd.html). На авторитетных серверах для этого имени домена мы обнаружили в среднем 2,2 запроса на каждый исходный запрос браузера, что более чем в два раза превышало наши наивные ожидания. Поэтому вполне возможно, что вклад Chrome составляет только 25% от общей нагрузки на корневые серверы, а инфраструктура резолверов DNS обеспечивает удвоение отправляемого на них количества запросов.
Кроме того, существует дополнительный усиливающий фактор. В системе DNS имеется значительная доля «зомби»-трафика. Проведённое компанией APNIC Labs исследование с использованием динамической метки DNS, которое включало время создания метки, установило, что примерно 25% всех DNS-запросов, полученных нашим авторитетным сервером, были не связаны с первоначальным использованием этой DNS-метки (https://www.potaroo.net/ispcol/2016-03/zombies.pdf). Существует целый ряд причин, по которым «старые» запросы повторно воспроизводятся в системе DNS. Там есть много точек, где запросы фиксируются и регистрируются в журналах, а анализ этих журналов связан, по-видимому, с повторной отправкой запроса. В других случаях создается впечатление, что преобразователь зацикливается в петле программного кода и отправляет огромное количество повторных запросов (миллиарды в течение нескольких недель) для одного и того же имени DNS.
Хотя всё это напрямую не связано с механизмом браузера Chrome, отправляй он эти запросы в более глубокую зону иерархии DNS по сравнению с корневой, это позволило бы значительно уменьшить исходную и добавленную нагрузки на корневую зону. Корневые серверы избавились бы более чем от половины свой текущей запросной нагрузки.
Наряду с этим значительным компонентом трафика существует фактор утечки имен. Многие среды используют локально определяемые зоны DNS для того, чтобы пометить сервисы, и даже когда устройства перемещаются из этих локальных доменов, они по-прежнему запрашивают локально определяемые имена. Запросы в корневую зону для неделегированных зон включают метки верхнего уровня .home, .corp, .local и .mail, а также целый ряд наименований поставщиков CPE (https://www.potaroo.net/presentations/2014-06-24-namecollide.pdf). Делегирование этих меток позволило бы вывести такие запросы из корневой зоны, но одновременно может создать целый ряд проблем безопасности, когда имена, предназначенные для интерпретации в одном сетевом контексте, интерпретируются в другом, что способно привести к удивительным и потенциально угрожающим результатам. Хотя в некоторых отдельных случаях такие утечки запросов в корневую зону можно исправить за счет изменения поведения приложений или устройств в рамках эксплуатационных обновлений, другие случаи поведения укоренились более глубоко и их исправление сопряжено с более значительными трудностями.
Перенаправление запросов
Изменение поведения устройств и приложений с целью использования делегированных доменов даже в частных контекстах с тем, чтобы увести запросы из корневой зоны, представляется одним из возможных подходов к ограничению экспоненциального роста количества запросов в корневую зону. У меня нет большого оптимизма по поводу того, что это окажется очень эффективным, поскольку текущее распределение издержек в системе DNS работает против данного подхода. Использование корневой зоны является самой быстрой и к тому же бесплатной опцией, а корневые серверы очень внимательно относятся к приватности данных. Применение неделегированных частных доменов или случайных имён в случае Chrome – это бесплатная опция, а последующие данные запросов являются в основном частными. Любой альтернативный подход потребует переноса нагрузки на другие серверы, что может привести к переносу издержек на приложение или поставщика устройств. При этом пользоваться корневой зоной можно бесплатно и быстро, и она просто работает! Какие могут быть проблемы? Возможно, потребуется рассмотреть другие подходы. Каким ещё способом можно «отфутболить» эти запросы от системы корневых серверов? Здесь нам могут помочь следующие два подхода.
Кэширование NSEC
Первый описывается в документах RFC8198 и представляет собой кэширование NSEC. Если метка верхнего уровня не существует в подписанной с помощью DNSSEC зоне и запрос имеет активный флаг DNSSEC EDNS(0), то ответ NXDOMAIN от корневого сервера включает подписанную запись NSEC, выдающую две метки, которые существуют в корневой зоне и которые «окружают» несуществующую метку. Записи NSEC сообщают нечто большее, чем «эта метка отсутствует в данной зоне». Они указывают, что в зоне не существует каждая метка, которая в лексикографическом смысле расположена между двумя вышеупомянутыми метками. Если резолвер поместит эту запись NSEC в кэш, то он сможет её использовать для ответа на все последующие запросы, содержащие имена в данном диапазоне меток, точно так же, как он обычно использует «положительные» записи кэша.
Если все резолверы будут использовать кэширование NSEC, то количество запросов, получаемых в корневой зоне от резолверов, включая связанные с запросами Chrome, практически сведется к нулю. Поэтому так важно внедрить кэширование NSEC для резолверов. Программа BIND (Berkeley Internet Name Domain) поддерживает эту функцию начиная с версии 9.12. Резолверы Unbound поддерживает её начиная с версии 1.7.0. Резолверы Knot поддерживает её начиная с версии 2.0.0. Тем не менее, количество запросов, поступающих в корневую зону, продолжает расти.
С помощью компании APNIC Labs мы провели измерение кэширования NSEC и отчитались о результатах своей работы на собрании DNS OARC в октябре 2019 года (https://www.potaroo.net/presentations/2019-10-31-oarc-nseccaching.pdf). Результаты оказались не то чтобы обнадёживающими. Мы применили методологию, которая использует два запроса: первый запрос генерировал ответ NXDOMAIN и запись NSEC, если у резолвера для запроса был установлен флаг DNSSEC, после чего ждали две секунды и отправляли в диапазон NSEC второй запрос. Теоретически, мы должны были увидеть только первый, но не второй запрос. Примерно 30% пользователей находятся в сфере действия DNS-резолверов, которые устанавливают в запросах флаг DNSSEC и, по наблюдениям, выполняют валидацию DNSSEC. Поэтому можно было ожидать, что такой эксперимент покажет уровень внедрения кэширования NSEC соответствующий приблизительно 30% пользователей. Однако мы наблюдали гораздо меньшую долю – 7% пользователей (рис. 4).
Рис. 4. Измерение кэширования NSEC, апрель 2019 г.
Возможно, мы слишком рано взялись за этот эксперимент. При измерении минимизации имени запроса в августе 2019 года развертывание этой функции составляло 3%, а через год, в августе 2020, те же измерения показали 18%. Поэтому мы, предположительно, проявили нетерпение и провели измерения слишком рано, а аналогичные результаты для сегодняшнего дня могут быть выше. Кроме того, надо признать, что метод измерения не очень хорошо соответствовал используемой сегодня модели инфраструктуры DNS. В настоящее время значительная доля инфраструктуры DNS-резолверов размещается в «фермах», на которых фронтальный распределитель передаёт каждый входящий запрос на одну из резолверных систем, развернутых на заднем плане. Хотя фронтальный распределитель, возможно, пытается оптимизировать работу кэша для запросов с тем же именем домена и направляет все такие запросы в одну систему, тот же самый подход не обязательно окажется эффективным для диапазонов имен – и запросы с разными метками могут отправляться разным резолверным системам. И наконец, существует вероятность, что кэширование NSEC уже хорошо работает! Доля ответов NXDOMAIN оставалась постоянной на уровне 75% за последние 12 месяцев, а общее количество корневых запросов оставалось относительно неизменным последние четыре месяца. Возможно, кэширование NSEC уже работает. (К сожалению, к этому утверждению применимы все оговорки в отношении качества и непротиворечивости отчетов корневых серверов, и нам остается лишь спекулировать на эту тему в отсутствие надежных данных.) Мы не можем точно знать на основе доступных данных. Кэширование NSEC может уже работать в системе DNS, и продолжающееся внедрение этой технологии в DNS-резолверах может в ближайшие месяцы привести как к снижению доли ответов NXDOMAIN, так и к уменьшению общего количества запросов.
Однако кэширование NSEC – это лишь тактический ответ на проблемы масштабирования корневой зоны, оно не является стратегическим решением. Всё по-прежнему зависит от инфраструктуры корневых серверов и использования запросного метода для распространения контента корневой зоны. Фактически, ничего не меняется в модели корневой службы. Кэширование NSEC лишь позволяет резолверам полноценно использовать информацию, содержащуюся в ответе NSEC. Больше ничего не изменилось.
Локальная корневая зона
Еще одна опция состоит в том, чтобы выйти за пределы модели запрос/ответ при изучении контента корневой зоны и просто загрузить всю корневую зону в рекурсивные резолверы. Идея этого подхода в том, что если в рекурсивный резолвер загружена копия корневой зоны, то он сможет работать автономно от корневых серверов в течение всего срока действия копии контента корневой зоны. Он больше не будет отправлять запросы на корневые серверы. Процедуры, используемые для загрузки локальной корневой зоны, детально задокументированы в RFC8806. При этом необходимо также отметить сервис LocalRoot (https://localroot.isi.edu/), который отправляет сообщения DNS NOTIFY в случае изменений в корневой зоне.
На сегодняшний день у этого подхода есть свои недостатки. Его неудобно использовать. Как узнать, что обслуживаемая зона является подлинной корневой зоной на текущий момент? Да, зона подписана, но подписан не каждый элемент, находящийся в зоне (например, записи NS). Клиенту требуется выполнить валидацию каждой цифровой подписи в зоне, и на сегодня их насчитывается 1376. До тех пор, пока не будет подписана вся корневая зона (это предложение сейчас оформлено в виде проекта для IETF: https://tools.ietf.org/html/draft-ietf-dnsop-dns-zone-digest-09 – этот проект был стандартизован в феврале 2021 и опубликован как RFC8976 (https://datatracker.ietf.org/doc/html/rfc8976) – прим. ред), никто не может быть уверен в том, что она является подлинной.
В то же время, эта модель может изменить саму природу корневой службы, в отличие от кэширования NSEC. Если есть что-то, что мы в последнее время научились делать исключительно хорошо, то это распределение контента. И действительно, мы сконцентрировали на этой области такие усилия, что весь Интернет кажется не более чем небольшим набором сетей распространения контента (CDN, Content Distribution Network). Если корневая зона будет полностью подписана подписями зоны, что позволит рекурсивному резолверу подтвердить её действительность и актуальность, и затем передана в распределительные системы просто как очередной объект, то инфраструктура CDN идеально подходит для передачи этой информации всей совокупности рекурсивных резолверов. Возможно, если изменить режим управления корневой зоны и генерировать новый файл зоны каждые 24 часа согласно строгому расписанию, то удастся избавиться от всей надстройки, обеспечивающей создание уведомлений. Например, каждая итерация контента корневой зоны публикуется заранее за два часа и остаётся действительной в течение ровно 24 часов.
Опции? Не мелочиться и брать всё!
Корневая служба используется в современном виде, поскольку до сих пор она работала достаточно хорошо. Но это не обязательно должно продолжаться вечно. В настоящее время у нас имеются опции для развития этой службы.
Благодаря перенаправлению части текущей нагрузки на точки делегирования, которые находятся ниже в иерархии доменов, можно добиться значительного снижения нагрузки от корневых запросов.
Научив резолверы лучше использовать подписанные записи NSEC, можно смягчить часть самых неотложных проблем, связанных с дальнейшим масштабированием корневой системы.
Но скорее всего, этого будет недостаточно. Мы можем либо продолжать в том же духе в ожидании коллапса системы и затем попытаться спасти DNS из месива обломков, либо можем исследовать альтернативы и попробовать уйти от модели распространения корневого контента на базе запросов, относясь к корневой зоне как к очередному массиву контента, находящемуся в более крупной экосистеме его распределения. Если нам удастся обеспечить экономичную загрузку текущей копии корневой зоны в каждый рекурсивный резолвер – а в настоящее время это не является сколько-нибудь трудной проблемой, – то у нас, возможно, получится избавиться от проблем масштабирования для системы корневых серверов, чтобы они могли отправлять ещё большее количество ответов «НЕТ!» всё более требовательным клиентам!
“Scaling the Root of the DNS”
(https://www.potaroo.net/ispcol/2020-09/root.html)