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

Координационный и технический центры российских национальных доменов готовятся к введению DNSSEC в .ru – это основной домен из трёх (su, рф, ru). Вот, пишут, что сгенерировали ключи и положили их на изолированный компьютер (air gap, да). Подписать .ru обещали до конца этого года. Так что можно, в принципе, готовить серверы и свои зоны. (Я dxdt.ru уже подписал; вот значение для DS – 12E833887648F73B80E06CC86252E025FFE5F75F.)

Тут спрашивают, достаточно ли устроить DNS-резолвер на собственном сервере или использовать сервис наподобие Google Public DNS, чтобы меньше беспокоиться о подмене ответов DNS (которые могут увести куда угодно)? Нет, не достаточно. Ключевой момент тут в IP-адресах. Предположим, что у вас настроен в качестве резолвера собственный сервер (пусть это будет BIND), доступный по IP-адресу 1.2.3.4. Откуда ваша локальная операционная система знает, что, отправляя запросы и получая ответы от 1.2.3.4, – она “разговаривает” именно с нужным резолвером?

Если в качестве точки перехвата трафика используются ближайший к вашему узлу шлюз, то очень легко сделать так, что по адресу 1.2.3.4 будет отвечать какой угодно подставной сервер. Посудите сами: сейчас даже новомодные точки доступа WiFi используют такую технологию, чтобы вместо нужного сайта показывать в браузере собственную страницу с сообщением об “ошибке соединения”, если там, например, кабель выпал (делать так, конечно, форменное безобразие). То же нередко реализуют интернет-провайдеры. Технология простая: маршрутизатор, вместо того, чтобы отправить пакеты в Интернет, перенаправляет их внутреннему узлу. Так что на запрос к 8.8.8.8 (гугловский DNS) может поступить самый неожиданный ответ: mail.google.com = 192.168.1.1. Более того, благодаря возможностям по спуфингу, существующим в типичной локальной сети, перехватить трафик может не только маршрутизатор. Ну и существует ещё несколько способов, позволяющих подставить другой сервер вместо вашего резолвера. Что, кстати, напоминает ситуацию со спуфингом GPS. (Как страшно жить.)

Возвращаемся к DNS. Что делать? А просто не нужно забывать об аутентификации. Так, если вы используете свой резловер без VPN, то потребуется настроить TSIG – то есть, подписывание запросов и ответов клиентом и сервером, стандартный механизм при обмене файлами зон.

Я делаю так: на локальной машине в качестве резолвера поднят BIND с поддержкой TSIG, для него в качестве “форвардера” настроен сервер резолвера – в файле конфигурации named.conf директива forwarders:

forwarders {
1.2.3.4;
};

(1.2.3.4 – IP-адрес резолвера).

Для удостоверения сообщений требуется общий секретный ключ. Его можно сгенерировать утилитой dnssec-keygen, входящей в пакет BIND9:

$ dnssec-keygen -a HMAC-MD5 -b 128 -n HOST megakey

(пояснения к параметрам: тип алгоритма HMAC-MD5, 128-бит, ключ для хоста).

Результатом работы является пара файлов, примерно с такими именами: Kmegakey.+157+14629.key и Kmegakey.+157+14629.private. Значение ключа, в виде строки Base64, можно взять из .private. Ключ, понятно, секретный.

Теперь в конфигурацию обоих BIND-ов, на клиенте, и на сервере, нужно добавить записи о ключе и директивы, предписывающие этот ключ использовать. Самый правильный способ: ключи вынести в отдельный файл, защитить его правами доступа, а в конфигурацию добавить с помощью include. Что, кстати, на отдельном виртуальном сервере может оказаться избыточным.

Описание ключа, для speckey.conf.key или прямо для named.conf:

key “resolver-key” {

};

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

Назначение ключа узлу (серверу), в named.conf, ничего секретного в строке нет:

server 1.2.3.4 {

};
};

Здесь 1.2.3.4 – адреса узлов: на клиенте – серверный адрес, на сервере – клиентский.

Собственно, это всё (после настройки нужно перезапустить BIND): при попытке подмены или перехвата ответов – получаем сообщение об ошибке, не более того.

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

Технология под названием DANE (DNS-Based Authentication of Named Entities) позволяет размещать в DNS информацию, идентифицирующую заданные элементы криптосистем, используемых различными сервисами в Интернете. DANE распространяет удостоверяющие свойства DNSSEC на другие протоколы, тем самым сильно расширяя возможности и область применения DNSSEC.

