Приватность DNS

Джефф Хьюстон

Джефф Хьюстон

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

Протокол трансляции имен DNS (Domain Name System) пришел к нам еще из тех времен, когда в Интернете царило взаимное доверие, а не нынешняя атмосфера всеобщей подозрительности. DNS – протокол открытый, и свои данные он рассылает направо и налево. Но эти данные – не просто абстрактные непонятные циферки. Запросы и ответы DNS содержат доменные имена для всего, что пользователи делают в Интернете: доменное имя каждого URL, каждой почты, каждого расположения, к которому обращает­ся пользователь. Этот поток данных синхронизирован с действиями пользователей. Практически каждой сетевой транзакции предшествует вызов DNS. Поэтому неудивительно, что в наши дни DNS широко исполь­зуется для незаявленных целей. Сейчас DNS – не только привычный нам всем протокол трансляции имен, который опрашивает огромную распределенную базу данных, но и потенциальный канал для слежки, а кроме того, способ реализации самых разнообразных способов контроля доступа к контенту в общедоступной сети.
Ситуация с DNS должна измениться. Теперь, когда файлы Сноудена наглядно показали нам, какой мас­штаб принимают подобные системы слежки – как на службе правительств, так и мотивированные коммерчески, – мы воочию увидели, что многие привычные нам инструменты Интер­нета слишком доверчивы, слишком болтливы и слишком легко обходятся умным противником. И первым в этой коллекции уязвимых инструментов будет DNS.
Запросы к системе доменных имен предшествуют практически каждой интернет-транзакции. Жур­нал моих запросов DNS в плане содержащейся в нем информации, пожалуй, эквивалентен тому, чем был для предыдущего поколения список набранных телефонных номеров. Пусть журнал транзакций DNS и не содержит информацию о конкретных действиях в сети, но в нем регистрируется то, к каким сайтам я обращался – а зачастую этого достаточно, чтобы создать весьма точный профиль того, чем конкретно мы занимаемся в Интернете. Нередко отмечают, что метаданные такого вида даже полезнее для различных видов анализа, поскольку не загромождены описаниями отдельных действий.
Не только спецслужбы полюбили стоять у нас за плечом и подсма­тривать, что происходит на наших экранах. Появилось множество продуктов и услуг, нацеленных на индивидуального пользователя и стремящихся построить всеобъ­емлющий профиль его желаний и потребностей. Хэл Вариан (Hal Varian), главный экономист Google, однажды заметил, что надоедливую рекламу отличает от своевременной подсказки лишь уровень точности и актуальности данных о пользователе. Потому неудивительно, что многие компании строят подобные профили для своей клиентской базы просто по работе. Дошло до того, что во многих случаях на стоимость чистых активов компании больше влияет не ценность и прибыльность ее продуктов и услуг, а масштаб собранной клиентской базы, ее общая покупательная способность и точность информации о ней. И с этой точки зрения поток запросов DNS – настоящий Клондайк.
DNS – находка для шпиона
DNS невероятно болтлив, и доступ к его данным может получить букваль­но кто попало!
Чтобы преобразовать новое имя, например, www.example.com, резолвер DNS сначала запрашивает IP-адрес имени www.example.com у корневых серверов имен. Очевидно, корневой сервер не может ответить на этот запрос, поэтому он в ответ выдает список серверов имен, ответственных за домен .com. Затем резолвер снова отправляет запрос IP-адреса для имени www.example.com, на этот раз серверу имен .com – и снова получает непрямой ответ, означающий, что сам сервер не знает адреса, но за адреса домена example.com отвечают такие-то и такие-то серверы имен, и адресовать запрос нужно им. Теперь резолвер может направить тот же самый запрос серверу, отвечающему за домен example.com – и, возможно, наконец-то получит от него в ответ адрес www.example.com. Но у этой горы запросов есть и неприятный побочный эффект. Корневой сервер имен, сервер имен .com и сервер example.com теперь знают, что меня интересует имя www.example.com, и они наверняка ведут журнал подобных запросов. Откуда мне знать, обще­доступен он или закрыт? Кто и как анализирует журнал, какие выводы делают из этих данных? Нет ответа.

