RFC 7626 | Вопросы конфиденциальности DNS

Аннотация

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

Скачать оригинальный документ на английском языке RFC 7626 PDF

1. Введение
2. Риски
2.1. Предполагаемый публичный характер данных DNS
2.2. Данные в запросе DNS
2.3. Шпионящий кэш
2.4. На проводе
2.5. В серверах
2.5.1. В рекурсивных резольверах
2.5.2. В авторитетных серверах имен
2.5.3. Мошеннические серверы
2.6. Повторная идентификация и другие ссылки
2.7. Дополнительная информация
3. Актуальные «Атаки»
4. Законность
5. Вопросы безопасности
6. Ссылки
6.1. Нормативные ссылки
6.2. Информационные ссылки
Благодарности
Адрес автора

Статус этой заметки

Этот документ не является спецификацией Internet Standards Track; опубликовано в ознакомительных целях.

Этот документ является продуктом Инженерной рабочей группы по Интернету (IETF). Он представляет собой консенсус сообщества IETF. Он получил общественное обозрение и был одобрен для публикации Руководящей группой по Интернет-разработкам (IESG). Не все документы, утвержденные IESG, являются кандидатами на любой уровень Интернет-стандарта; см. раздел 2 RFC 5741.

Информацию о текущем статусе этого документа, любых ошибках и способах предоставления отзывов о нем можно получить по адресу http://www.rfc-editor.org/info/rfc7626.

Уведомление об авторских правах