Например, используя DANE можно разместить в DNS специальные записи, привязывающие определённый SSL-сертификат к веб-серверу, отвечающему под соответствующим доменом. Программы-клиенты (браузеры), обращающиеся к веб-серсверу, смогут проверить валидность сертификата средствами DNSSEC. Что, потенциально, приводит имеющуюся инфраструктуру к схеме с единым корнем. Или, по крайней мере, позволяет владельцу домена как-то бороться с “левыми” сертификатами, которые могут быть выпущены для его домена: запись в DNS точно указывает на то, какие именно сертификаты браузер должен принимать для данного веб-сайта. Естественно, DANE касается не только HTTPS (TLS), пример работы с которым я приведу ниже, но и распространяется на другие протоколы.

Пока что DANE находится в разработке, которая, надо заметить, идёт неплохо: примерно за год активной деятельности рабочей группы соответствующий RFC уже добрался до завершающей стадии подготовки. Тем не менее, говорить о какой-то поддержке приложениями пока что рано, протокол всё ещё экспериментальный, его ключевые особенности могут измениться. Кроме того, требуется продвижение идеи в пользовательские браузеры.

В качестве тестовой площадки я сделал https://dane.nox.su/ – понятно, что заходить туда имеет смысл только по https. Более того, приготовьтесь увидеть предупреждение системы безопасности браузера. Подробности – ниже.

Как это работает? Основной момент в том, что информация об открытом ключе SSL-сертификата вносится в подписанную зону DNS. В случае с dane.nox.su – с этим проблем нет, так как зона nox.su поддерживает DNSSEC. Веб-сервер dane.nox.su использует самоподписанный SSL-сертификат. Это сделано специально, так как одной из интересных особенностей DANE является то, что этот новый инструмент, благодаря DNSSEC, позволяет превратить самоподписанный (бесплатный, заметьте) сертификат во вполне сносный механизм аутентификации веб-сайта. Хотя, на практике лучше использовать не самоподписанный, а полноценный сертификат – с ним DANE, понятно, также совместим.

Процедура настройки DANE для TLS довольно проста. Я опущу описание процесса генерации SSL-сертификата, предположим, что он уже есть и установлен. Требуется добавить в зону DNS запись особого вида, содержащую отпечаток (хеш) открытого ключа сертификата. Используем SHA-256 (один из вариантов, указанных в RFC). Прежде всего, отпечаток нужно получить:

$ openssl x509 -noout -fingerprint -sha256 -in yourcert.crt

– здесь yourcert.crt – файл с вашим сертификатом.

Вообще, для использования в DNS, значение SHA-256 потребуется в записи без двоеточий, так что лучше сразу сказать как-то так:

$ openssl x509 -noout -fingerprint -sha256 -in nox.su.self.crt | perl -ne ‘s/://g; print $_’

Результат примерно такой (для сертификата dane.nox.su):

SHA256 Fingerprint =
12B1BC2AF0D87C6E0E259CE364CE6921
B74F0C748328C4A33A11F19467700EB2

(Как вариант: отпечаток ключа можно подсмотреть браузером, открыв ваш сайт и заглянув в окно со свойствами SSL-сертификата.)

Запись DNS выглядит, соответственно, так (для dane.nox.su):

_443._tcp.dane.nox.su. IN TYPE65468 \# 35
( 03000112B1BC2AF0D87C6E0E259CE364CE6921
B74F0C748328C4A33A11F19467700EB2 )

Думаю, нетрудно догадаться, что имя построено из номера порта, типа протокола и хоста: TCP и 443 – это стандартный транспорт HTTPS. Тип TYPE65468 – это временный тип записи, выделенный для тестирования DANE. Собcтвенно, сейчас IANA уже выделила “нормальный” тип – TLSA (52). Но с TLSA пока что удобства ещё меньше.

Значение: тут к отпечатку, в качестве префикса, добавлено три байта (октета), со значениями 03,01,01. Это, в порядке следования:

* метод использования сертификата – 3 – обозначает, что сертификат не должен проверяться по цепочке доверия (PKIX) браузера, а только сверятся с отпечатком в DNS; подходит для самоподписанного сертификата; другие варианты предусматривают проверку цепочки внутри иерархии подписей;

* проверяемая часть сертификата – 1 – проверятся отпечаток открытого ключа; 0 – проверяется отпечаток всего сертификата;

* тип хеш-функции – 1 – SHA-256; тут всё понятно.