А может быть, ситуация еще хуже: ведь приложение, с которым я рабо­таю, например, браузер, как правило не выполняет трансляцию имен DNS само. Оно для этого обращается к операционной системе, например в форме запроса gethostbyname(). А ведь ОС тоже может вести журнал подобных запросов. Получается, что мой браузер и моя ОС осведомлены о моих действиях. Платформа операционной системы, как правило, не содержит автономного резолвера DNS, а настроена на вызов удаленного резолвера. Обычно такой рекурсивный резолвер предоставляется интер­нет-провайдером. Все это хорошо и замечательно, но, выходит, мой провайдер тоже знает всю мою историю обращений к DNS.
Дальше – больше. Провайдер, чтобы не связываться с поддержкой полномасштабного сервера DNS, может транслировать запросы другому рекурсивному резолверу, т.е. еще одной стороне. Как правило, подобные пересылки влекут за собой потерю атрибуции, так как пересылаемые запросы не содержат моих идентифи­кационных данных. Но если резолвер использует опцию EDNS0 Client Subnet (RFC 7871), тогда пересылаемые запросы сохраняют ряд важных данных о моей локальной сети.
Из этого примера видно, что о моем интересе к сайту www.example.com узнает множество посторонних лиц.
Все эти запросы DNS – огромная куча данных даже по меркам нынешнего информационного века. Еще в апреле 2015 года Google сообщил, что его серверы DNS выдают около 400 миллиардов ответов в сутки, а по другим сведениям, Google обраба­тывает примерно 12% общей нагрузки DNS. Получается, что на тот момент в мире генерировалось порядка трех триллионов запросов DNS. С тех пор эта цифра точно не стала меньше.
Мало того, что DNS беспардонно делится информацией о действиях пользователя с кем попало – он еще и передает ее открыто. Запросы DNS и ответы на них не шифруются, просто сидят на порту 53 для UDP и TCP. Запросы DNS легко можно перехватить, а если не используется DNSSEC – и подсунуть в поток данных фальшивые ответы, а клиент ничего не заметит. В некоторых странах перехват и подмена DNS уже стали обычным делом. Другие обратились к перехвату и блокировке DNS, пытаясь решить проблемы, связанные с перегрузкой IP-адресов при виртуальном веб-хо­стинге.
Можно ли «научить» DNS здоровой осторожности?
В последние годы IETF, наконец, заня­лась приватностью DNS, и появились предложения по его доработке, с тем чтобы лишить шпионов и цензоров всех мастей их любимого инструмента. Рассмотрим эти инициативы подроб­нее.

