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

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

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

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

Ещё немного веб-технологий. Как известно, dxdt.ru работает на WordPress (WP). Ещё лучше известно, что связка Apache+PHP+MySQL+WordPress – это монструозный источник нагрузки для сервера. Надо сказать, что так как большого трафика на dxdt.ru нет, то я никогда не тратил время на “повышение нагрузочной способности” этого конкретного веб-сайта. Но тут таки на досуге попробовал установить нахваливаемый многими плагин для WP – W3 Total Cache (W3TC). Оказалось, что, да, нахваливают обоснованно.

В случае с dxdt.ru, означенный плагин исправил ситуацию самым кардинальным образом. До установки плагина, тестирование (в терминологии blitz.io) двумя сотнями одновременных пользовательских коннектов приводило к тому, что сервер капитально ложился через несколько секунд (причину я не расследовал, но, похоже, что множество набежавших Apache+MySQL съедало всю доступную память). После установки и настройки этого самого W3TC – работоспособность, при тех же условиях, сохраняется, хотя часть “пользователей” (~8%) теряется. Неплохо, на мой вкус. Думаю, что соответствующий трафик – примерно 5 млн хитов в сутки – dxdt.ru не грозит. Да и “длительное” время ответа (~500 ms) не должно беспокоить.

Пояснение (03.04.12):

Насчёт времени ответа: всё просто, речь же шла о тесте из штатовского дата-центра, а dxdt.ru размещается в Ирландии, поэтому время ответа такое “большое”, пакетам требуется дважды пересечь океан. Сам сервер генерирует страницы примерно за 30-60 ms.

Дополнение:

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

Дополнение-2 (01.04.12):

Посмотрел на причину падений без плагина. Всё так и есть: без плагина W3TC, благодаря особенностям работы mod_php, Apache поднимает отдельный “тред” MySQL для каждого http-коннекта (то есть, для ста пользователей – сто “тредов”); с плагином – “тред” был замечен ровно один, вне зависимости от числа коннектов. Поэтому и не падает.

(На правах технократического юмора.) Если вы хотите версию того, как можно вызвать аварию всех 13 корневых серверов глобальной DNS, то вот такой вариант: взломан скрытый сервер VeriSign, с которого раздаётся зона на эти самые корневые сервера. В результате, 31 марта, хакеры распространят испорченную корневую зону. DNS сломается. Не требуется даже генерировать подписи DNSSEC, ведь задача состоит не в том, чтобы подменить адресацию, а в том, чтобы всё сломать.

В ноябре прошлого года при обходе зоны .ru (для доменов вида [www.]domain.tld в DNS искалась А-запись) удалось получить адреса для 2762616 имён. По состоянию на 27.03.2012 – таких имён удалось найти уже 2993620. Прирост – 231004 домена.

По IP-адресам: уникальных IP – 204275. Прирост (относительно 09.11.11) – 16944 адреса. Поделим приросты: 231004/16944 ~13.6 домена на один IP-адрес. Впрочем, это такой очень размытый показатель. Для всей зоны тот же показатель составляет ~14.6 домена на IP-адрес.

Обнаружилось 246624 домена (~8.2%) для которых указано более одной А-записи. Нашлось 14 IP-адресов, на каждый из которых указывает более 10000 доменов .ru. Рекорд, как обычно, за доменной парковкой Sedo – 141407 доменов указывают на один IP, относящийся к этому сервису.

Итак, сайт переехал. Можно использовать комментарии. Если обнаружите какие-то неработающие штуки – сообщайте, пожалуйста, будем исправлять.

(Кстати, логи опять подтверждают, что далеко не везде доверяют TTL из DNS: скажем, YandexBot продолжает приходить и на старый адрес, и на новый.)

В ближайшие несколько часов я возьму в руки пару консолей и попробую перенести dxdt.ru на другой сервер. Поэтому, до сообщения о том, что переезд закончен, лучше не писать сюда комментариев: могут остаться в базе на старом сервере, так как в момент переезда некоторое время будут работать параллельно оба сайта, и на какой вы попадёте – это только DNS знает.

Наверное, помните очередную “сенсацию” в СМИ про “неизвестный язык программирования”, следы которого, как заявляли со ссылкой на “Касперских”, были обнаружены в коде трояна Duqu? Так вот тот мегазагадочный “неизвестный” суперязык программирования оказался, по сообщению всё той же лаборатории, языком C. Во как ловко. Процитирую BugTraq.ru:

Из неопознанности языка делались глубокие выводы о высокой квалификации разработчиков (на чем аналитики ЛК продолжают настаивать и сейчас – мол, выбрать такое экзотическое средство разработки по нынешним объектно-ориентированным временам могли лишь самые хардкорные олдфаги, которые с трудом пересели с ассемблера на C, ну и потом предпочли не связываться с C++, а сымитировать тот же функционал макросами).

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

Статистика: встретилось 533 клиентских устройства WiFi. Обратите внимание: это не точки доступа, которых повстречалось более 1500 штук, а разные планшеты, смартфоны, ноутбуки и тому подобные штуки. Всё это время автомобиль находился на разных городских улицах, не во дворах, то есть, разумно предположить, что большая часть – мобильные устройства. (И это не метро! Там плотность устройств была бы выше, это очевидно.) Из 533 устройств 363 (~68%) не были, в момент обнаружения, привязаны к точке доступа. То есть, это неплохо подтверждает гипотезу о преобладании мобильных устройств в полученной выборке.

Так вот, 130 устройств передавали в эфир список идентификаторов точек доступа, к которым они ранее подключались. Я писал об этой особенности реализации WiFi раньше. 130 штук – это около 24%, примерно четверть. Немало, да.

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

(Да, заблокировать передачу всякого подобного “мусора” в эфир можно, отключив использование WiFi, других универсальных способов я не знаю.)

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

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

Скопирую свой комментарий сюда:

Вообще, занятно представить, как могли бы быть построены системы защиты для подобного канала связи. И как можно перехватить сообщение. То есть, скажем, понятно, что огонь факелов видно всем. Направление атаки: можно использовать собственные часы для измерения “длительности” того или иного сообщения, и таким образом восстановить шкалу. Шкала, сама по себе, уже даёт ценную информацию: можно определить повторы одних и тех же сообщений. Другой вопрос: как сопоставить содержание сообщений с метками шкалы? Можно самостоятельно передавать повторы записанных сообщений и смотреть, что там делает принимающая сторона. В современной криптологии это называется “криптографический оракул”.

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

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

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

“Яндекс” в своём репертуаре. Сравниваем результаты поиска по запросу “DNSSEC пример”, в Google на первом месте ссылка на nox.su, потом подробная статья на “Хабрахабре”, ссылающаяся на nox.su, и т.д., добротно, в общем:

Теперь “Яндекс” – тут nox.su вообще нет в выдаче, наверху статья с “Хабрахабра” и другие тематические страницы, которые ссылаются на nox.su:

Впрочем, надеюсь, что поправят в “Яндексе” выдачу, несмотря на то, что для подобных запросов этот поисковик вряд ли используют.

Оказывается, “сверхсветовые” нейтрино детектировали ещё и используя другое оборудование, независимое от OPERA. Выводы вот такие:

Таким образом, ICARUS прямо опровергает данные OPERA и подтверждает ожидания теории относительности.

(По ссылке – заметка Игоря Иванова с подробностями, опять рекомендую.)