То есть, значение записи строится так: {метод}{часть}{тип-хеша}{значение-хеша} – просто и прозрачно. Извлечь тестовую запись, вместе с подписью, из DNS можно попробовать такой командой:

$ dig +dnssec -t TYPE65468 _443._tcp.dane.nox.su

После того, как запись успешно размещена в зоне и зона подписана – всё готово для использования DANE.

Тут и кроется основная практическая трудность (или, скажем так, засада): поддержки DANE пока нет. Из того, что мне удалось обнаружить: плагин для Firefox Extended DNSSEC Validator, альфа-версия. В принципе, Chrome должен поддерживать DANE, но, на правах первопроходца, он делает это в манере, отличающейся от описанной в текущем RFC (который, напомню, черновик). Для того, чтобы заработал Chrome, требуется другая запись в DNS и специальное поле в сертификате. Поэтому, в случае с dane.nox.su, Chrome выдаёт предупреждение о “плохом” сертификате. Надеюсь, что по мере развития технологии, всё нормализуется и будет один стандарт.

Спрашивают в комментариях к записке об использовании открытых и “чужих” сетей – зачем нужен собственный резолвер DNS, налаженный внутри VPN?

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

Понятно, что в случае с собственным VPN-соединением, запущенным через “чужую” сеть, определять адреса серверов может всё тот же провайдерский резолвер. В конце концов, через VPN ходит TCP/IP, а не символьные имена доменов. После того, как резолвер определил IP-адрес сервера, соединение будет устанавливаться уже через VPN.

Но, как вы понимаете, паранойя встречается разных типов и масштабов, а резолвер провайдера как раз и используется для того, чтобы осуществлять подмену адресов страниц. Ведь именно при помощи подстановки “кривого” адреса в ответ на запрос о любом домене происходит переадресация браузера на замечательные страницы с предложением приобрести ту или иную услугу, с напоминанием о том, что на счёте мало денег, и так далее, и тому подобное. “Чужой” резолвер ставит крест на всех полезностях VPN, если, конечно, вы планируете использовать DNS. (Кроме того, если вы настроили локальную маршрутизацию таким образом, что весь трафик ходит через VPN, может возникнуть проблема: резолвер владельца сети не станет обслуживать запросы, поступающие с вашего компьютера, потому что они будут приходить извне – со стороны шлюза VPN.)

Другое решение – держать рекурсивный резолвер локально, на своём ноутбуке. Я не уверен, может ли это делать Windows (наверное, может), но с юниксоподобными системами проблем нет, достаточно поднять локальный BIND. Трафик резолвера нужно завернуть в VPN, это обеспечит секретность. (Тут есть подводный камень: использование NAT, – а трафик из VPN во внешний мир может выходить именно через NAT, – грозит тем, что испортится один из защитных механизмов DNS, который называется “рандомизация портов UPD на источнике запроса”; но это другая история.) А главный недостаток один: нужно на каждом клиенте VPN держать свой рекурсивный резолвер. Неудобно. Поэтому куда более логично разместить собственный резловер на сервере, обеспечивающем VPN. Всё равно этот сервер работает постоянно.

А кроме того, редкий провайдерский резолвер поддерживает DNSSEC. Я таких вообще не видел.

(И, хорошо, можно использовать открытые сервисы, наподобие Google public DNS, но это всё ж не то решение, которое сравнится с собственным резолвером. При этом гугловский сервис быстрее. В моём случае – заметно быстрее.)

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

К сожалению, в домене ru DNSSEC появится неизвестно когда, но точно нескоро. Другой российский (по факту) домен – su, – хоть и заявлен недавно на конференции ICANN как поддерживающий DNSSEC, на практике, насколько я смог выяснить, не позволяет воспользоваться защитными механизмами. Записи об su в корне DNS подписаны, но в самой этой зоне мне не удалось найти ни одного подписанного домена второго уровня. Более того, не подписан даже домен администратора SU – fid.su. Для рядового же пользователя проблема в том, что, на практике, отсутствует механизм “привязки” подписанной зоны второго уровня к ключам домена SU.

(Addon (17/11/11): как пишут из ТЦИ, реестр SU поддерживает работу с DNSSEC, но регистраторы пока не реализовали свою часть. Ждём.)

