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

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-ов. Наверное, что-то ещё. Сервис довольно специфический, но всё равно: вопросы, предложения, пожелания – всячески приветствуются в комментариях.

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

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

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

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

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

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

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

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

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

Как я уже упоминал, для нового выпуска “Доменных имён“, посвящённого истории Интернета, мы с Артемием Ломовым написали статью “Сценарии конца Интернета“. Сейчас статья доступна на сайте журнала, в PDF, рекомендую. Небольшая цитата:

Некоторые умные люди небезосновательно утверждают, что вероятность любого события тождественно равна нулю до его наступления и тождественно равна единице – после. Например, почти ровно 100 лет тому назад, в первой половине апреля 1912-го, вероятность гибели «Титаника» как раз оценивалась всеми здравомыслящими людьми как нулевая. Любое пророчество о том, что первый же рейс станет последним для непотопляемого лайнера, не могло быть воспринято иначе, чем инфернальный бред. Однако все мы хорошо знаем, что случилось дальше.

Спустя считаные минуты после того, как вероятность катастрофы стала в точности равной единице, носовая часть расколовшегося надвое «Титаника» врезалась в океанское дно со скоростью порядка 13 миль в час, зарывшись в осадочные породы. И человечество, надо сказать, еще легко отделалось – к счастью, в данной точке пространства-времени не оказалось проложенного по дну трансатлантического кабеля магистральной сети связи с пропускной способностью в несколько сотен гигабит в секунду.

Да, текст, местами, художественный, но некоторые из упомянутых в статье сценариев уже просматриваются в реальности. Итак, вот, ещё раз, ссылка на PDF.

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

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

А с другой стороны, интереснее такая интерпретация: разработанная по заказу ICANN система настолько некачественная, что восстановление после сбоя уже заняло больше двух недель. Это как же нужно было спроектировать программное обеспечение, чтобы достичь такого эффекта? При этом в корпорации, контролирующей распределение адресного пространства всего Интернета, управление проектами налажено так “замечательно”, что ICANN даже не может уверенно прогнозировать время восстановления после сбоя. В общем, абсурд там какой-то с этими New gTLD, по всем фронтам.

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

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

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

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