dxdt.blog: занимательный интернет-журнал

Важный момент про DNS-over-TLS (DoT) и DNS-over-HTTPS (DoH): в случае, когда валидацию DNSSEC проводит внешний рекурсивный резолвер, использование DoT/DoH на “последней миле” позволяет эффективно продолжить цепочку доверия DNSSEC до клиента; правда, через дополнительный шаг – аутентификацию сервера в рамках TLS. То есть, если некоторый клиентский stub-резолвер использует гугловый сервис 8.8.8.8 и доверяет его валидации DNSSEC, но сам валидацию не проводит, то, в классическом случае, никто не мешает на транзитном узле вмешиваться в трафик и присылать фиктивные ответы от имени 8.8.8.8, в которых будет что угодно. Использование же DoT/DoH позволяет клиенту аутентифицировать узел (DNS-сервер) и проверять подлинность ответов, что распространяет доверие к валидации DNSSEC на случай, когда клиент не верит транзитным узлам (а им верить давно нельзя).

(Первоначально опубликовано на Facebook.com, 22/11/2019.)

Авторитативные серверы DNS – это серверы, которым делегирована поддержка заданной доменной зоны. Другими словами, это основные серверы, служащие первоисточником информации об адресации внутри доменной зоны. Именно к авторитативным серверам должен обращаться рекурсивный резолвер при поиске значений DNS-записей.

DNS-over-TLS – технология, защищающая трафик DNS-запросов при помощи TLS. Обычно, DNS-запросы и DNS-ответы передаются по протоколу UDP (реже – TCP) в открытом и незащищённом виде. Существует технология DNSSEC, которая позволяет снабдить содержание DNS-ответов электронной подписью, затруднив, таким образом, подмену информации. Но DNSSEC не скрывает сам трафик: то есть, третья сторона всё равно будет видеть состав запросов и ответов. Кроме того, DNSSEC аутентифицирует только передаваемые данные, привязывая их к некоторому открытому ключу, но не позволяет аутентифицировать сервер, который данные передал. В принципе, в модели угроз DNSSEC аутентификация сервера и не требуется: основная идея этой технологии состоит в том, что не имеет значения, каким маршрутом и от какого узла DNS-данные попали к клиенту – если данным соответствует валидная подпись от доверенного ключа, то они, так или иначе, достоверны. То есть, с точки зрения достоверности, канал получения DNS-информации для DNSSEC не важен. Если данные, защищённые DNSSEC, будут как-то изменены на транзитном узле, то клиент сможет обнаружить подмену. С DNS-over-TLS (или DoT) – другая история. Эта технология оборачивает обычный трафик DNS в TLS, создавая защищённый канал связи. DoT позволяет узлам, которые намерены обменяться DNS-запросом и DNS-ответом, аутентифицировать друг друга до отправки запроса. В подавляющем большинстве случаев, конечно, будет использоваться только аутентификация сервера клиентом.

В DNS, как в сервисе, большое значение имеет взаимодействие рекурсивного резолвера с так называемым stub-резолвером. Последний представляет собой самый простой вариант резолвера, который не выполняет поиска в DNS, а лишь перенаправляет запросы рекурсивному резолверу. Stub-резолвер – это типовой резолвер в подавляющем большинстве конфигураций операционных систем. Сервис же рекурсивного резолвера предоставляется либо провайдером доступа, либо отдельным провайдером DNS, как, например, в случае общедоступных резолверов Cloudflare (1.1.1.1) и Google (8.8.8.8).

Так вот, сейчас часто приходится слышать, что технология DNS-over-TLS предназначена лишь для защиты DNS-трафика на пути от stub-резолвера до рекурсивного резолвера, а на авторитативных серверах – не нужна. Это не так. Авторитативным серверам тоже рекомендована поддержка DNS-over-TLS, так как такая поддержка позволит защитить обмен информацией с рекурсивными резолверами. Дело в том, что прослушивание DNS-запросов или подмена данных – возможны и для трафика рекурсивного резолвера, адресованного не клиенту, а авторитативному серверу. Другое дело, что реализовать избирательность такой атаки становится сложнее, поскольку точно не известно, какие запросы какому клиенту соответствуют. Но, например, если используется популярный сервис DNS, то IP-адреса его узлов-резолверов известны, поэтому подмена может осуществляться избирательно. Впрочем, атакующему придётся каким-то образом встать своим транзитным узлом между авторитативным сервером и сервером DNS-резолвера. Это сложно, но возможно. Причём, разными способами. А не раз продемонстрированные на практике BGP-атаки позволяют перехватить трафик между сетями, которые, в смысле маршрутизации, находятся “далеко” от точки перехвата.

