Не очень понятно зачем именно домен.
есть плагин плагин для firefox - SwitchHosts. По сути "редактирует" файл host, сбрасывает кеш и внутри ОС и внутри firefox. В одно нажатие позволяет переключаться между тестовой и основной версиями сайта не изменяя URL. ---------- Добавлено 02.09.2012 в 02:58 ----------
ну так я же уже сказал - сейчас это двое суток. А подробнее нужно изучить механизм работы DNS и как работать с программой-клиентом DNS типа nslookup.exe.
Если попасть в удачный момент времени, можно подать запрос на смену ns, который следом тут же обновится на серверах обслуживающих зону .net. На них нет никакого кеша. Просто все запросы на изменения там собираются в кучу и обновляется периодически. А вот кеш у провайдеров обычно сбросить нельзя.
hostracker, очевидно, специально не кеширует информацию dns, всегда запрашивает сервера обслуживающие зону, чтобы выдавать актуальный ответ. А ваш провайдер кеширует. Если бы вы смогли сбросить кеш и у себя и у провайдера, то тоже открыли бы новый сайт сразу.
Именно так. С помощью dns-клиента, такого как nslookup.exe, можно узнать какой именно TTL отдают сервера зоны. запрашиваем один из серверов обслуживающих зону .net и получаем :
dig zaycev.net -t ns @a.gtld-servers.net. .. zaycev.net. 172800 IN NS ns81.worldnic.com.
172800 - это двое суток. Все остальные сервера отвечают точно так же. В зоне ru ttl четверо суток. В org - одни сутки. Соответственно получается, что практически нет такой зоны для сайта, в которой можно было бы быстро менять NS. Дополнительную задержку дает сам процесс обработки смены записи у регистратора и на серверах поддерживающих зону - это, допустим, еще пара часов.
Но для быстрого переноса сайта NS-сервера можно поменять заранее, создав нужные записи указывающие на старый хостинг на новом месте. TTL должен быть указан небольшой и тут на TTL можно повлиять, в отличие от TTL в зонах .net или .org . Потом меняете записи и за время не большее TTL сайт начинает открываться на новом хостинге.
Не каждый провайдер хочет с этим возиться, поэтому все предлагают просто указывать новые ns-сервера.
класс нужно знать только сегодня и то не всем - тем кто первый раз в школу пошел.
ТС почему бы вам понятно не описать, что именно вы вкладываете в понятие определение домена РФ ?
Если код на php, который определяет какой из множества прикрепленных доменов загружается, то нужно просто понимание механизмов работы этих самых доменов.
В данном случае достаточно понимать, что домен .рф закодирован особым образом и в переменной $_SERVER не будет содержатся строка '.рф', а будут закодированная строка, которая соответствует вашему домену. То же самое и в .htaccess.
webinator, почта домена обрабатывается в гугле, значит тоже маловероятно.
webinator, во-первых, маловероятно чтобы почта гугла взяла и заглохла.
Во-вторых, все опять зависит от конкретики :
при сбое, который проявляется как отсутствие связи с сервером, почта должна придти позже, потому что все почтовые сервера обязаны хранить и предпринимать повторные попытки доставки писем.
Если сбой в виде неправильной настройки сервера и сервер рапортует что "такого ящика тут нет", другие сервера не будут ждать и удалят письмо.
Единственное, что тут ясно - есть подозрения на то, что информация каким-то образом оказывается у третьих лиц.
Высказывания неспециалистов да еще и переданные своими словами другим неспециалистом, следует понимать именно так.
Поэтому возможных сценариев бесконечное число и я предлагаю просто определить границу между разумными мерами и паранойей.
Если уж так хочется конкретики : да, возможна расшифровка и модификация любой информации переданной внутри ssl, если клиентское ПО заранее модифицировано и туда внесены поддельные сертификаты. Например, Forefront TMG Server таким образом инспектирует https.
C ADSL тоже проблема решаемая.
неправильно понимаете, можно и предложить, но ТС этого не поймет, а ради ваc не хочется.
Так они этого не знают. Думаю, начальник будет вполне удовлетворен ссылочкой и заверением, что все сделано как там написано.
Dns, почта и веб - три разных сервиса. От работоспособности dns зависит работа почты и веба.
Зависит от того как именно заглох.
В общем, если вы озабочены надежностью почты и прогнозируете проблемы у хостера, лучше dns держать не у хостера, а на специальных хостингах dns - типа pdd.yandex.ru, dyndns.org и тд. благо стоимость этой услуги копеечная.
а подробней в статье 272 УК РФ - неправомерный доступ к компьютерной информации.
там ограничено время хранения этих логов. или, может, число записей. не так уж важно.
а про наличие или отсутствие фильтров в исходном сообщении не упомянуто. только про логи.
о содержании страницы.
Вообще, можно считать, что эта ссылка как раз устанавливает с точки зрения google границу между разумными мерами безопасности для типичного домашнего пользователя и паранойей, которой можно увлекаться бесконечно. Вот и пользуйтесь этой границей, если затрудняетесь оценить риски самостоятельно.
Имея фантазию можно придумывать массу сценариев когда та или иная мера ограничения доступа не сработает. Включая "технически невозможные".
Например, можно зайти в ящик 3 еще года назад и настроить копирование в другой ящик. Все - никаких следов. Старые данные затрутся со временем.
Некоторые вещи, которые следует проверить в первую очередь google сами предлагают http://www.google.com/goodtoknow/online-safety/mail-accounts/
И даже на этой странице от гугла нет заявлений о том, что получение вашей почты технически невозможно. Это просто советы.