Вообще, подписать саму зону можно не прибегая к услугам администратора домена верхнего уровня (см., например, nox.su, который я подписал в порядке эксперимента – сами записи в зоне подписаны, но цепочка рвётся в .su, разместить там нужные данные сейчас не представляется возможным). “Привязка” доменов к единой цепочке выполняется с помощью специальных DS-записей (Delegation signer), вносимых в зону, уровнем выше удостоверяемой, для построения иерархии, ведущей к корневому ключу (кстати, опубликованному на сайте IANA). Если делать всё добротно, то данные DS-записей для подписывания должны передаваться минуя DNS, по другим каналам, подразумевающим некоторую аутентификацию отправителя – иначе теряется большая часть смысла в развёртывании DNSSEC. Стандартный путь проходит через регистраторов доменов.

Итак, для получения работающей конфигурации пришлось dxdt.ru и nox.su предпочесть домен tooktook.org, так как зона .org корректно подписана и размещение DS-записей в ней поддерживается крупными регистраторами (я воспользовался GoDaddy).

Функционирование каждого домена обеспечивают серверы имён (NS). Для tooktook.org я взял пару серверов с BIND 9.7.3 (это известная реализация DNS-сервера), который полностью поддерживает DNSSEC. На сайте ISC есть подборка инструкций по настройке DNSSEC в BIND-е. Я не стану приводить подробных деталей, потому что это будет офтопик, на мой взгляд (если что, то пишите вопросы в комментарии). Сам процесс создания подписанной зоны DNS несложен, и сводится к генерации нескольких ключей (закрытых и открытых), с последующим удостоверением с их помощью записей в файле зоны. В пакете с BIND есть все утилиты: dnssec-keygen, dnssec-signzone и т.п. То есть, на входе у вас текстовый файл зоны без подписей, на выходе – текстовый файл зоны, но уже с дополнительными записями (RRSIG, DNSKEY), содержащими подписи и открытые ключи для их проверки.

После того, как зона подписана, генерируем DS-запись (записи), содержащую значение хеш-функции от открытой части ключа (KSK), с помощью которого подписан ключ (ZSK), удостоверяющий записи в зоне. (Пара ключей используется для удобства их ротации и оптимизации процедуры подписывания зоны. И, да, можно сгенерировать DS-запись до подписывания зоны.) В случае с доменом tooktook.org я без каких-то трудностей разместил DS-запись при помощи клиентского веб-интерфейса GoDaddy. На удивление, весь процесс – генерация подписанной зоны, размещение записей, – занял примерно 20 минут, включая ожидание обновления информации в DNS.

Теперь tooktook.org подписан (проверить можно с помощью веб-интерфейса от VeriSign). Зачем? Следующий шаг – проверка на практике технологии, дополняющей, с помощью DNSSEC, механизмы использования SSL-сертификатов в браузерах и уже поддерживаемой в Chrome. Нужно же посмотреть, что нас ждёт в ближайшем будущем.

Не так давно я писал про удостоверение SSL-сертификатов с помощью DNSSEC. Оказывается, как мне подсказывают, подобная функциональность уже включена в рабочий Chrome 14, примерно пару недель назад. В общем, процесс движется быстро. Интересно, кто успеет запрыгнуть в вагон?

История с чередой “поломок” удостоверяющих центров, выдающих SSL-сертификаты, наводит на довольно логичный вывод: коммерческую систему “управления доверием” могут очень сильно перекроить. Потому что момент подходящий.

Вообще, иерархия удостоверяющих центров в реализации браузерных криптографических схем с SSL вводится при помощи одного вроде бы простого утверждения: обязательно требуется механизм, позволяющий проводить идентификацию предъявителей сертификатов с помощью “третьей стороны”. Напомню простой пример: кто-то предъявляет браузеру SSL-сертификат, выпущенный для домена test.ru – откуда браузер знает, что этот кто-то действительно имеет отношение к test.ru? Выпустить самоподписанный сертификат для test.ru может кто угодно.

Страшилка: этот “кто угодно” может вмешаться в канал связи и выдать себя за владельца test.ru. Неожиданным образом, этот момент лежит в основе продаж SSL-сертификатов. Предлагается поступать так: пользователь выбирает некую доверенную организацию, которая проверяет, что предъявитель сертификата действительно представляет test.ru; теперь пользователь принимает только те сертификаты для test.ru, которые подписаны доверенной организацией. Вроде бы, все довольны.