Поддержка DoT на авторитативных серверах пока что является большой редкостью и встречается существенно реже, чем даже поддержка DNSSEC. Тем не менее, один масштабный пример внедрения DoT здесь уже есть: технология поддерживается авторитативными серверами Facebook, на которые делегирована зона facebook.com.

Очень много сообщений про DNS-over-HTTPS в Firefox, про то, что внедрение этого протокола, якобы, “позволяет обходить любые блокировки и DPI”. Между тем, DNS-over-HTTPS (DoH) в Firefox – это способ сокрытия DNS-запросов и DNS-ответов от третьей стороны, причём скрываются только запросы от браузера до рекурсивного резолвера (подразумевается, что до резолвера Cloudflare). Заметьте, что использование DoH не скрывает рекурсивные запросы, источником которых является браузер Firefox. Например, если некоторую уникальную DNS-метку встроить в веб-страницу, то на авторитативном сервере будет видно, откуда пришёл рекурсивный запрос, соответствующий конкретной сессии конкретного браузера. По IP-адресу источника запроса (рекурсивного резолвера), по некоторым другим признакам, можно определить, используется ли клиентом штатный DNS от провайдера доступа, или это та или иная реализация DoH. В качестве источника DNS-меток (такой источник принято называть “праймером”) с большим охватом может работать любой популярный веб-сервис или веб-сайт: например, какой-нибудь веб-счётчик (что-то подобное “Яндекс.Метрике”), страница популярной социальной сети и т.д.

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

Предположим, что блокировка доступа к веб-ресурсу осуществляется провайдером на уровне DNS. Смысл подобного метода блокирования в том, чтобы браузер (или другие программы-клиенты) не мог определить подлинный IP-адрес, с которым требуется установить соединение. Как такая блокировка работает?

В простом варианте, провайдер так настраивает резолвер, обслуживающий клиента, что в ответ на запрос о заблокированном ресурсе (по имени домена) – резолвер возвращает не подлинный IP-адрес, а либо адрес сервера-заглушки, либо заведомо недоступный адрес. Чтобы это работало, клиент должен использовать DNS провайдера. Эта схема реализуется самыми элементарными средствами. Для её преодоления не требуется ничего зашифровывать, а достаточно использовать другой DNS-резолвер, не провайдерский.

В продвинутом варианте, уже система DPI обнаруживает все DNS-запросы и DNS-ответы, вне зависимости от того, к каким DNS-серверам они отправлены и от каких получены. Фильтрующий узел вмешивается в трафик в том случае, если силами DPI обнаружены запросы, относящиеся к заблокированным именам. Вмешательство в трафик может выражаться как в подмене ответов, так и в блокировании запросов; конечно, можно заблокировать и ответы. В этом случае DoH помогает, так как DPI перестаёт видеть DNS-трафик. Однако тот же фильтрующий узел и DPI можно настроить так, что они будут блокировать трафик DoH. Блокировать придётся весь трафик, а DPI потребуется очень серьёзно доработать. При этом в Firefox по умолчанию будут встроены средства, позволяющие предотвратить автоматическое включение использования DoH. Эти средства предназначены для корпоративных сетевых сред, где фильтрация DNS нередко является обязательным требованием “политик безопасности”. Такое поведение браузера пользователь может преодолеть, если включит использование DoH вручную.

(Отмечу, в скобках, что все описанные выше методы с подменой информации DNS противоречат DNSSEC и, соответственно, будут обнаружены, если клиент поддерживает DNSSEC.)