Минимизация QNAME
В рабочей группе DNS Operations возникло предложение минимизиро­вать имена запросов DNS, в результате чего появилась спецификация QNAME Minimisation (RFC 7816, март 2016 г.). В этом документе говорится: «Минимизация QNAME исходит из того принципа, что чем меньше рассылается данных, тем меньше возникает проблем с их утечкой» – на мой взгляд, более чем разумная позиция.
В вышеприведенном примере запрос к корневым серверам для получения IP-адреса www.example.com содержит два лишних элемента информации, а именно полное доменное имя и тип запроса. Разумнее и безопаснее было бы запросить у корневых серверов имен записи NS для домена .com, не делясь информацией, которая корневым серверам вообще не нужна. Аналогично, у серверов имен .com лучше было бы запрашивать список серверов имен для домена example. com и так далее (см. рис. 1).
Минимизация QNAME в плане эффективности ничем не хуже передачи полного имени запроса, да и возможность использовать кэшированные данные не страдает. Она выявила ряд несоответствий при обработке т.н. пустых нетерминальных доменных имен (empty non-terminal domain names), но сам подход реа­лизуется надежно и станет хорошим шагом к тому, чтобы положить конец разбазариванию информации. Никаких изменений на серверах DNS не требуется, а любой резолвер, реализующий этот метод, предоставит своим пользователям преимущества защиты их данных.
Одними из первых резолверов DNS, реализовавших минимизацию QNAME, стали Knot DNS Resolver, разработан­ный CZNIC , и Unbound  (начиная с версии 1.5.7, хотя, как я понял, в реализации преобразователя Unbound минимизация QNAME по умолчанию отключена).
DNS по безопасному каналу
Минимизация имен запросов DNS решит лишь часть проблем – ведь в DNS вообще ничего не шифруется. Благодаря такой открытости DNS, прослушивать, перехватывать и подменять его данные невероятно просто. Этой проблемой занимается рабочая группа DPRIVE  в составе IETF, пытаясь найти способы защитить обмен запросами и ответами DNS между клиентом и резолвером.
Здесь главная проблема – обе­спечить безопасность протокола преобразования имен DNS. Причем для обеспечения безопасности нужно решить две задачи. Во-первых, требуется защитить транзакции DNS от прослушивания, т.е. зашифровать трафик DNS. А во-вторых, клиенты DNS должны отправлять запросы только своему резолверу DNS и проверять, что полученный ответ действительно пришел от нужного резолвера. Таким образом клиент сможет удостове­риться в подлинности транзакции DNS, а попытки перехвата будут для него легко различимы.
DNS поверх TLS
У нас уже есть сеансовый сервис общего назначения, способный обеспечить такую безопасность на уровне сеанса, а именно протокол TLS (Transport Layer Security). TLS вырос из более раннего протокола SSL (Secure Socket Layer), разработанного Netscape в 90-е годы.
Надо признать, что сочетание TLS и DNS в одной фразе вызывает довольно бурную реакцию в сообществе DNS. По вопросу использования TCP вместо UDP в качестве основного транспортного протокола для DNS, а не резервного варианта для больших ответов, было сломано множество копий. Утверждалось, что усилия по поддержке соединения TCP значительно затруднят для сервера обработку больших объемов запросов, а дополнительная задержка на первоначальное «рукопожатие» негативно отразится на пользователе. Другая сторона оперировала следу­ющими аргументами: «Веб и так уже используется, в основном, как служба коротких транзакций, и веб-серверы неплохо справляются с подобной нагрузкой. Кроме того, применение TCP – эффективное лекарство от различных злоупотреблений, эксплуа­тирующих уязвимость UDP к спуфингу исходных адресов».
Спецификация DNS поверх TLS (RFC 7858, май 2016 г.) довольно проста: транспортная служба, обеспечиваемая TLS, фактически та же, что и у TCP, с тем отличием, что порт прослушива­ния на сервере – TCP 853, а не 443.