Но в реальности – проблемы. Например, оказалось, что эти самые “доверенные организации” могут подписать что угодно. Либо в результате взлома, это как раз основа нынешней шумихи, либо вполне себе осознанно, скажем, действуя в рамках сотрудничества с производителями систем мониторинга трафика. Самое занятное, что ни пользователь браузера, ни тот, кто приобретает SSL-сертификат, не могут повлиять на ситуацию и как-то предотвратить подобное использование имеющейся инфраструктуры: в браузеры встроены десятки “корней” удостоверяющих центров (УЦ), каждый из них технически может подписать любую ерунду. Выходит, что для пользователей и потребителей SSL-сертификатов от коммерческих УЦ заявленный механизм идентификации не факт, что работает. (Да, понятно, что можно возразить: нет, работает! Но плана для проверки всё равно не реализовано.)

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

Естественно, описанные трудности SSL касаются только имеющейся практической реализации. Если у вас есть возможность пользоваться действительно добротными услугами по идентификации от “третьей стороны”, то полученная схема, надстроенная поверх непрерывного контроля подлинности при помощи уникальных отпечатков (см. предыдущий абзац), оказывается весьма сильной защитой.

И вот тут появляется DNS и DNSSEC. В DNS единый корень. Как раз доменное имя (читай – инфраструктура DNS) позволяет типичному пользователю установить “первый контакт” с неизвестным ему ранее сайтом. DNSSEC, понятно, также содержит единый корень и подписать “что попало” – не выйдет, так как доменные имена должны быть уникальны. С чисто технической точки зрения с помощью DNSSEC можно удостоверить не только адресную информацию, но и дополнительные сведения, например, указать, какие именно сертификаты – или, что конкретнее, криптографические ключи, – может использовать сайт под данным доменом. Заметьте, существующая иерархия УЦ здесь уже не нужна!

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

Так что шумиха раскручена не просто так. Наверняка готовятся очень интересные перемены.

Дополнение: да, понятно, что при условии изменения порядка и появления у DNSSEC новой роли, корректирующей судьбу SSL, к бизнесу по “управлению доверием” прямо подключаются регистраторы доменов.

В ночь с 15 на 16 июля корневую зону DNS подписали настоящим ключом и опубликовали открытые ключи для проверки подписей DNSSEC. Таким образом, Минторг США, компания VeriSign и ICANN завершили развёртывание DNSSEC в корневой зоне. Собственно, теперь DNSSEC можно использовать в глобальной DNS. Ключи каждый может взять на сайте IANA.

Теперь поддержку DNSSEC начнут массово вводить в доменах первого уровня.

Напомню, что следующие шаги на пути к новому Интернету – внедрение IPv6 и модернизация принципов маршрутизации (через внедрение криптографических механизмов).

На фоне озвучиваемых в СМИ планов по созданию новых государственных сервисов в национальном кириллическом домене интересно взглянуть на адресацию в Интернете с точки зрения “главных рубильников”.

Понятно, что всякий интернет-сервис намертво привязан к двум фундаментальным штукам: DNS (то есть, имена доменов) и IP (то есть, сами адреса, по которым доставляются пакеты данных). В этом кроется принципиальное отличие интернет-среды от, скажем, радиоэфира.

Радиоэфир общий по своей физической сути. Есть международные соглашения, регулирующие использование спектра частот. Но, по большому счёту, если вдруг очень сильно потребуется организовать вещание на той или иной частоте, то ни у одной международной (или просто коммерческой) организации не найдётся средств, чтобы технически вещание полностью заблокировать. Да, можно ставить помеху, блокируя приём передач в некотором кусочке пространства. Можно, в общем, вести РЭБ. Но просто взять, нажать кнопку, и отключить доступ к частоте для всех слушателей и для вещателя – такого, очевидно, нельзя сделать.

Совсем другое дело – системы интернет-адресации. Здесь есть главные рубильники, и главные кнопки, которые позволяют очень быстро отключить частоту. Самый простой пример – удаление домена из файла зоны. Удалить можно не только домен второго уровня, но и домен первого уровня. В результате все сайты из него станут недоступны. Так как опрос DNS всегда начинается с корневых серверов, то внесение изменений в корневую зону позволяет не только отключить любой домен первого уровня, но и, например, перенаправить трафик внутри этого домена на другие адреса. Конечно, требуется административный доступ к корневой зоне DNS.

