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

В ICANN наподавали немало заявок на разнообразные новые домены. Сегодня опубликован список.

Update: сервис, описанный в этой заметке, более не доступен.

Сделал вот сервис dns.dxdt.ru – позволяет искать сведения об адресации, связанные с DNS. Бета-версия. За веб-интерфейсом скрывается база данных из примерно 13 млн документов, которые были получены при помощи опроса доменных зон .ru, .su, кириллической .рф.

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

Как работает dns.dxdt.ru? Интересно было попробовать современные решения. Поэтому в качестве СУБД выбрана MongoDB – это NoSQL СУБД. Сам сервис использует два сервера минимальной конфигурации из амазоновского EC2: на одном работает MongoDB, это, так сказать, “бекэнд”, на втором – связка Apache, PHP, Memcached, это, стало быть, “фронтэнд”. Была идея использовать на “фронтэнде” Ruby, но данный язык, вполне ожидаемо, оказался чудовищно медленным. Отказался. Memcached кэширует не ответы БД, а форматированные результаты выдачи (то есть, итоговые HTML-страницы), что сильно ускоряет работу на повторяющихся запросах. При этом, впрочем, остаётся проблема с доставкой клиенту больших по объёму страниц: некоторые запросы генерируют десятки и сотни тысяч строк в ответе (таковы, например, запросы об ns-ах крупных регистраторов доменов).

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

На следующем шаге планирую добавить в dns.dxdt.ru вывод некоторой статистики, обработку MX-ов. Наверное, что-то ещё. Сервис довольно специфический, но всё равно: вопросы, предложения, пожелания – всячески приветствуются в комментариях.

В 2012 году на roem.ru сообщают: “MD5 больше не надёжен”.

Вообще, о том, что MD5 не является стойким вариантом для преобразования паролей с целью их сохранения, стало известно примерно через пару лет после разработки MD5 (1991). Но, спустя ещё, примерно, два десятка лет – “ненадёжность” MD5 остаётся открытием. В принципе, это объясняет и то, почему разработчики продолжают MD5 применять везде, где только могут.

Очередной День IPv6 отмечают сегодня, 6 июня. Про новый протокол, малодоступный для рядового пользователя Интернета, я писал раньше, поделюсь некоторыми ссылками:

• “Перечислимость” IP-адресов;
• Техническое: практика IPv6;
• Воскресный юмор: как исчерпать адресное пространство IPv6.

Чуть больше года работает тестовый сервер IPv6/IPv4: ipv6.nic.ru, поднятый к прошлому всемирному “переходу” на новый протокол; статистика там накоплена не очень большая, так как, понятно, посещаемость оставляет желать лучшего, но всё равно видно, что IPv6 – пока не популярен.

Вот ещё один штрих: Microsoft распространила сообщение, подтверждающее, что из-под их УЦ выпустили “левые” сертификаты, удостоверявшие, в том числе, вредоносный код. Уязвимы все поддерживаемые версии Windows. Вот вам и доверенный канал для обновлений ОС.

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

В TechNet подробности. Собственно, пишут, что Flame как раз был подписан по этой схеме.

Много шума вокруг обнаружения “бэкдоров” (аппаратных закладок) в микросхемах Actel. Закладки делают возможным прямой доступ к секретной информации, находящейся внутри устройств, использующих ряд FPGA. Авторы исследования, позволившего вскрыть сей аппаратный “дефект”: Sergei Skorobogatov и Christopher Woods. Некоторые СМИ уже сообщают, что это китайское производство виновато – будто там закладки добавили в разработанные в Штатах микросхемы. При этом авторы исходной работы утверждают, что ничего подобного: “бэкдоры” встроила компания-разработчик, штатовская Actel.

Нет сомнений, что история с этой работой будет занятная.

(Неожиданная записка про бытовую технику.) А вот, на картинке, микроволновая печь Raytheon RadaRange – буквально из ретро-футуристических альтернативных историй. Производили в 50-х годах прошлого века. Первые серийные микроволновые печи, правда, появились раньше. Все были большими. RadaRange c фотографий (встречены в “Википедии”) была установлена на атомоходе “Саванна” – пассажирском судне, построенном в США в конце 50-х.

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

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

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

Корабль SpaceX Dragon пристыковался к МКС. Это, в общем-то, первый такой случай в истории, потому что Dragon позиционируется как не государственный проект космического транспорта. Это такая приватизация функций по доставке грузов на орбиту, проводимая NASA.

Сегодня ICANN опять открыла многострадальную систему приёма заявок на новые домены верхнего уровня. Сломанную систему остановили ещё 12 апреля. Говорят, что в программном обеспечении ошибка была изначально. С 12 апреля ICANN, с завидной регулярностью, выпускала разные бюрократические уведомления, рассказывающие о статусе “починки”, которая продолжалась “неопределённое” время. Вроде, теперь закончили работы и обещают почти девять суток принимать заявки – это дополнительный период. Посмотрим, что случится дальше.

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

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

Как разработчики простых твиттерных помехопостановщиков могли бы их улучшить? Во-первых, конечно, нужно устроить автоматы таким образом, чтобы они быстро и автономно обнаруживали переход подавляемого канала на другую частоту, то есть, на другой хеш-тег. Для реализации не нужно распознавать смысловое содержание сообщений. Достаточным признаком может служить быстро возросшее количество сообщений с не встречавшимся ранее тегом для некоторого ядра пользователей. Понятно, что новый тег вводит кто-то из тех, кто активно и в первых рядах использовал предыдущие теги. Эта особенность позволяет выявить “ведущих” пользователей. Соответствующие таблицы в базе данных не займут много места.

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

Возможно, всё это уже реализовано. Ну и, очевидно, если хорошо вести статистику наблюдаемого твиттер-эфира, то появляются другие, не менее интересные пути развития “глушилок”.