Недостатком TLS является необ­ходимость выполнить трехэтапное «рукопожатие» TCP для создания сеанса, а затем передачу аутентифи­кационных данных TLS для создания защищенного сеанса. В TLS 1.2 это означает, что перед тем как запрос клиента поступит на сервер, должно пройти три интервала передачи данных с клиента на сервер и обратно (Round Trip Time, RTT). В более новой версии TLS 1.3 планируется улучшить положение, избавившись от одной RTT, но все равно это будет куда медлен­нее UDP и, скорее всего, увеличит нагрузку на серверы DNS за счет необходимости поддерживать сеансы.
Есть, однако, одно изменение, которое позволило бы устранить существенную, если не большую часть дополнительной нагрузки – вариант с повторным использованием сеансов TLS. В спецификации DNS поверх TLS предлагается именно это: «Чтобы свести к минимуму задержку, клиен­там СЛЕДУЕТ направлять несколько запросов в сеансе TLS конвейерно». Для обмена данными между кли­ентом и рекурсивным резолвером повторное использование сеанса имеет смысл, но при обмене данными между авторитетным сервером имен и клиентом, который сам выполняет преобразование DNS, это может быть малореально.
Также интересно предложение использовать выделенный порт TCP. Если надо замаскировать шифро­ванный трафик DNS и затруднить блокировщикам его обнаружение, то напрашивается вариант пустить DNS поверх TLS через порт 443 (по крайней мере, я бы так и сделал!). А зашифро­ванный трафик через ничем больше не занятый порт TCP просто кричит: «Вот он я, блокируй – не хочу!» – и тог­да будет гораздо легче заставить вас отказаться от шифрования DNS. Куда логичнее пустить безопасный трафик DNS через активно используемый порт TCP 443, где его будет значительно труднее выделить.
В ближайшие месяцы DNS поверх TLS будет реализован для устройств Android, так что можно ожидать некоторого повышения приватности DNS в этом аспекте.
Узнать больше о нынешнем состоянии клиентов и серверов, поддерживающих DNS поверх TLS, можно по адресу https://dnsprivacy. org/wiki/display/DP/DNS+Privacy+Imple mentation+Status.
Проблема этого варианта в том, что хотя обмен данными между тупиковым резолвером и выбранным рекурсивным резолвером шифруется, ваш рекурсивный резолвер все равно оказывается в курсе всего, что вы делаете по DNS. От атак на канал это защитит, но что касается ситуации на другом конце канала, тут остается только уповать на порядочность и квалификацию хозяев сервера.
DNS поверх DTLS
TCP не всегда будет оптимальным способом создать безопасный канал для DNS. TCP пытается доставлять данные последовательно, а в приложении, ориентированном на сообщения, потеря сообщения в TCP задержит доставку всех последующих до тех пор, пока TCP не исправит потерю данных и не передаст пропав­шее сообщение. Эта особенность TCP может привести к неприемлемому возрастанию нагрузки при передаче сообщений по типу датаграмм: одна потеря, как вредный или нерастороп­ный покупатель, будет задерживать всю очередь. Для защиты приложений на основе UDP лучшим вариантом мог бы оказаться IPSEC, но IPSEC – функция ядра, а не модуль прикладного уровня, и его семантика применяется на уровне IP, а не в качестве атрибута транспортного протокола. Это затруд­няет реализацию IPSEC в приложениях и развертывание криптографических функций в пространстве пользователя.
Альтернативный вариант защиты транспорта DNS – внедрение безопас­ного уровня сеанса в среду передачи датаграмм. На этом и построен новый протокол DTLS, представляющий собой адаптацию функции TLS, которая может обеспечить прило­жению функцию доставки по типу датаграмм, не требующую надежного транспортного сервиса. DTLS может восстанавливать потерю пакетов и выполнять переупорядочение, но нетерпим к фрагментации пакетов UDP. Он построен по образцу TLS 1.2 и пытается немного снизить негативное воздействие от использования TLS на качество работы DNS, особенно по сравнению с вариантом «DNS поверх TLS поверх TCP». Главное отличие – необходимость первоначального рукопожатия DTLS для того, чтобы создать общее состояние шифрования, и применение файлов cookie, чтобы повторно использовать это состояние на протяжении нескольких отдельных взаимодействий «запрос-ответ».
Применение DNS в его нынешнем варианте поверх UDP отличается тем, что накладные расходы на обслу­живание общего состояния нагружают каждую отдельную транзакцию по минимуму, в результате чего сервис оказывается очень надежным и оперативным. DNS поверх DTLS пытается, насколько воз­можно, сохранить эту простую модель обмена датаграммами «запрос-от­вет», но при этом сделать так, чтобы клиент использовал шифрование, основанное на предложенных серве­ром и проверенных сертификатах (RFC 8094, февраль 2017 г.).

