собственно у кого-нить есть инфа с хуиза никовского на утро домена делегированного? у самого ник.ру статус изменился не так давно на делегирован только.
мне кажется это цифра оооочень занижена. Все домены что я регистрировал в ru и su, а это порядка полутора сотни домено все были в not delegated, все домены, что я смог по памяти проверить аналогично.
Делегирование, это образно говоря галочка "Вкл" для домена. Поэтому когда "Выкл" ДНС сервера видят, то ошибку и возвращают, что домен недоступен. Бывает еще когда ДНС не видит галочку Вкл или Выкл для домена, это значит что домена вообще не существует :)
31.01.08 произошел сбой в работе системы регистрации RU-CENTER, что привело к следующим последствиям:
в системе регистрации RU-CENTER была изменена информация о DNS-серверах части доменов. На DNS-серверах зоны RU было снято делегирование у 6078 доменов, находящихся на сопровождении RU-CENTER. Время неработоспособности с 2 часов ночи до 10 часов утра по московскому времени.
В 10 часов 31.01.08 в Техническом Центре домена RU делегирование всех доменов было восстановлено по состоянию на 19 часов 30.01.08. Информация в системе регистрации RU-CENTER и в Реестре домена RU будет восстановлена сегодня, ориентировочно к 14 часам.
Приносим свои извинения нашим клиентам и партнерам.
Re>слава богу не текущий момент (11:01) восстанавливается все потихоньку
на сейчас пока только nic.ru в deletated стал :) на http://developers.1nsk.ru/blog/post10945… я скрины делал, собственно база WHOIS.NIC.RU отдает not delegated, а с базы WHOIS.RIPN.NET все норм
:) это было лукавство, в смысле они-же делали конкурс зарегь миллионный домен и получи чето-там, когда это был миллионный вообще .ру домен, а так на сегодня конечно это порядка 700тыр, http://stat.nic.ru/2008/01/31/registrar-…
Я тоже считал, что все это сложно, но буквально на днях имел удовольствие общаться с представителем УФСБ по Новосибирской области ( тут чуток выложил http://developers.1nsk.ru/blog/post10539… ), там вполне рады обращениям о подобных делах. А про доказывать :) они тупо берут, смотрят кто вам угрожал где-нить на форумах в том числе и начинают прорабатывать все версии... если там демон зла какой все делает, то возможно и сложно пойдет, но очень часто за всем стоят малолетние за#$оты.
Немного неверно, сама атака попадает под Статья 274 Нарушение правил эксплуатации ЭВМ, системы ЭВМ или их сети.
1. Нарушение правил эксплуатации ЭВМ, системы ЭВМ или их сети лицом, имеющим доступ к ЭВМ, системе ЭВМ или их сети, повлекшее уничтожение, блокирование или модификацию охраняемой законом информации ЭВМ, если это деяние причинило существенный вред, -
наказывается лишением права занимать определенные должности или заниматься определенной деятельностью на срок до пяти лет, либо обязательными работами на срок от ста восьмидесяти до двухсот сорока часов, либо ограничением свободы на срок до двух лет.
А по поводу реализации, я думал что надо чтобы файлы были по возможности находились в обоих ДЦ.
Именно такое требования основное, т.к. тарифные игры провайдеров требуют чтобы абонент получал весь трафик с определенного сервера, не "смешивая". Собственно порядок по объему данных ~гигабайт в сутки (фотки, ролики, файлы до 100Мб каждый), ftp или sftp рассматривал, но как-то scp привычнее :) т.к. шел scponly поднял и голову не грей за права :)
В виду хитрых провайдеровых войн гонять трафик постоянно некошерно. Поэтому в виду не сильно большой интенсивности генерации файлов (несколько тысяч картинок, роликов etc.) тестирую сейчас следующую схему, есть БД которая хранит в себе тип (файл, директория), событие (добавлен, обновлен, удален), путь до файла, сервер на котором произошло событие. Соответственно на площадках эта копия базы имеется, раз в X минут запускается скрипт который готовит задание для scp или чистильщика и отрабатывает.
Резервирование всего через снапшоты LVM и последующий бэкап их. Вируализация через VServer, имхо после тестов ксена, и виртуозы больше нравится, тем более за пару лет ни разу не подводила схема вируализации, а xen чето себя странно под нагрузкой вел :)
Сейчас разрабатываю для своего проекта подобную схему, разносим проект по двум ДЦ:
bind в зависимости от провайдеров выдает ту или иную ip, на площадках сервера с nginx+apache, про мускул еще не решили, либо мастер-мастер репликация, либо мастер-слейв и на одной из площадок класс работы с БД будет все что не SELECT делать на мастер.
Пока узкое место системы mysql (дать возможность проекту работать в случае геморойной связи между ДЦ) и что делать с файлами заливаемыми пользователями в плане их синхронизации на сервера...
я правильно понял что предыдущий спитч по поводу сдвига окна? если да, то подумаем как зафиксить, а какие еще мысли возникают по усовершенствованию сервиса, интересно было бы выслушать мнения\предложения, т.к. повторюсь аналогов просто не нашли.
http://nic.ru/news/2008/31.01.tech.html
31.01.08 произошел сбой в работе системы регистрации RU-CENTER, что привело к следующим последствиям:
в системе регистрации RU-CENTER была изменена информация о DNS-серверах части доменов. На DNS-серверах зоны RU было снято делегирование у 6078 доменов, находящихся на сопровождении RU-CENTER. Время неработоспособности с 2 часов ночи до 10 часов утра по московскому времени.
В 10 часов 31.01.08 в Техническом Центре домена RU делегирование всех доменов было восстановлено по состоянию на 19 часов 30.01.08. Информация в системе регистрации RU-CENTER и в Реестре домена RU будет восстановлена сегодня, ориентировочно к 14 часам.
Приносим свои извинения нашим клиентам и партнерам.
на сейчас пока только nic.ru в deletated стал :) на http://developers.1nsk.ru/blog/post10945… я скрины делал, собственно база WHOIS.NIC.RU отдает not delegated, а с базы WHOIS.RIPN.NET все норм
1. Нарушение правил эксплуатации ЭВМ, системы ЭВМ или их сети лицом, имеющим доступ к ЭВМ, системе ЭВМ или их сети, повлекшее уничтожение, блокирование или модификацию охраняемой законом информации ЭВМ, если это деяние причинило существенный вред, -
наказывается лишением права занимать определенные должности или заниматься определенной деятельностью на срок до пяти лет, либо обязательными работами на срок от ста восьмидесяти до двухсот сорока часов, либо ограничением свободы на срок до двух лет.
Именно такое требования основное, т.к. тарифные игры провайдеров требуют чтобы абонент получал весь трафик с определенного сервера, не "смешивая". Собственно порядок по объему данных ~гигабайт в сутки (фотки, ролики, файлы до 100Мб каждый), ftp или sftp рассматривал, но как-то scp привычнее :) т.к. шел scponly поднял и голову не грей за права :)
Резервирование всего через снапшоты LVM и последующий бэкап их. Вируализация через VServer, имхо после тестов ксена, и виртуозы больше нравится, тем более за пару лет ни разу не подводила схема вируализации, а xen чето себя странно под нагрузкой вел :)
bind в зависимости от провайдеров выдает ту или иную ip, на площадках сервера с nginx+apache, про мускул еще не решили, либо мастер-мастер репликация, либо мастер-слейв и на одной из площадок класс работы с БД будет все что не SELECT делать на мастер.
Пока узкое место системы mysql (дать возможность проекту работать в случае геморойной связи между ДЦ) и что делать с файлами заливаемыми пользователями в плане их синхронизации на сервера...
Сильно бесит? Имхо вроде нормально.
Re>Кстати, подумайте над идеей открытия всплывающих слоев справа от ссылки, а то как-то по-ближневосточному получается :)
:) почему-то не думали в таком контексте