Посмотрим на сценарий с DNS чуть более детально. Предположим, что кому-то требуется перехватить управление некоторым национальным доменом. Адресация в национальном домене глобально определяется серверами имён, которые указаны для него в корневой зоне. Первый путь для перехвата: изменяется запись в корне, новая версия указывает на другие сервера имён. Часто можно услышать, что корневую зону поддерживает большое число корневых серверов (их – 13), узлы которых распределены по всему миру и находятся под управлением разных компаний. Это так. Но файл корневой зоны все эти серверы получают из одного источника, со скрытого сервера, управляемого компанией VeriSign. Соответственно, если изменить адреса в исходном файле, то при очередном обновлении изменения распространятся на все экземпляры корневой зоны.

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

Понятно, что на новых серверах домена верхнего уровня может быть прописана совсем другая адресация. Но можно и сохранить имевшуюся на момент перехвата управления. Для этого потребуется заблаговременно получить файл зоны с действующих серверов имён. Этот файл содержит все записи о доменах уровнем ниже. Разместив на новых серверах имён копию старого файла зоны, можно замаскировать перехват: для пользователей ничего не изменится. (Конечно, файл зоны может быть “засекречен”, но, на уровне положения администраторов корня DNS, такой расклад выглядит непрактичным: ну реально ж попросить свежую копию заранее.)

Забрав управление доменом описанном незаметном режиме, новый администратор может переадресовать только какие-то ключевые сайты, оставив основную часть адресных настроек без изменений. Этот способ особенно хорош в том случае, если новый администратор не желает, чтобы под удар попали лояльные к нему интернет-сервисы: ведь понятно, что если “снести” домен полностью, то недоступными окажутся все ресурсы сразу; копирование установленной адресации – сильно смягчает ситуацию для рядовых пользователей. (Да, старые администраторы не смогут менять настройки доменов и т.п., и т.д. но это не так страшно.)

Заметьте, что изменение DNS коснётся и электронной почты в домене. Она начнёт ходить “не туда”.

Вывод: в отличие от, например, радиоэфира, получается, что в Интернете не только можно отключить “главным рубильником” вещателей и слушателей, но и избирательно подменить вещателей (скорректировав адресные записи для выбранных доменов второго уровня). Все изменения делаются центрально и сразу во всём виртуальном пространстве. Никакой “РЭБ” вести невозможно, а главный тот, у кого рубильник.

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

(А при этом IP-адреса корневых серверов зашиты в системном программном обеспечении. Изменить их можно, но только в ручном режиме, при условии, тысячи системных администраторов будут действовать согласованно.)

Да, конечно, всё это теоретические сценарии. Но интересные. Так что, думаю, в следующих записках разбор темы можно продолжить. Тем более, что актуальность Интернета у нас растёт семимильными шагами.

На 16 июня ICANN назначена первая церемония генерации ключа для DNSSEC. Пишут, что церемония займёт около шести часов, участие принимает группа доверенных представителей (это персоны, которые держат части секретных данных, определяющих криптографический процесс генерирования ключа). “Главный ключ” нужен для подписывания ключа Verisign, которым, в свою очередь, будет подписана сама корневая зона.

Между прочим, если посмотреть на положение дел с литературной точки зрения, то выходит, что ICANN придумала интересный мистический ритуал. С одной стороны, он напрямую связан с глобальной Сетью. С другой – с криптографией. Проводится ритуал в особом культовом здании: безопасном дата-центре. (Вообще, таких центров два – для резервирования; во втором центре церемония намечена на июль.) В общем, всё это важный признак нового Интернета.

Как сообщают, сегодня последний из корневых серверов DNS (J) перевели на DNSSEC (прогресс – здесь). То есть, с пятого мая все корневые серверы отдают подписанную зону. На этом, правда, процесс развёртывания DNSSEC не закончен. Сейчас зону специально “подписывают” с помощью “кривого” ключа, так, чтобы нельзя было проверить данные. Часто спрашивают – для чего это сделано? А для того, чтобы можно было с минимальными проблемами откатить всё обратно, если вдруг DNSSEC приведёт к краху DNS.

Объяснение разработчиков процедуры – такое: использование кривого ключа гарантирует, что особенно продвинутые участники глобальной Сети не перейдут на полную поддержку DNSSEC раньше времени. Действительно, с “кривым” ключом использовать DNSSEC на практике смысла нет, поэтому клиенты не станут массово и полностью внедрять поддержку новой технологии, так как они не смогут в таком случае работать с DNS. А вот если бы корневую зону подписывали сразу проверяемым образом, то откат оказался бы очень проблемным делом: те, кто перешли на DNSSEC уже не смогли бы работать с Сетью, если бы поддержку DNSSEC отключили.