DTLS нетерпим к фрагментации IP, поэтому реализация DNS поверх DTLS по структуре своей сходна с исполь­зованием флага TC в реализации DNS поверх UDP: если размер ответа превосходит MTU маршрута, то сервер должен выдать сокращенный ответ и установить флаг TC, чтобы просигна­лизировать клиенту о необходимости повторить запрос по TCP. Цель такого поведения в случае DTLS в следую­щем: если сервер DNS поверх DTLS выдает ответ длиннее, чем оценка MTU локального маршрута, то сервер должен в ответе установить флаг TC, а клиент интерпретирует это как инструкцию повторить запрос по DNS поверх TLS.
Спецификация DTLS содержит любопытную оговорку: «Это решение DTLS рабочая группа DPRIVE сочла подходящим вариантом для использования в случае, если метод на основе TLS, описанный в RFC7858, обнаружит проблемы при внедрении. На момент написания спецификации ожидается, что RFC7858 будет внедрен, а потому настоящая специ­фикация задумана, главным образом, как резервная».
Похоже, сами разработчики не очень-то верят в DTLS: разумно сделать вывод, что на сей момент интерес к DNS поверх DTLS невелик, и специфи­кация DTLS разработана, скорее, не для широкомасштаб­ного применения, а в качестве формальности.
«Минимизация QNAME исходит из того принципа, что чем меньше рассылается данных, тем меньше возникает проблем с их утечкой» – на мой взгляд, более чем разумная позиция.
Безопасный DNS поверх JSON
И DNS поверх TLS, и DNS поверх DTLS просто заменяют транспортный протокол, никак не трогая формат запросов и ответов. Но, разумеется, никто не объявлял формат DNS неприкасаемым, а потому есть и другие методики, основанные на новом представлении запросов и ответов DNS.
Сервер по адресу https://dns. google.com выполняет функцию трансляции поверх TLS через порт 443, передавая результаты в формате структур данных JavaScript Object Notation ( JSON). Эту реализацию легко превратить в альтернативную форму gethostbyname() для приложения, заменяя обычный запрос DNS выборкой веб-объекта. Преимуществом для вызывающего станет некий уровень защиты от прослушивания третьими сторонами, потенциального вторжения и цензуры… хотя непонятно, о какой «защите» может идти речь, если вы оповещаете о своих действиях DNS-серверы Google!
Однако, чтобы проиллюстрировать, как приложение может использовать такой сервис непосредственно, обходя перехват как со стороны платформы, так и локального DNS, приведу пример скрипта Python, который устанавлива­ет безопасный сеанс с этим сервисом Google: 
Этот метод может оказаться полезным, так как опасения об утечке данных DNS нельзя ограничивать только внешними формами слежки и перехвата. «Адекватно осторожное» приложение не будет использовать службу трансляции имен DNS, предоставленную платформой, поскольку тогда запросы DNS прило­жения попадут в неконтролируемую среду, где могут регистрироваться платформой и другими приложени­ями. В этом случае приложение не выполняет трансляцию DNS и проверку DNS само: оно использует безопасный канал связи со службой трансляции имен Google по соединению TLS. Приложение может быть в некоторой степени уверено в том, что не допускает локальной утечки данных DNS, и что (при включенной проверке DNSSEC) получаемые ответы с известной степенью надежности достоверны, при условии, что само преобразуемое имя подписано по DNSSEC.
Отправка запросов по безопасному каналу на очень загруженный рекур­сивный резолвер – а вряд ли найдется резолвер более загруженный, чем общедоступный DNS-сервер Google – имеет еще и то преимущество, что ваши запросы могут затеряться в горе кэшированной информации и тем избежать обнаружения. Если вы не против того, чтобы оповещать Google о своих запросах DNS, то довольно разумно использовать безопасный доступ к рекурсивному DNS-резо­лверу, который стремится к точности, целостности и полноте в выполнении своих задач. Такой безопасный канал гораздо труднее обойти и прослушать поток запросов.
Если же такой вариант вас не устраивает, есть и другой: вернуть трансляцию имен на свою платформу или даже в приложение, используя такие инструменты, как GetDNS. Здесь, правда, возникнет другая проблема: да, вы не доверяете чужому рекурсивному резолверу и ваши запросы напрямую передаются на ответственные серверы имен, но зато вы опять используете незашифрованный DNS – а к тому же теряете преимущество в быст­родействии из-за общего кэша DNS. Возможно, лучше использовать безопасный канал к рекурсивному преобразователю, которому вы доверяете, но выполнять проверку DNSSEC самостоятельно.
DNS поверх HTTPS
Теперь мы можем обратиться к стандартизационной работе в IETF, где рабочая группа DOH пытается стандартизировать DNS поверх HTTPS. В уставе этой рабочей группы записано: «Данная рабочая группа стандартизирует шифрование для запросов и ответов DNS, пригодное для использования в HTTPS. Это позволит системе доменных имен функционировать на некоторых марш­рутах, где существующие методы DNS (UDP, TLS [RFC 7857 ] и DTLS [RFC 8094]) столкнулись с проблемами. Данная рабочая группа будет в максимально возможной степени повторно исполь­зовать методы, коды ошибок и прочую семантику HTTPS. Применение HTTPS и его существующего PKI обеспечивает целостность и конфиденциальность, а также взаимодействие с общей инфраструктурой и политиками HTTPS».

Какой метод используется здесь?
Новые метки URI для различных схем именования URI сейчас не в моде, и работа DOH не стала исключением. Вместо того, чтобы повторно задей­ствовать префикс «dns:», рабочая группа использует популярный в наше время механизм, а именно хорошо известный URI-путь «.well-known/ dns-query». В этой схеме запрос DNS может выглядеть так:

