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

Делегирован домен .СРБ – это ещё один “нелатинский” домен верхнего уровня. При этом, в отличие от .РФ, состоит из трёх букв, включая одну “специфическую” – Б. Домен, понятно, для Сербии. Пример адреса сайта: њњњ.срб. Развивается система имён. Ещё лет десять назад такой вариант развития мало кому мог бы показаться вероятным. Хотя, идеи о нелатинских именах тогда уже сформировались.

И, кстати, строго говоря, это не второй кириллический домен, а третий. Потому что первым был .ИСПЫТАНИЕ.

Потихоньку развиваю nox.su (это иллюстрация использования DNSSEC, которую я планирую показывать на семинарах по теме): дополнил описание, поменял ключи (теперь два ZSK, как положено), опубликовал файлы зон (исходный и с подписями). Как и раньше, все доступно на сайте.

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

Напомню предысторию: в декабре 2011 года могло произойти массовое удаление доменов .РФ, зарегистрированных в первые дни свободной регистрации (с 11.11.2010); однако удаление доменов было заморожено 8 декабря и возобновилось только 29 декабря. Удаление теперь проводится по новой процедуре, в рамках которой ограничено число имён, удаляемых ежесуточно.

Так, из доменов .РФ, скопившихся в очереди на удаление, за каждую итерацию (то есть, за одни сутки, по рабочим дням) удаляют 10000. То же самое и с доменами .RU, но мы сейчас следим за .РФ. В результате кириллическая зона сдувается, но не так быстро – масса доменов, регистрацию которых не продлевают, размазана по времени. Типичный отрицательный прирост – около 8 тыс. доменов в сутки. Но не забывайте, что удаление производится только по рабочим дням (да и то, были пропуски). В числах это выглядит примерно так (данные stat.nic.ru): 29 декабря, когда удаление возобновили, в зоне .РФ было 954013 имён, по состоянию на 17 января осталось 912707; итого: -41306 доменов. Для сравнения, в домене .RU за тот же период – напротив, прирост +7415 имён.

В общем, пока что кириллическая доменная зона теряет численность. Если бы ограничений на удаление не вводили, то спад был бы очень резким, сейчас он размыт, но всё равно хорошо заметен. Прогнозы относительно итогового числа доменов, на которое уменьшится зона .РФ, есть разные, они начинаются от оптимистичных 100000 имён. Процесс удаления сойдётся где-то весной, тогда и сравним показатели.

Так как домен nox.su успешно подписан (DNSSEC), то делаю под ним информационную страничку о том, как, собственно, эта DNSSEC для конкретного домена устроена. Пока что там очень краткое описание (но с картинкой уже!), детализацию постепенно увеличу. Получается пример внедрения, да.

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

Самая занятная особенность использования QR-кодов вместе с Интернетом – в идеальной “геолокационной” функции. Изображения, размещаемые в офлайне, могут содержать уникальные коды. Разместивший знает, где именно какой код он оставил. А использование встроенной в смартфон камеры для распознавания изображения практически гарантирует, что пользователь, только что обратившийся по данной ссылке к веб-серверу, находится рядом с картинкой. Наклейка на столике в кафе “Лютик”? Будьте уверены, что пользователь – за этим столиком. Очень точная система. Не использует GPS и тому подобных штук, которые могут быть пользователем отключены.

Да, конечно, можно придумать несколько исключений: сохранил картинку, вышел из кафе, спустился в метро – только тут прочитал код. Но это далеко от реальных привычек массового пользователя.

Получается, потребитель QR-кода ничего не знает о том, что стоит за кодом. Человек даже не в состоянии прочесть этот код самостоятельно, без использования электронного устройства (сравните с “текстовым” URL). А вот владелец сервера, на который приходит браузер смартфона (мобильного устройства), напротив, обладает как минимум следующей информацией: некий IP-адрес, связанный с устройством (определяет оператора, провайдера, дополнительный источник данных о местоположении); тип устройства; тип ПО на этом устройстве, сведения о браузере; ну и весьма точные данные о местоположении пользователя в данный момент. Удобно, полезно.

По традиции, о капчах. На форуме RU-CENTER мы довольно давно сделали особую геометрическую капчу, но, вроде бы, я про неё не писал раньше. Пример этой капчи:

Капча многослойная. Например, до сих пор приходят сообщения, что там ошибка в тексте описания. Но никаких ошибок нет, просто текст описания является неотъемлемой частью капчи. Основная особенность этой капчи в том, что она отсекает “биороботов”.

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

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

В продолжение записки от 11.11.11 про освобождение доменов .РФ: удаление доменов из реестра до сих пор не производится, а приостановлено оно было 08.12.11, то есть, как раз накануне массового освобождения. Сейчас заморожено удаление и .ru, и .рф, так как оператор реестра у этих доменов общий. Новые домены регистрируются, поэтому зоны растут. Естественно, растёт и очередь на удаление. По правилам регистрации домены должны удаляться из реестра через, примерно, 30 дней после окончания срока регистрации. Ситуация довольно занятная. Когда начнётся удаление и какова будет его процедура – пока не ясно. (Вообще, сейчас понятно только то, что раз предыдущее техническое решение привело к приостановке удаления, то новое решение должно от него как-то отличаться. То есть, и результаты могут быть другими. Посмотрим.)

Занятно: браузер Chrome в Рунете выбрался в лидеры, LiveInternet насчитали аж 18.6% (первое место). Судя по графикам, Chrome вытесняет IE. Как и предполагали ещё в прошлом году, одна из причин в отсутствии внятного браузера от Microsoft под Windows XP: IE9 там не работает. Но это только одна из причин, да.

Спустя примерно месяц, я вновь собрал SSL-сертификаты с серверов, на которые указывают домены .ru. Методика описана в прошлой записке по этой теме. Кратко повторю основные моменты: на первом этапе делается попытка определить адрес сервера (A-запись) для каждого из делегированных доменов (учитывая www.) в зоне .ru; из найденных серверов с уникальными IP выбираются те, у которых открыт 443-й порт (https); на заключительном этапе каждый из отобранных серверов опрашиваются на предмет SSL-сертификатов путём открытия https-сессии; собранные сертификаты разбираются при помощи OpenSSL.

В результатах “много цифр”, поэтому прячу под “Читать полностью”.

Читать полностью

Записка про DNSSEC в реальности Интернета получила хорошее продолжение.

Благодаря поддержке RU-CENTER, – персональное спасибо Павлу Ильичеву, – содействию ФРИ (Фонд Развития Интернет – администратор домена SU) и ТЦИ (Технический Центр Интернет – оператор реестра), домен nox.su, который я привожу в пример в прошлой записке по теме, подписан по всем правилам. Cоответствующая DS-запись внесена в зону .su без проблем. (Для того, чтобы посмотреть на результат, можно воспользоваться всё тем же инструментом от VeriSign.)

Так что технология DNSSEC в домене с особым статусом SU начала разворачиваться на практике. Это хорошо. Насколько я понимаю, nox.su стал первым подписанным доменом второго уровня в .su. Зато теперь не нужно перебираться в .org с экспериментами: .su, при всех особенностях, вполне себе российский домен.

В корневой зоне 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. Нужно же посмотреть, что нас ждёт в ближайшем будущем.