Защита от просмотра DNS-трафика никак не влияет на блокировку доступа непосредственно по IP-адресу узла: если соединение с конкретным адресом установить не удаётся, то не важно, как этот адрес был получен – через “открытый DNS” провайдера или через “защищённый DNS-over-HTTPS”. Да, нетрудно предложить вариант, в котором IP-адреса постоянно изменяются, а “верный адрес” передаётся только при использовании сервиса DoH. Так можно устроить, если авторитативные серверы DNS соответствующей доменной зоны как-то связаны с провайдером сервиса DoH. Однако при этом активная система блокирования может узнавать “верные адреса”, просто используя свой экземпляр браузера Firefox. Конечно, всегда остаётся экстенсивный вариант развития данной схемы, при котором, с одной стороны, сотни тысяч IP-адресов случайно распределяются по DNS-ответам, а с другой стороны – какие-то, – возможно те же, – сотни тысяч и миллионы адресов попадают под превентивную блокировку. При этом DoH здесь помогает только тем сервисам, у которых очень много IP-адресов.

Нередко можно услышать, что данный метод, применительно к проблеме блокирования доступа, хорош тем, что его трафик, по внешним признакам, не отличается от “обычного HTTPS” (то есть, от HTTPS для веб-сайта). Мало кто готов блокировать весь HTTPS-трафик. Конечно, приложив достаточно вычислительных мощностей, попытаться отличить трафик DoH от работы с веб-сайтами – можно: есть IP-адреса, есть характеристики отправляемых и принимаемых пакетов, продвинутая система блокирования умеет делать проверку сервисов (connection probe) и так далее. Другое дело, что ресурсов для блокирования потребуется действительно много и будут ложные срабатывания. Более того, в качестве следующего шага по защите возможно заворачивание DNS-трафика в “самый настоящий” HTTPS-сеанс работы с обычным веб-сайтом: DNS-запросы могут передаваться браузером в качестве нагрузки, в специальных HTTP-заголовках; и в таких же HTTP-заголовках сервер пришлёт ответы.

В целом, сверхидея DNS-over-HTTPS хорошо укладывается в самую современную концепцию в области информационной безопасности. В этой концепции “доверенными” являются только приложения – клиентское и серверное. То есть, даже операционная система не относится к доверенным. Криптография позволяет двум приложениям надёжно идентифицировать (и аутентифицировать) друг друга: браузер Firefox, используя принесённые с собой TLS-сертификаты, идентифицирует и аутентифицирует серверное приложение, которое исполняется на узлах Cloudflare и реализует сервис рекурсивного опроса доменных имён. Для схемы не важно, каким образом, по каким транзитным сетям, приложения устанавливают между собой соединение. Да, тут есть масса оговорок – про аппаратуру, которая исполняет команды; про ядро ОС, имеющее полный доступ к памяти приложений; и так далее. Но, тем не менее, логическая концепция именно такая. Развитие этой идеи в ближайшем будущем приведёт к тому, что появятся “различные интернеты”, работающие внутри того или иного приложения. Но это другая история.

Вернёмся к DoH в браузере Firefox. Данный инструмент, сам по себе, не является универсальным средством, “позволяющим обходить все блокировки”, но он защищает от утечки информации о DNS-запросах/DNS-ответах на “последней миле”: то есть, на пути от резолвера до браузера. При этом браузер замыкает на стороне пользователя некоторый особый контур, в который теперь входит и защищённая доставка контента (TLS на веб-сайтах), и собственный сервис доменных имён. “Интернет – это то, что показывается в браузере”.

По адресу http://hold-my-beer.xyz/ (да, он несколько странный, но правильный) – я разместил веб-интерфейс экспериментального сервиса, который пытается определить, поддерживает ли ваш DNS-резолвер валидацию DNSSEC. Довольно давно я уже сделал сервис, проверяющий поддержку DNSSEC при помощи браузера. Отличие нового эксперимента в том, что здесь проверка происходит также и на серверной стороне, а в браузер передаются адреса резолверов – как они видны на авторитативных серверах. То есть, методика измерения совсем другая, более полная, так как позволяет собирать статистику. Но, повторюсь, это пока эксперимент.