На данный документ распространяется действие ПП 78 и Правовые положения IETF Trust, относящиеся к документам IETF (http://trustee.ietf.org/license-info), действующие на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа. Компоненты кода, извлеченные из этого документа, должны включать в себя текст упрощенной лицензии BSD, как описано в разделе 4.e Правил доверия, и предоставляются без гарантии, как описано в упрощенной лицензии BSD.

1. Введение

Этот документ представляет собой анализ проблем конфиденциальности DNS в духе Раздела 8 [RFC6973].

Система доменных имен указана в [RFC1034], [RFC1035] и во многих более поздних RFC, которые никогда не были объединены. Это один из наиболее важных компонентов инфраструктуры Интернета, который часто игнорируется или неправильно понимается пользователями Интернета (и даже многими профессионалами). Почти каждое действие в Интернете начинается с DNS-запроса (и часто с нескольких). Его использование имеет много последствий для конфиденциальности, и это попытка составить полный и точный список.

Давайте начнем с упрощенного напоминания о том, как работает DNS. (См. Также [DNS-TERMS].) Клиент, преобразователь заглушки, отправляет DNS-запрос серверу, который называется рекурсивным преобразователем (также называемым кэширующим преобразователем или полным распознавателем или рекурсивным сервером имен). Давайте использовать запрос «Какие записи AAAA для www.example.com?» В качестве примера. AAAA — это QTYPE (тип запроса), а www.example.com — это QNAME (имя запроса). (Следующее описание предполагает холодный кэш, например, потому что сервер только что запустился.) Рекурсивный распознаватель сначала запросит корневые серверы имен. В большинстве случаев корневые серверы имен будут отправлять рефералов. В этом примере ссылка будет на серверы имен .com. Средство распознавания повторяет запрос к одному из серверов имен .com. Серверы имен .com, в свою очередь, будут ссылаться на серверы имен example.com. Сервер имен example.com вернет ответ. Корневые серверы имен, серверы имен .com и серверы имен example.com называются авторитетными серверами имен. При анализе проблем конфиденциальности важно помнить, что вопрос, задаваемый всем этим серверам имен, всегда является исходным, а не производным вопросом. Вопрос, отправляемый корневым серверам имен: «Что такое записи AAAA для www.example.com?», А не «Что такое серверы имен .com?». Повторяя полный вопрос, а не только соответствующую часть вопроса следующему в очереди, DNS предоставляет больше информации, чем необходимо серверу имен.

Поскольку DNS в значительной степени зависит от кэширования, алгоритм, описанный выше, на самом деле немного сложнее, и не все вопросы отправляются на авторитетные серверы имен. Если через несколько секунд преобразователь заглушки спросит рекурсивный преобразователь: «Каковы записи SRV _xmpp-server._tcp.example.com?», Рекурсивный преобразователь вспомнит, что ему известны серверы имен example.com, и просто запросить их, минуя рут и .com. Поскольку в обработчике заглушки обычно отсутствует кэширование, рекурсивный преобразователь, в отличие от авторитетных серверов, видит весь трафик DNS. (Приложения, такие как веб-браузеры, могут иметь некоторую форму кэширования, которая, например, не соответствует правилам DNS, поскольку может игнорировать TTL. Таким образом, рекурсивный распознаватель не видит все действия по разрешению имен.)

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

Сегодня почти все DNS-запросы отправляются по UDP [thomas-ditl-tcp]. Это имеет практические последствия при рассмотрении шифрования трафика в качестве возможного метода обеспечения конфиденциальности. Некоторые решения для шифрования предназначены только для TCP, а не UDP.

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

Основной запрос: это имя домена в URL-адресе, который пользователь вводил, выбирал из закладки или выбирал, щелкая гиперссылку. Предположительно, это то, что представляет интерес для подслушивающего.
Вторичные запросы: это дополнительные запросы, выполняемые пользовательским агентом (в данном случае веб-браузером) без какого-либо прямого участия или ведома пользователя. Для Интернета они запускаются встроенным контентом, каскадными таблицами стилей (CSS), кодом JavaScript, встроенными изображениями и т. Д. В некоторых случаях на одной веб-странице могут быть десятки доменных имен в разных контекстах.
Третичные запросы: это дополнительные запросы, выполняемые самой системой DNS. Например, если ответом на запрос является обращение к набору серверов имен, а склеенные записи не возвращаются, преобразователь должен будет выполнить дополнительные запросы, чтобы преобразовать имена серверов имен в IP-адреса. Точно так же, даже если возвращаются склеенные записи, осторожный рекурсивный сервер будет выполнять третичные запросы для проверки IP-адресов этих записей.

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

В отношении условий конфиденциальности мы будем использовать терминологию из [RFC6973].

2. Риски

В этом документе основное внимание уделяется изучению рисков конфиденциальности для конечного пользователя (который выполняет запросы DNS). Мы учитываем риски повсеместного наблюдения [RFC7258], а также риски, связанные с более сфокусированным наблюдением. Риски конфиденциальности для владельца зоны (риск получения данных кем-либо) обсуждаются в [RFC5936] и [RFC5155]. Риски, не связанные с конфиденциальностью (например, отравление кэша), выходят за рамки.

2.1. Предполагаемый публичный характер данных DNS

Уже давно утверждается, что «данные в DNS являются общедоступными». Хотя это предложение имеет смысл для поисковой системы в Интернете, для данных и метаданных существует несколько аспектов, которые заслуживают более подробного рассмотрения. Во-первых, несмотря на списки управления доступом и частные пространства имен, DNS работает в предположении, что публичные авторитетные серверы имен будут отвечать на «обычные» DNS-запросы для любой зоны, для которой они являются авторитетными, без дальнейшей аутентификации или авторизации клиента (распознавателя). Из-за отсутствия возможностей поиска только данное QNAME будет показывать записи ресурсов, связанные с этим именем (или с отсутствием этого имени). Другими словами: нужно знать, о чем просить, чтобы получить ответ. Передача зоны QTYPE [RFC5936] часто блокируется или ограничивается аутентифицированным / авторизованным доступом для обеспечения этой разницы (и, возможно, по другим причинам).

Еще одно различие, которое следует учитывать, заключается в самих данных DNS и конкретной транзакции (то есть поиск имени DNS). Данные DNS и результаты запроса DNS являются общедоступными в пределах границ, описанных выше, и могут не иметь каких-либо требований конфиденциальности. Однако то же самое не относится к одной транзакции или последовательности транзакций; эта транзакция не является / не должна быть публичной. Типичный пример извне мира DNS: веб-сайт Анонимных Алкоголиков является общедоступным; То, что вы посещаете его, не должно быть.

2.2. Данные в запросе DNS

Запрос DNS включает в себя множество полей, но два из них кажутся особенно актуальными для вопросов конфиденциальности: QNAME и IP-адрес источника. «IP-адрес источника» используется в широком смысле слова «IP-адрес источника + возможно порт источника», поскольку порт также находится в запросе и может использоваться для различения нескольких пользователей, совместно использующих IP-адрес (за NAT операторского уровня (CGN), например [RFC6269]).

QNAME — это полное имя, отправленное пользователем. Он дает информацию о том, что делает пользователь («Что такое MX-записи example.net?» Означает, что он, вероятно, хочет отправить электронное письмо кому-то по адресу example.net, который может быть доменом, используемым всего несколькими лицами, и поэтому очень Раскрытие информации об общении). Некоторые QNAME более чувствительны, чем другие. Например, при запросе записи A известного домена веб-статистики обнаруживается очень мало (все посещают веб-сайты, использующие эту аналитическую службу), но при этом запрашивается запись A www.verybad.example, где verybad.example является доменом организация, которую некоторые люди считают оскорбительной или нежелательной, может создать больше проблем для пользователя. Кроме того, иногда QNAME встраивает используемое программное обеспечение, что может быть проблемой конфиденциальности. Например, _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.example.org. Есть также некоторые клиенты BitTorrent, которые запрашивают запись SRV для _bittorrent-tracker._tcp.domain.example.

Еще одна важная вещь о конфиденциальности QNAME — это будущее использование. Сегодня отсутствие конфиденциальности является препятствием для размещения потенциально конфиденциальных или идентифицирующих личность данных в DNS. На данный момент ваш DNS-трафик может показать, что вы делаете электронную почту, но не с кем. Если ваш почтовый пользовательский агент (MUA) начинает поиск ключей Pretty Good Privacy (PGP) в DNS [DANE-OPENPGPKEY], то конфиденциальность становится намного важнее. И электронная почта — только пример; было бы другое действительно интересное использование для более дружественного конфиденциальности DNS.

Для связи между распознавателем-заглушкой и рекурсивным распознавателем IP-адрес источника — это адрес компьютера пользователя. Поэтому все вопросы и предупреждения о сборе IP-адресов применяются здесь. Для связи между рекурсивным распознавателем и официальными серверами имен IP-адрес источника имеет другое значение; он не имеет того же статуса, что и адрес источника в HTTP-соединении. Теперь это IP-адрес рекурсивного распознавателя, который каким-то образом «скрывает» реального пользователя. Однако сокрытие не всегда работает. Иногда используется [CLIENT-SUBNET] (см. Анализ конфиденциальности в [denis-edns-client-subnet]). Иногда конечный пользователь имеет личный рекурсивный распознаватель на своей машине. В обоих случаях IP-адрес является таким же чувствительным, как и для HTTP [sidn-entrada].

Примечание об IP-адресах: в настоящее время нет документа IETF, в котором подробно описываются все проблемы конфиденциальности, связанные с IP-адресацией. В то же время здесь обсуждаются адреса источников IPv4 и IPv6. По ряду причин их характеристики назначения и использования различны, что может иметь значение для деталей утечки информации, связанной со сбором адресов источника. (Например, конкретный адрес источника IPv6, видимый в общедоступном Интернете, с меньшей вероятностью, чем адрес IPv4, будет создаваться за CGN или другим NAT.) Однако для адресов как IPv4, так и IPv6 важно отметить, что адреса источника распространяются с запросы и содержат метаданные о хосте, пользователе или приложении, которые их создали.

2.3. Шпионящий кэш

Содержимое кэшей рекурсивных распознавателей может раскрывать данные о клиентах, использующих его (риски конфиденциальности зависят от количества клиентов). Эту информацию иногда можно проверить, отправив DNS-запросы с RD = 0 для проверки содержимого кэша, особенно глядя на DNS TTL [grangeia.snooping]. Поскольку это также метод разведки для последующих атак отравления кэша, некоторые контрмеры уже были разработаны и развернуты.

2.4. На проводе

DNS-трафик может быть замечен перехватчиком, как и любой другой трафик. Обычно он не зашифрован. (DNSSEC, указанный в [RFC4033], явно исключает конфиденциальность из своих целей.) Таким образом, если инициатор начинает связь HTTPS с получателем, в то время как трафик HTTP будет зашифрован, обмен DNS до этого не будет. Когда другие протоколы станут все более осведомленными о конфиденциальности и защищены от слежки, DNS может стать «самым слабым звеном» в конфиденциальности.

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

С точки зрения подслушивателя, лучшее место, куда можно прикоснуться, — это определенно между решателями-заглушками и рекурсивными решателями, потому что трафик не ограничивается кэшированием DNS.

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

Рекурсивный распознаватель может находиться на компьютере конечного пользователя. (В настоящее время) в небольшом числе случаев пользователи могут использовать собственный распознаватель DNS на своем локальном компьютере. В этом случае поверхность атаки для соединения между решателем заглушки и решателем кэширования ограничена этим единственным компьютером.
Рекурсивный распознаватель может находиться на границе локальной сети. Для многих / большинства корпоративных сетей и для некоторых бытовых пользователей решатель кэширования может существовать на сервере на границе локальной сети. В этом случае поверхностью атаки является локальная сеть. Обратите внимание, что в крупных корпоративных сетях DNS-распознаватель может располагаться не на границе локальной сети, а на границе всей корпоративной сети. В этом случае корпоративная сеть может рассматриваться как похожая на сеть провайдера доступа к Интернету (IAP), упомянутую ниже.
Рекурсивный распознаватель может находиться в помещении IAP. Для большинства бытовых пользователей и, возможно, других сетей, типичным случаем является конфигурация компьютера конечного пользователя (обычно автоматически через DHCP) с адресами рекурсивных преобразователей DNS в IAP. Следовательно, поверхность атаки для проводных атак — от системы конечного пользователя через локальную сеть и через сеть IAP до рекурсивных распознавателей IAP.
Рекурсивный распознаватель может быть общедоступной службой DNS. Некоторые машины могут быть настроены на использование общедоступных распознавателей DNS, таких как те, которые сегодня используются публичными DNS Google или OpenDNS. Конечный пользователь, возможно, настроил свою машину на использование этих рекурсивных преобразователей DNS — или их IAP, возможно, решил использовать общедоступные преобразователи DNS вместо использования собственных преобразователей. В этом случае поверхность атаки — это общедоступный Интернет между соединением конечного пользователя и общедоступной службой DNS.

2.5. В серверах

Используя терминологию [RFC6973], DNS-серверы (рекурсивные распознаватели и авторитетные серверы) являются активаторами: они облегчают связь между инициатором и получателем, не находясь непосредственно в канале связи. В результате они часто забываются при анализе рисков. Но, чтобы еще раз процитировать [RFC6973], «Хотя […] активаторы, как правило, не могут рассматриваться как злоумышленники, все они могут представлять угрозу конфиденциальности (в зависимости от контекста), потому что они способны наблюдать, собирать, обрабатывать и передавать конфиденциальные данные. » На языке [RFC6973] активаторы становятся наблюдателями, когда начинают собирать данные.

Существует много программ для сбора и анализа данных DNS на серверах — от «журнала запросов» некоторых программ, таких как BIND, до tcpdump и более сложных программ, таких как PacketQ [packetq] [packetq-list] и DNSmezzo [dnsmezzo]. Организация, управляющая DNS-сервером, может использовать эти данные самостоятельно или может быть частью программы наблюдения, такой как PRISM [призма], и передавать данные стороннему наблюдателю.

Иногда эти данные хранятся в течение длительного времени и / или передаются третьим лицам для исследовательских целей [ditl] [день в корне], анализа безопасности или задач наблюдения. Такое использование иногда осуществляется по какому-то контракту с различными ограничениями, например, на перераспределение, учитывая конфиденциальный характер данных. Кроме того, в сети есть точки наблюдения, которые собирают данные DNS, а затем делают их доступными для третьих лиц в исследовательских целях или в целях безопасности («пассивный DNS» [passive-dns]).

2.5.1. В рекурсивных резольверах

Рекурсивные резольверы видят весь трафик, так как перед ними обычно нет кэширования. Подводя итог: ваш рекурсивный распознаватель знает о вас многое. Средство распознавания большого IAP или большого общедоступного преобразователя может собирать данные от многих пользователей. Вы можете получить представление о данных, собранных, прочитав политику конфиденциальности большого общедоступного распознавателя, например, <https://developers.google.com/speed/public-dns/privacy>.

2.5.2. На авторитетных серверах имен

В отличие от того, что происходит с рекурсивными распознавателями, возможности наблюдения авторитетных серверов имен ограничены кэшированием; они видят только те запросы, на которые ответа не было в кеше. Для агрегированной статистики («Каков процент запросов LOC?») Этого достаточно, но это мешает наблюдателю видеть все. Тем не менее, авторитетные серверы имен видят часть трафика, и этого подмножества может быть достаточно, чтобы нарушить некоторые ожидания конфиденциальности.

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

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

Эта «защита» при использовании большого распознавателя со многими клиентами больше не присутствует, если используется [CLIENT-SUBNET], поскольку в этом случае полномочный сервер имен видит исходный IP-адрес (или префикс, в зависимости от настройки).

На сегодняшний день все экземпляры одного корневого сервера имен, L-root, получают около 50 000 запросов в секунду. Хотя большая часть из них является «мусорной» (ошибки в имени домена верхнего уровня (TLD)), она дает представление о количестве больших данных, поступающих на серверы имен. (И даже «мусор» может привести к утечке информации; например, если в TLD есть ошибка ввода, пользователь отправит данные в TLD, который не является обычным.)

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

Кроме того, кажется (см. Обзор, описанный в [aeris-dns]), что существует сильная концентрация авторитетных серверов имен среди «популярных» доменов (таких как список Alexa Top N). Например, среди Alexa Top 100K один DNS-провайдер размещает сегодня 10% доменов. Десять самых важных провайдеров DNS размещают вместе одну треть доменов. Благодаря контролю (или способности анализировать трафик) нескольких серверов имен вы можете собирать много информации.

2.5.3. Мошеннеческие серверы

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

Например, мошеннический DHCP-сервер или доверенный DHCP-сервер, конфигурация которого была изменена злоумышленниками, может направить вас к мошенническому рекурсивному преобразователю. Похоже, что в большинстве случаев это делается для того, чтобы перенаправить трафик, обманывая некоторые доменные имена. Но его можно использовать только для захвата трафика и сбора информации о вас. Возможны и другие атаки, кроме использования DHCP. Трафик от DNS-клиента к DNS-серверу может быть перехвачен по пути от источника к предполагаемому источнику, например, через прозрачные DNS-прокси в сети, которые будут перенаправлять трафик, предназначенный для законного DNS-сервера. Этот мошеннический сервер может маскироваться под предполагаемый сервер и отправлять данные клиенту. (Мошеннические серверы, которые внедряют вредоносные данные, возможны, но это отдельная проблема, не относящаяся к конфиденциальности.) Мошеннический сервер может корректно реагировать в течение длительного периода времени, что исключает возможность обнаружения. Это может быть сделано по тем причинам, которые могут быть названы вескими причинами, такими как оптимизация или кэширование, но это приводит к снижению конфиденциальности по сравнению с отсутствием злоумышленника. Кроме того, вредоносное ПО, такое как DNSchanger [dnschanger], может изменить рекурсивный распознаватель в конфигурации машины, или сама маршрутизация может быть подорвана (например, [mature-atlas-turkey]).

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

2.6. Повторная идентификация и другие ссылки

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

Например, пользователь может быть повторно идентифицирован с помощью запросов DNS. Если злоумышленник знает личность пользователя и может наблюдать за его DNS-запросами в течение определенного периода, то этот же злоумышленник может повторно идентифицировать пользователя, основываясь только на его шаблоне DNS-запросов, в дальнейшем, независимо от местоположения, из которого пользователь делает эти запросы. запросы. Например, одно исследование [herrmann-reidentification] показало, что такая повторная идентификация возможна, так что «73,1% всех повседневных ссылок были правильно установлены, то есть пользователь u был либо повторно идентифицирован однозначно (1), либо классификатор правильно сообщил что тебя больше не было в день t + 1 (2). » Хотя это исследование связано с поведением просмотра веб-страниц, одинаково характерные шаблоны могут создаваться даже при межмашинном обмене данными или без выполнения пользователем определенных действий, например во время перезагрузки, если устройство получает доступ к характерному набору услуг.

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

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

2.7. Дополнительная информация

Полезную справочную информацию также можно найти в [tor-leak] (о риске утечки конфиденциальности через DNS) и в нескольких научных статьях: [yanbin-tsudik], [castillo-garcia], [fangming-hori-sakurai], и [federrath-fuchs-herrmann-piosecny].

3. Актуальные «Атаки»

Очень быстрая проверка трафика DNS может привести к неверному выводу, что извлечь иголку из стога сена сложно. «Интересные» первичные DNS-запросы смешиваются с бесполезными (для перехватчика) вторичными и третичными запросами (см. Терминологию в разделе 1). Но в настоящее время обработки «больших данных» существуют мощные методы, позволяющие получить от необработанных данных то, чем на самом деле интересуется перехватчик.

Многие исследовательские работы по обнаружению вредоносных программ используют DNS-трафик для обнаружения «ненормального» поведения, которое можно проследить до активности вредоносных программ на зараженных машинах. Да, это исследование было сделано хорошо, но технически это атака на конфиденциальность, которая демонстрирует силу наблюдения за трафиком DNS. См. [Dns-footprint], [dagon-malware] и [darkreading-dns].

Пассивные DNS-системы [passive-dns] позволяют реконструировать данные иногда целой зоны. Они используются по многим причинам — некоторые хорошие, некоторые плохие. Известные пассивные системы DNS хранят только ответы DNS, а не IP-адрес источника клиента, именно из соображений конфиденциальности. Другие пассивные системы DNS могут быть не такими осторожными. И все еще есть потенциальные проблемы с раскрытием QNAME.

Раскрытие (из документов Эдварда Сноудена, которые были просочены из Агентства национальной безопасности (АНБ)) программы наблюдения MORECOWBELL [morecowbell], которая использует DNS, как пассивно, так и активно, для скрытного сбора информации о пользователях, является еще одним хорошим примером, показывающим, что отсутствие защиты конфиденциальности в DNS активно эксплуатируется.

4. Законность

Насколько нам известно, ни в одной стране нет конкретных законов о конфиденциальности для данных DNS. Интерпретация общих законов о конфиденциальности, таких как [директива о защите данных] (Европейский союз), в контексте данных о трафике DNS — непростая задача, и мы не знаем судебного прецедента. Смотрите интересный анализ в [sidn-entrada].

5. Вопросы безопасности

Этот документ полностью о безопасности, точнее о конфиденциальности. Это просто излагает проблему; он не пытается устанавливать требования (с учетом выбора и компромиссов), а тем более определять решения. Возможные решения проблем, описанных здесь, обсуждаются в других документах (в настоящее время слишком много, чтобы их можно было упомянуть); см., например, [QNAME-MINIMIZATION] для минимизации данных или [TLS-FOR-DNS] о шифровании.

6. Ссылки

6.1. Нормативные ссылки

[RFC1034] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.

[RFC1035] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.

[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, «Privacy Considerations for Internet Protocols», RFC 6973, DOI 10.17487/RFC6973, July 2013,
<http://www.rfc-editor.org/info/rfc6973>.

[RFC7258] Farrell, S. and H. Tschofenig, «Pervasive Monitoring Is an Attack», BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <http://www.rfc-editor.org/info/rfc7258>.

6.2. Информационные ссылки

[aeris-dns] Vinot, N., «Vie privee: et le DNS alors?», (In French), 2015, <https://blog.imirhil.fr/vie-privee-et-le-dns-alors.html>.

[castillo-garcia] Castillo-Perez, S. and J. Garcia-Alfaro, «Anonymous Resolution of DNS Queries», 2008,
<http://deic.uab.es/~joaquin/papers/is08.pdf>.

[CLIENT-SUBNET] Contavalli, C., Gaast, W., Lawrence, D., and W. Kumari, «Client Subnet in DNS Queries», Work in Progress, draft-ietf-dnsop-edns-client-subnet-02, July 2015.

[dagon-malware] Dagon, D., «Corrupted DNS Resolution Paths: The Rise of a Malicious Resolution Authority», ISC/OARC Workshop, 2007,
<https://www.dns-oarc.net/files/workshop-2007/Dagon-Resolution-corruption.pdf>.

[DANE-OPENPGPKEY] Wouters, P., «Using DANE to Associate OpenPGP public keys with email addresses», Work in Progress, draft-ietf-dane-openpgpkey-03, April 2015.

[darkreading-dns] Lemos, R., «Got Malware? Three Signs Revealed In DNS Traffic», InformationWeek Dark Reading, May 2013, <http://www.darkreading.com/analytics/security-monitoring/got-malware-three-signs-revealed-in-dns-traffic/d/d-id/1139680>.

[data-protection-directive] European Parliament, «Directive 95/46/EC of the European Pariament and of the council on the protection of individuals with regard to the processing of personal data and on the free movement of such data», Official Journal L 281, pp. 0031 — 0050, November 1995,
<http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML>.

[day-at-root] Castro, S., Wessels, D., Fomenkov, M., and K. Claffy, «A Day at the Root of the Internet», ACM SIGCOMM Computer Communication Review, Vol. 38, Number 5, DOI
10.1145/1452335.1452341, October 2008,
<http://www.sigcomm.org/sites/default/files/ccr/papers/2008/October/1452335-1452341.pdf>.

[denis-edns-client-subnet] Denis, F., «Security and privacy issues of edns-clientsubnet», August 2013, <https://00f.net/2013/08/07/edns-client-subnet/>.

[ditl] CAIDA, «A Day in the Life of the Internet (DITL)», 2002, <http://www.caida.org/projects/ditl/>.

[dns-footprint] Stoner, E., «DNS Footprint of Malware», OARC Workshop, October 2010, <https://www.dns-oarc.net/files/workshop-201010/OARC-ers-20101012.pdf>.

[DNS-TERMS] Hoffman, P., Sullivan, A., and K. Fujiwara, «DNS Terminology», Work in Progress, draft-ietf-dnsop-dns-terminology-03, June 2015.

[dnschanger] Wikipedia, «DNSChanger», October 2013, <https://en.wikipedia.org/w/index.php?title=DNSChanger&oldid=578749672>.

[dnsmezzo] Bortzmeyer, S., «DNSmezzo», 2009, <http://www.dnsmezzo.net/>.

[fangming-hori-sakurai] Fangming, Z., Hori, Y., and K. Sakurai, «Analysis of Privacy Disclosure in DNS Query», 2007 International Conference on Multimedia and Ubiquitous Engineering (MUE 2007), Seoul, Korea, ISBN: 0-7695-2777-9, pp. 952-957, DOI 10.1109/MUE.2007.84, April 2007,
<http://dl.acm.org/citation.cfm?id=1262690.1262986>.

[federrath-fuchs-herrmann-piosecny] Federrath, H., Fuchs, K., Herrmann, D., and C. Piosecny, «Privacy-Preserving DNS: Analysis of Broadcast, Range
Queries and Mix-based Protection Methods», Computer Security ESORICS 2011, Springer, page(s) 665-683, ISBN 978-3-642-23821-5, 2011,
<https://svs.informatik.uni-hamburg.de/publications/2011/2011-09-14_FFHP_PrivacyPreservingDNS_ESORICS2011.pdf>.

[grangeia.snooping] Grangeia, L., «DNS Cache Snooping or Snooping the Cache for Fun and Profit», February 2004,
<http://www.msit2005.mut.ac.th/msit_media/1_2551/nete4630/materials/20080718130017Hc.pdf>.

[herrmann-reidentification] Herrmann, D., Gerber, C., Banse, C., and H. Federrath, «Analyzing Characteristic Host Access Patterns for Re-Identification of Web User Sessions»,
DOI 10.1007/978-3-642-27937-9_10, 2012,
<http://epub.uni-regensburg.de/21103/1/Paper_PUL_nordsec_published.pdf>.

[morecowbell] Grothoff, C., Wachs, M., Ermert, M., and J. Appelbaum, «NSA’s MORECOWBELL: Knell for DNS», GNUnet e.V., January 2015, <https://gnunet.org/morecowbell>.
[packetq] Dot SE, «PacketQ, a simple tool to make SQL-queries against PCAP-files», 2011,
<https://github.com/dotse/packetq/wiki>.

[packetq-list] PacketQ, «PacketQ Mailing List», <http://lists.iis.se/mailman/listinfo/packetq>.

[passive-dns] Weimer, F., «Passive DNS Replication», April 2005, <http://www.enyo.de/fw/software/dnslogger/#2>.

[prism] Wikipedia, «PRISM (surveillance program)», July 2015, <https://en.wikipedia.org/w/index.php?title=PRISM_(surveillance_program)&oldid=673789455>.

[QNAME-MINIMIZATION] Bortzmeyer, S., «DNS query name minimisation to improve privacy», Work in Progress, draft-ietf-dnsop-qname-minimisation-04, June 2015.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «DNS Security Introduction and Requirements», RFC 4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>.

[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, «DNS Security (DNSSEC) Hashed Authenticated Denial of Existence», RFC 5155, DOI 10.17487/RFC5155, March 2008,
<http://www.rfc-editor.org/info/rfc5155>.

[RFC5936] Lewis, E. and A. Hoenes, Ed., «DNS Zone Transfer Protocol (AXFR)», RFC 5936, DOI 10.17487/RFC5936, June 2010,
<http://www.rfc-editor.org/info/rfc5936>.

[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, «Issues with IP Address Sharing», RFC 6269, DOI 10.17487/RFC6269, June 2011,
<http://www.rfc-editor.org/info/rfc6269>.

[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., Trammell, B., Huitema, C., and D. Borkmann, «Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement», RFC 7624, DOI 10.17487/RFC7624, August 2015,
<http://www.rfc-editor.org/info/rfc7624>.

[ripe-atlas-turkey] Aben, E., «A RIPE Atlas View of Internet Meddling in Turkey», March 2014,
<https://labs.ripe.net/Members/emileaben/a-ripe-atlas-view-of-internet-meddling-in-turkey>.

[sidn-entrada] Hesselman, C., Jansen, J., Wullink, M., Vink, K., and M. Simon, «A privacy framework for ’DNS big data’ applications», November 2014,
<https://www.sidnlabs.nl/uploads/tx_sidnpublications/SIDN_Labs_Privacyraamwerk_Position_Paper_V1.4_ENG.pdf>.

[thomas-ditl-tcp] Thomas, M. and D. Wessels, «An Analysis of TCP Traffic in Root Server DITL Data», DNS-OARC 2014 Fall Workshop,
October 2014, <https://indico.dns-oarc.net/event/20/session/2/contribution/15/material/slides/1.pdf>.

[TLS-FOR-DNS] Zi, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, «TLS for DNS: Initiation and Performance
Considerations», Work in Progress, draft-ietf-dprivestart-tls-for-dns-01, July 2015.

[tor-leak] Tor, «DNS leaks in Tor», 2013,
<https://www.torproject.org/docs/faq.html.en#WarningsAboutSOCKSandDNSInformationLeaks>.

[yanbin-tsudik] Yanbin, L. and G. Tsudik, «Towards Plugging Privacy Leaks in the Domain Name System», October 2009,
<http://arxiv.org/abs/0910.2472>.

Благодарности

Спасибо Натали Бульвар и членам CENTR за оригинальную работу, которая привела к созданию этого документа. Спасибо Ondrej Sury за интересные обсуждения. Спасибо Мохсену Суисси и Джону Хайдеманну за корректуру, а также Полу Хоффману, Маттис Меккинг, Маркосу Сансу, Тиму Вицински, Фрэнсису Дюпону, Эллисон Мэнкин и Уоррену Кумари за корректуру, предоставлению технических замечаний и множеству улучшений читаемости. Благодарю Дэна Йорка, Сюзанну Вульф, Тони Финча, Стивена Фаррелла, Питера Коха, Саймона Йозефссона и Фрэнка Дениса за хороший письменный вклад. И спасибо членам IESG за последние замечания.

Адрес автора

Stephane Bortzmeyer
AFNIC
1, rue Stephenson
Montigny-le-Bretonneux 78180
France
Phone: +33 1 39 30 83 46
Email: bortzmeyer+ietf@nic.fr
URI: http://www.afnic.fr/