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

Как известно, почтовые серверы, принимающие почту для адресов заданного домена, обозначаются при помощи 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.)

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

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

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

Можно предложить такую схему: жук достаточно автономен и не нуждается в большом числе команд, поступающих в режиме реального времени; а небольшой набор “медленных” управляющих сигналов может передаваться в защищённом режиме (размазываем по времени и частотам) и восстанавливаться, вычисляться, на борту, при помощи накопления энергии сигнала. Равно та же методика хорошо работает для GPS-приёмников.

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

Google показывает очки “дополненной реальности”. А между прочим, ценность интерактивных очков, позволяющих просматривать дополнительную информацию в интегрированном с “основной” картинкой реальности виде, теряется, если эти очки служат лишь интерфейсом для смартфона. “Дополненние реальности” уведомлениями об SMS – это не то, что хотелось бы получить. Это лишь избыточный, маркетинговый “функционал”.

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

Хотя, наверное, как товар от Google – очки с “эсэмэсками” должны пойти хорошо. Тем более, что туда же можно транслировать указания вида “купи вот эту куртку”.

Продолжаем неделю интернет-адресации на dxdt.ru. Я подумал, что данные по адресации внутри домена .ru, которые я извлекаю из DNS для того, чтобы собирать SSL-сертификаты с работающих веб-сайтов, довольно занятны сами по себе. В общем, сделал такой вот сервис: http://adr.dxdt.ru/ – он позволяет получить список доменов, а вернее, имён хостов, которые соответствуют заданному IP-адресу. Работает только для .ru. И не в режиме онлайн. Запросы можно делать простым GET-ом, формат описан на странице сервиса: там вообще только Apache, это такой очень простой сервис.

(Интересности: есть немало имён с адресом 1.1.1.1 или с адресом 0.0.0.0; само собой, распространен 127.0.0.1.)

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

Поделюсь ссылкой, пожалуй. Прибавляется число локальных узлов одного из корневых серверов:

RU-CENTER и ICANN реализовали совместный проект по инсталляции российского узла сервера L-Root.

Addon (05/04/2012): а вот и сообщение на сайте ICANN.

Вообще, локальных узлов корневых серверов много, адресуются они, обычно, с помощью anycast. То есть, обращаясь к тому или иному серверу по одному и тому же IP-адресу, но из разных сегментов Сети, вы будете попадать на наиболее “близкий” физический сервер. Расстояние тут измеряется в терминах топологии Интернета, конечно. Примерно так результат для l.root-servers.net теперь выглядит “с близкого расстояния”, из московского дата-центра:

$ traceroute l.root-servers.net
traceroute to l.root-servers.net (199.7.83.42), 30 hops max, 60 byte packets
1 MSK-KHOUSE-NR1.nic.ru (109.70.27.19) 0.772 ms 1.111 ms 1.245 ms
2 MSK-STD-NR1.nic.ru (193.232.147.215) 1.348 ms 1.351 ms 1.458 ms
3 l.root-servers.net (199.7.83.42) 1.226 ms 1.223 ms 1.213 ms

А вот вариант из Ирландии (Amazon, кусочек):

$ traceroute l.root-servers.net
traceroute to l.root-servers.net (199.7.83.42), 30 hops max, 60 byte packets
[…]
4 ec2-79-125-0-135.eu-west-1.compute.amazonaws.com (79.125.0.135) 0.684 ms ec2-79-125-0-133.eu-west-1.compute.amazonaws.com (79.125.0.133) 0.470 ms 0.453 ms
5 178.236.0.232 (178.236.0.232) 0.816 ms 178.236.0.124 (178.236.0.124) 1.403 ms 1.134 ms
6 178.236.0.124 (178.236.0.124) 1.117 ms 1.127 ms 178.236.0.131 (178.236.0.131) 1.229 ms
7 inex.woodynet.net (193.242.111.60) 2.421 ms 178.236.0.131 (178.236.0.131) 1.158 ms inex.woodynet.net (193.242.111.60) 2.602 ms
8 inex.woodynet.net (193.242.111.60) 2.343 ms 3.063 ms 2.784 ms
9 l.root-servers.net (199.7.83.42) 1.906 ms 1.865 ms 1.615 ms

В общем, больше серверов, хороших и разных.