Для проверки – достаточно зайти браузером по ссылке. Там есть и визуальный “флаг”, который покажет, поддерживается ли валидация DNSSEC (вверху страницы, зелёный/красный). Сразу оговорю технический момент, связанный с сервисом резолвера Google Public DNS (8.8.8.8): этот сервис заявлен как валидирующий, но в случае данного теста – браузер покажет, что поддержки DNSSEC нет. И это действительно так. Причина в том, что для теста используются имена (DNS-зоны) четвёртого уровня и ниже, и здесь сервис Google почему-то не проводит валидацию (возможно, так задумано, возможно – это ошибка: нужно будет написать в Google). При использовании, например, Cloudflare (1.1.1.1) – всё работает нормально, как ожидается.

http://hold-my-beer.xyz/

(Это временный сервис, точнее – демонстратор технологии.)

Update (25/07/2019): эксперимент закончен, сервис пока недоступен.

Открытый сервис DNS-резолвинга 1.1.1.1 от Cloudflare, оказывается, реализует QNAME Minimization – это метод, снижающий утечку через DNS информации о посещаемых узлах, я описывал его несколько лет назад.

Интересно, что у 1.1.1.1 сейчас реализованы все инструменты защиты DNS: DNS-over-TLS, валидация DNSSEC (более строгая, чем у Google Public DNS), QNAME Minimization. В случае с последней технологией, использование TLS, само по себе, не закрывает утечку, так как без “минимизации” – информация о полном имени уходит на все авторитативные серверы, присутствующие в цепочке.

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

А вот DNS авторам удаётся подменить полностью, несмотря на то, что LTE считается существенно более защищённой технологией, по сравнению с предыдущими поколениями 2G/3G. Суть атаки состоит в подмене части данных внутри UDP-пакетов, представляющих запрос и ответ DNS. Для этого требуется провести активную атаку типа “человек посередине” (MiTM), то есть, абонентское устройство должно подключиться к подменному узлу, который транслирует пакеты между ним и “подлинной” LTE-сетью. Казалось бы, LTE – современный протокол. Тем не менее, для основной части пользовательских данных в нём не используется аутентификация сообщений, хотя данные и передаются в зашифрованном виде. Данные зашифровываются AES в режиме счётчика (CTR), но, так как целостность не проверяется, пакеты могут быть прозрачно изменены.

Как это происходит. DNS использует в качестве штатного транспорта UDP. Структура пакета заранее известна (она определяется спецификациями IP и UDP). Более того, обычно известен и IP-адрес DNS-сервера, которому предназначен исходный запрос: это сервер, предоставляемый оператором связи, а определить его адрес можно из настроек IP-транспорта. Задача атакующего состоит в том, чтобы перехватить пакеты, содержащие DNS-запросы, и подменить в них IP-адрес DNS-сервера провайдера на IP-адрес подменного DNS-сервера, находящегося под контролем атакующего. Если такая подмена будет успешно осуществлена на пути от абонентского устройства до “легитимной сети” LTE, то пакет будет доставлен по адресу, заданному атакующим, соответственно, ответить на запрос сможет подменный DNS-сервер (и ответ, понятно, может содержать адрес произвольного узла). Также нужно модифицировать ответный пакет, чтобы он содержал нужный адрес отправителя. Почему нельзя заменить ответы сразу на перехватывающем узле, без отправки дальше? Потому что всё же имеется некоторая защита трафика, а секретный симметричный ключ атакующему неизвестен.

В режиме шифрования CTR, блочный шифр используется для зашифрования некоторого значения, изменяющегося для каждого следующего блока – это даёт ключевую последовательность (или гамму). Далее вычисляется XOR от блоков открытого текста и соответствующих блоков ключевой последовательности: это прямое побайтовое суммирование. Так как атакующий перехватывает все сообщения, ему известно значение блока шифротекста. Также, из структуры пакетов, известны смещения байтов, содержащих запись IP-адреса и значения этих байтов. Соответственно, атакующий может легко вычислить такую маску, которая при последующем суммировании с ключевым потоком на стороне настоящей сети LTE даст в результате нужные значения байтов записи адреса. Эту маску атакующий записывает в нужный фрагмент зашифрованного пакета. Это типовая атака, очень давно известная для режимов CTR (это, конечно, только подчёркивает странность того факта, что в LTE здесь нет контроля целостности). Единственную небольшую проблему создают контрольные суммы, которые есть и в IP-пакете, и в части, относящейся к UDP. Авторы работы справляются с этой проблемой при помощи модификации значений дополнительных полей пакетов, которые также известны заранее (в частности, поле TTL IP).

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

