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

Начался приём работ на конкурс WebHiTech-2012. В этом году заявки принимаются по новой схеме, качество каждой оценивается жюри уже на этапе отбора. Подать заявку можно на сайте конкурса.

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

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

Вышел из печати новый номер журнала “Доменные имена”. Этот выпуск рассказывает про историю Интернета (кстати, есть и про телеграфы). Отдельно рекомендую статью “Сценарии конца Интернета”, очень в тему. Журнал будет распространяться на РИФе, а после РИФа – в офисах RU-CENTER, и на профильных мероприятиях.

Как известно, почтовые серверы, принимающие почту для адресов заданного домена, обозначаются при помощи MX-записей. Я собрал значения этих записей со всех делегированных и доступных в DNS доменов .RU (по состоянию на 15.04.12). Собственно, интересно было посмотреть, как используются сервисы для доменов от “Яндекса” и Google (с хостерами и так всё ясно).

Итак, “Яндекс” (“Почта для домена”) предлагает установить в качестве значения MX-записи – mx.yandex.ru. То есть, можно предположить, что если у домена такая MX-запись, то, с большой вероятностью, этот домен используется для яндексовского почтового сервиса. Таких доменов удалось обнаружить 96201.

Google для своих Google Apps предлагает список из пяти почтовых серверов, все они встречаются сравнимое число раз, я взял в качестве показателя самый приоритетный (и самый распространённый) – aspmx.l.google.com. Такую запись удалось обнаружить для 97226 доменов.

То есть, примерно поровну. И примерно 96201+97226=193427 доменов второго уровня .ru используют сервисы электронной почты от поисковых систем. Впрочем, это всего лишь ~5% от общего числа зарегистрированных доменов. Мало. Понятно, что подсчёт MX-записей даёт несколько размытую картину, так как администраторы доменов нередко настраивают DNS с ошибками. Но, тем не менее, показатели информативные.

Дефект (скорее, уязвимость) в интерфейсе приёма заявок на New gTLD ICANN признала 12 апреля, хотя, подтверждают, что сообщения о проблемах от пользователей поступали с 19 марта. Сегодня – 14 апреля, и пока что ICANN, в своём стиле, только обещает 16 апреля сообщить о том, смогут ли они возобновить приём заявок 17 апреля.

Вчитайтесь: через двое суток после аварии, ICANN, на полном серьёзе, выпускает официальное сообщение о том, что ещё через два дня опубликуют очередное сообщение, в котором будет уведомление о поступлении следующего сообщения. Это рафинированный образец бюрократии в действии.

New gTLD – очень шумное начинание. Одно из самых шумных с момента создания ICANN. Понятно, что сломать, в принципе, могут всё что угодно. Но, в случае с закрытым сервисом ICANN, списывать очки на этот бесспорный момент – очень непросто. Кроме того, не факт, что там была какая-то сложная и серьёзная причина для сбоя, вполне вероятно, что просто тривиальная ошибка программиста, вылезшая в “боевой” продукт по причине отсутствия аудита качества.

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

Впрочем, посмотрим, как оно повернётся.

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

Заметьте, космические ракеты на регулярной основе успешно запускают уже больше 50 лет, но до сих пор данная технология не каждому государству доступна. При этом, если говорить о Штатах, то недалёк тот день, когда там коммерческие компании, а не государство, смогут осуществлять регулярную доставку грузов на околоземную орбиту. И это, между прочим, отличный пример того, как в современном мире корпорации соотносятся с государствами.

(Северокорейская ракета “Ынха-3” развалилась в воздухе 13 апреля 2012 года. И, вероятно, развалилась она самостоятельно, без внешнего воздействия. Хотя, кто знает?)

Конкурс WebHiTech в 2012 году планируем проводить в новом формате. Старт приёма заявок – на РИФе, некоторые подробности – в официальном сообщении.

Ещё немного Интернета. Вот “Битрикс” с шумом запускает проект bitrix24.ru. Конечно, “облачный”. Позиционируют как корпоративный интранет. Естественно, всякое у них написано про то, как обеспечивают безопасность, что, мол, только по https, все дела. Цитата с сайта: “Безопасность вашей информации превыше всего!”. И, без сомнения, для корпоративного интранета безопасность действительно важна. Особенно, если какая-то компания удумает держать интранет в “облаке”, под “Битриксом”. Судя по всему, вертится проект на амазоновском EC2.

Но я о другом. Идём на https://bitrix24.ru/ и – любуемся на кривой самоподписанный сертификат, который отдаёт нам сервер:

Issuer: E = test@email.address; CN = Bitrix; OU = Bitrix R&D; O = Bitrix; L = Kaliningrad; ST = Moscow; C = RU;
Subject: E = test@email.address; CN = Bitrix; OU = Bitrix R&D; O = Bitrix; L = Kaliningrad; ST = Moscow; C = RU;

Тот же сертификат отдаёт www1.bitrix24.ru. При этом у проекта есть сертификат для *.bitrix24.ru – его отдают другие их веб-серверы.

А благодаря смелым настройкам DNS “Битрикс24”, можно открывать “сайт” под любым выдуманным (несуществующим) адресом третьего уровня внутри bitrix24.ru, например, http://alskdjfhg.bitrix24.ru/, и наблюдать страницу-заглушку, которая, судя по тексту, обозначает временную недоступность сервиса в целом. Поведение, очевидно, совершенно некорректное. (Update, 22.06.12: поведение исправили, показывают страницу “Несуществующий домен”.) Проявив чуть больше смекалки, и попробовав адреса уровнем ниже третьего (a.b.c.bitrix24.ru), повторно наблюдаем кривое использование SSL-сертификата, но теперь уже в случае с сертификатом для *.bitrix24.ru, который, вообще-то, при правильном применении, вполне себе валидный (выдан Go Daddy CA).

И это, наверняка, не все проколы. Ну и вот как тут можно говорить про безопасность корпоративного интранета в подобном “облаке”, которое разработчики не сумели настроить?

Дополнение (13.04.12): не менее показательно, что в разделе “Безопасность – техническим специалистам” на сайте написано буквально следующее (цитата): “на уровне операционной системы веб-серверов «Битрикс24» через сетевой экран закрыт внешний доступ по все портам, кроме 443”; но при этом нетрудно убедиться, что их веб-сервер охотно отвечает на 80 порту (301 Moved Permanently), перенаправляя на тот же IP, но на 443 порт. Понятно, что иначе и быть не может – пользователи не умеют https набирать.

Во как: у ICANN сломалась (сломали?) система приёма заявок на новые домены верхнего уровня. Сегодня последний день приёма таких заявок, но, понятно, срок продлили.

12 апреля. Картинка:

(via.)