В этой методологии используется существующий двоичный формат DNS по проводу с применением типа данных MIME «application/dns-udpwireformat». При использовании метода GET запрос DNS шифруется по Base64, в то время как метод POST помещает двоичный запрос DNS в тело HTTP-объекта, к которому применяется POST, как в примере выше.
Надо сказать, я не слишком понимаю, в чем тут выгода. Дополнительная оболочка HTTP не добавляет практически ничего, кроме ненужных украшательств – и никаких преиму­ществ, кроме демонстрации ловкости рук, я тут не вижу! Если все, что нам надо – это упрятать запросы DNS в зашифрованный канал, то в HTTPS этим занимается тот же TLS, а ком­понент HTTP лишь усложняет задачу. Так может, просто использовать DNS поверх TLS?

Что дальше?
Мы затронули не все аспекты приват­ности DNS.
Например, есть еще и возможность паддинга (заполнение пустыми данны­ми) пакетов. Даже если содержимое DNS передается по зашифрованному сеансу, есть возможность установить факт обмена данными DNS по размеру пакетов запроса и ответа DNS. Если блокировать такой зашифрованный трафик DNS, то пользователи будут вынуждены передавать данные DNS открыто и подставляться под DNS-ата­ки. С этим пытается бороться паддинг DNS (RFC7830, май 2016 г.): можно увеличивать размер запросов и ответов DNS, добивая их переменным количеством байтов, чтобы нельзя было отлавливать зашифрованный трафик по длине. Однако, хотя эта спецификация описывает, как добав­лять мусорное содержимое, она не рекомендует никакой конкретной политики паддинга. Этой темой сейчас занимается IETF, и рабочая группа DRPIVE вырабатывает новую специфи­кацию, ориентированную на политики (текущий рабочий документ носит имя draft-ietf-dprive-padding-policy), чтобы дать полезные рекомендации в части политик паддинга, которые пригодятся клиентам DNS.
Еще один аспект, заслуживающий рассмотрения, это взаимодействие между рекурсивным резолвером и авторитетным сервером имен. До сих пор основные усилия по защите передачи DNS были сосредоточены на канале, ведущем от оконечного клиен­та к рекурсивному резолверу, а ведь канал от преобразователя к серверу имен не лишен тех же самых проблем. Недавно в этой сфере появились под­вижки (рабочий документ носит имя draft-bortzmeyer-dprive-resolver-to-auth-00): предлагается использовать DANE и возложить на DNS публикацию открытого ключа сервера для запросов DNS поверх TLS. Работа находится еще на ранней стадии и наверняка будет переделываться, но выглядит эта идея достойно.
Паддинг может устранить некоторые очевидные паттерны трафика DNS, которые не сможет скрыть шифро­вание, но остается еще проблема времени передачи пакетов: оно тоже демаскирует обмен данными DNS. Ведутся разговоры о том, не стоит ли добавлять пакеты-«пустышки» в потоки запросов и ответов, чтобы лучше замаскировать паттерны коммуникации DNS. Пока неясно, что из этого получится, но если ответом на шифрование сеансов DNS действительно станет блокировка шифрованного трафика DNS, то идея добротной маскировки этого трафика наберет популярность среди пользо­вателей.
Состояние дел с приватностью DNS
Да, в наши дни открытость DNS невероятно облегчает его прослушку, перехват и подмену данных; но отчаиваться рано – прилагается много усилий к тому, чтобы создать среду DNS, которая защищала бы конфиден­циальность и целостность данных.
Минимизация имен запросов позво­лит значительно сократить уровень утечки информации DNS. А передача запросов и ответов DNS по безопас­ному каналу затруднит посторонним лицам прослушку и перехват пакетов DNS в пути.

Если приложения начнут использо­вать сервисы, которые инкапсулируют локальный трафик запросов DNS в зашифрованных сеансах TLS, то значи­тельная часть данных DNS, доступных сегодня любому желающему, просто исчезнет из поля зрения. Более того, нынешняя практика выборочной локальной инспекции и вмешатель­ства в процесс преобразования имен DNS станет гораздо более трудной, если вообще возможной.
Если вдобавок ко всему этому еще и широко распространится DNSSEC, облик Интернета существенно изме­нится. Само собой, попытки цензуры Интернета никуда не денутся – равно как и практика мониторинга и слежки в сети. Но если все мы решим всерьез заняться приватностью и безопасно­стью DNS, он перестанет быть тем, чем является сейчас – исключительно простым и дешевым инструментом для этих неблаговидных целей.
Источник: DNS privacy, Geoff Huston