Очередная новость “про блокировки” сообщает, что, якобы, Amazon запретил “использовать свои сети в качестве прокси” (варианты: использовать для “обхода блокировок” и др.). Сообщения сопровождаются ссылкой на публикацию AWS (Amazon Web Services), где, впрочем, рассказывается о другом.

О чём идет речь? Действительно, существует схема маскировки имени сервиса, под названием Domain Fronting. Схема построена на архитектурной особенности HTTPS: данный протокол использует TLS в качестве транспорта, соответственно, появляются два уровня – TLS и HTTP. С каждым из этих уровней связано некоторое имя сервера (имя хоста). В TLS это имя передаётся в поле SNI (Server Name Indication), в открытом виде, то есть, в виде, доступном для просмотра системой DPI. На уровне HTTP есть ещё одно имя сервера, оно входит в состав адреса документа (URI), который запрашивает клиент. Этот адрес, а следовательно и имя, входящее в его состав, передаётся уже в зашифрованном виде, поэтому недоступен для DPI.

Пример: пусть клиент, являющийся браузером, использует веб-сервер под именем “example.com” и пытается с помощью HTTPS извлечь документ по адресу “https://example.com/document.html”. Тогда при установлении TLS-соединения, которое происходит до отправки HTTP-запроса, браузером в поле SNI (TLS) будет передано имя “example.com” (обратите внимание: без полного адреса документа, только имя узла, домен). После того, как TLS-соединение установлено, браузер отправит GET-запрос HTTP, указав, согласно спецификации протокола HTTP, адрес документа “/document.html” и имя узла (в специальном поле заголовка HTTP-запроса, под названием Host) “example.com”. Это имя совпадает с именем на уровне TLS, в поле SNI, но вообще имена могут различаться, так как находятся на разных уровнях абстракции. Приложение, работающее по HTTP, вообще обычно не видит не только имени в SNI, но и самого протокола TLS.

Domain Fronting строится на подмене имён SNI и HTTP. В SNI указывается имя одного сервера, но после того, как TLS-соединение установлено, HTTP запросы отправляются с указанием другого имени. Поясню в терминах примера из предыдущего абзаца: в TLS SNI указывается имя “example.com”, однако GET-запрос уже отправляется с указанием “test.ru” в качестве имени хоста. Теперь на уровне HTTP указано совсем другое имя, но так как TLS и HTTP используют разный контекст, сервис, где размещён исходный узел (адресуемый example.com в нашем примере), может выполнять и HTTP-запросы к test.ru. Это будет являться побочным эффектом реализации HTTPS на стороне сервиса.

Теперь предположим, что из некоторого сегмента Глобальной сети доступ к test.ru по каким-то причинам невозможен. Используя Domain Fronting можно замаскировать запросы к test.ru под HTTPS-сессию с узлом example.com: так как HTTP-запросы передаются в зашифрованном виде, анализирующая трафик сторона видит только имя example.com в поле SNI TLS. Конечно, могут заблокировать и доступ к example.com, в том числе, по IP-адресу, но тут в игру вступает административная часть: представьте, что вместо example.com используется google.com (или какой-то другой массовый сервис) – мало кто готов блокировать условный Google. Конечно, чтобы всё сработало, требуется поддержка описанной схемы со стороны сервиса, используемого как прикрытие. Именно на этом этапе и возникает сервис “Амазон” CloudFront, который позволяет (или позволял, см. ниже) использовать такую схему для ресурсов, которые размещаются за CloudFront. При этом “заехать” за чей-то домен можно без ведома того клиента CloudFront, который этот домен использует штатно, что, конечно, не самая привлекательная особенность сервиса.

Метод маскировки с использованием Domain Fronting известен много лет. Наличие такой особенности объясняется тем, что для массового сервиса удобнее жёстко разделить TLS и HTTP – одни логические узлы обрабатывают TLS-соединение (выполняют “терминирование TLS”), а другие – работают с HTTP, уже в открытом виде. Поводом для новостей про “запрет обхода блокировок” как раз послужило то, что “Амазон” недавно обновил платформу CloudFront, исправив обработку контекстов и, тем самым, удалив возможность использования Domain Fronting. Думаю, понятно, что к “обходу блокировок” это если и имеет какое-то отношение, то весьма и весьма косвенное, и только со стороны тех нестандартных клиентов, которые данную особенность использовали. К ним, например, относится мессенджер Signal, который, впрочем, уже получил предупреждение о нарушении правил использования сервиса от Amazon.

Cloudflare официально запустили сервис DNS-резолвинга 1.1.1.1 (это IP-адрес, второй: 1.0.0.1). Резолвер работал под этим адресом уже некоторое время, но Cloudflare широко заявили о нём только первого апреля (такая вот шутка). Особенности сервиса: заявлена поддержка и DNS-over-TLS, и даже DNS-over-HTTPS (есть и такой новый протокол). По адресу 1.1.1.1 – доступен веб-сайт. При этом 1.1.1.1 в глобальной Сети нередко фильтруется или используется нерадивыми сетевыми администраторами в качестве “локального” IP-адреса, для внутренних тестов (не все готовы поверить, что это “обычный адрес”). Соответственно, сервис Cloudflare может быть недоступен из некоторых сетей. А вот адрес 1.0.0.1 – может трактоваться как синоним 1.1 (да, в короткой записи, две единицы), что позволяет прямо так и обращаться к узлу: $ ping 1.1

(В контексте DNS-over-TLS, напомню, что пару лет назад “Яндекс” занялся встраиванием в свой браузер другой технологии обеспечения безопасности DNS – DNSCrypt, но, похоже, DNSCrypt оказался неверным выбором.)

ICANN отложила ротацию корневого ключа DNSSEC на неопределённое время. Первоначально, фактическую ротацию планировали провести 11 октября этого года. В качестве причины указаны данные о недостаточном распространении нового KSK (корневого ключа) по резолверам. Напомню, что корневой ключ (RSA, разрядностью в 2048 бит) в DNSSEC не менялся с момента внедрения технологии в глобальной DNS, то есть, с 2010 года. О механизме ротации при запуске просто забыли. За это время такой алгоритм ротации был предложен и утверждён согласно процессу IETF (RFC 5011), но теперь ICANN при помощи другого технологического механизма (RFC 8145) и косвенных данных обнаружила, что алгоритм ротации не работает.

В принципе, учитывая общую инертность глобальной DNS, а также разнообразие сочетаний платформ и настроек в базовых транспортах Интернета, откладывать ротацию можно сколь угодно долго: среди трафика, пригодного для анализа, всегда найдутся следы дефектных реализаций, которые могут сломаться при замене KSK. При этом, вовсе не факт, что послужившие источником “проблемных сигналов” системы вообще умеют валидировать DNSSEC. В Сети действует огромное количество “аномальных систем”, которые по тем или иным причинам пренебрегают требованиями протоколов. В классической DNS такая ситуация особенно распространена: протоколы спроектированы таким образом, что продолжают худо-бедно решать основные задачи даже при весьма существенных ошибках и нарушениях в реализации. Поэтому сомневаться, что при замене корневого KSK что-то сломается – не приходится в любом случае. Самое занятное, что сломаться могут даже те системы, которые не проводили валидацию DNSSEC.

В инфраструктуре DNSSEC существует самый верхний ключ – KSK корневой зоны. К этому ключу ведут все (штатные) цепочки валидации DNSSEC, соответствующие общепринятой структуре DNS с единым корнем. Главный корневой ключ не менялся с момента запуска DNSSEC в 2010 году: спроектировать и согласовать механизм замены ключа каким-то образом забыли. Сейчас такой механизм появился, и начался процесс подготовки ротации KSK корня DNS: 11 июля в корневой зоне опубликован новый ключ (KSK) – KSK-2017. Так как новый KSK подписан действующим, можно произвести его замену автоматически, используя только DNS. Алгоритм описан в RFC 5011. То есть, если валидирующий резолвер поддерживает RFC 5011, то можно ожидать, что он автоматически заменит старый ключ на новый. Тем не менее, лучше заранее проверить, что резолвер смог получить новый ключ и включил его в список доверенных. Фактическая замена ключей (rollover) намечена на осень этого года (11 октября 2017) – до этого момента нужно убедиться, что ваш резолвер сможет использовать новый ключ, иначе валидация, спустя какое-то время после ротации, полностью сломается.

KSK-2017 можно добавить в резолвер и в ручном режиме, например, скопировав значение ключа из корневой зоны и проверив подписи. Информация о корневых ключах также доступна на сайте IANA.

DNS Privacy – актуальная тема. Речь здесь о том, как снизить утечки информации об использовании интернет-сервисов, происходящие через DNS. Как именно и какая информация утекает? В типичной пользовательской конфигурации, DNS служит базой данных, хранящей соответствие символьных имён и IP-адресов, а поиск в этой базе данных осуществляет рекурсивный резолвер интернет-провайдера (несколько реже – корпоративный рекурсивный резолвер).

Есть два основных потока утечек. Первый – это сведения об узлах, для которых запрашивались имена; во многих случаях эти данные близки к списку посещаемых веб-сайтов, но содержат и другие разнообразные сведения. Второй поток – “помеченный” трафик, характерный для конкретного браузера и конкретных веб-страниц. Ко второму случаю, например, относятся известные способы деанонимизации пользователей при помощи создания уникальных имён ресурсов, ссылки на которые встраиваются в код веб-страницы. Браузер, пытаясь извлечь ресурс по ссылке, отправит уникальный идентификатор страницы на сервер имён, поддерживающий зону DNS, которая послужила базисом в системе деанонимизации. Обычно маркером служит уникальное имя, созданное для конкретного запроса, например: kf356askg.example.com (уникальный идентификатор здесь – kf356askg). Интересно, что если вы просматриваете пользовательский DNS-трафик, то идентифицирующие маркеры можно распознавать и без использования серверов имён: они будут передаваться в открытом виде.

Нельзя сказать, что поток данных об активности пользователя, утекающих через DNS-запросы, огромен, но, учитывая, что про DNS мало кто из типичных современных интернет-пользователей знает, этот инструмент эффективен во многих случаях (пример – определение реальных сетевых реквизитов клиента TOR; сейчас, впрочем, актуально в меньшей степени).

При штатной работе DNS, резолвер всегда начинает опрос серверов с полным именем искомого ресурса в составе запроса. На минуточку предположим, что в нашем простом случае исчезло кеширование. Тогда, если пользователь, например, задумал обратиться на www.example.com, то об этом имени, сопоставленном с IP-адресом используемого резолвера, узнают и корневые серверы глобальной DNS, и корневые серверы .COM, и серверы имён зоны EXAMPLE.COM. Так устроен протокол. При этом, если исходить из необходимости получения А-записи для www.example.com, знать о полном имени запроса нужно только серверам зоны EXAMPLE.COM (строго говоря, серверам WWW.EXAMPLE.COM, но эти детали мы опустим). Борьба с данной утечкой называется QNAME Minimization – есть RFC 7816, со статусом Experimental. Основная идея состоит в том, чтобы резолверы направляли запросы, минимизируя утечки информации. В случае с www.example.com – можно спрашивать корневые серверы сразу об именах серверов имён (NS) зоны .COM, и так далее.

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

Защите DNS-трафика от прослушивания и, частично, подмены, посвящена технология DNS over TLS, описанная в свежем RFC 7858. Мало кто ожидает, что в ближайшее время при помощи TLS будут защищены все DNS-транзакции, но технология позволяет это сделать. Параллельное решение – DNSCrypt, про который я рассказывал не так давно. Вариант с TLS выглядит несколько более предпочтительным, так как вписан в существующую технологическую архитектуру Сети, где TLS является основной для защиты трафика.