Ничего не изменится. Раньше был бёрст, который их клиенты получали всегда, т.к. сервера не оверселленные, или оверселленные, но не на 100% (извините, клиент имея бёрст, не переходит на высший тариф, пока не выжрет бёрст). Т.е. не изменилось ничего.
Не учитывается простой от одной эякуляции до другой, так что информация не может быть точной. Посчитайте, если в сутки кончить 11 раз, то сколько будет полноценных сперматозоидов в эякуляте. И сколько восстанавливаться до нормального объёма.
Это то же самое, что передача данных по голубиной почте. Если выпустить стаю голубей-тяжеловозов и поставить по 2 человека на снятие инфы с каждого голубя, то скорость набегает приличная. Но, чтобы выйти на среднюю скорость равную пиковой, нужно голубей возить самолётами в обе стороны и ставить конвейер для обработки информации.
К ому же яйцеклетка НЕ выдерживает DDoS атаку, т.к. ЕДИНСТВЕННЫЙ = ПЕРВЫЙ ЖЕ пакет отправляет всю систему в аут на 9 месяцев. Это и есть пример неправильной политики безопасности.---------- Добавлено 21.02.2012 в 14:18 ----------
Между прочим, для того, чтобы положить большинство крупных порталов, достаточно 1к ботов.
Сергей Владимирович, Там виртуальный хостинг. Столько денег у ТС просто быть не может, чтобы разобраться попытались.
Я видел этот домен и всё там хорошо, кроме записи SOA. Т.е. закеширован мог быть только негативный ответ. Не могу представить иной ситуации. Причём ТС менял DNS. Если на корневых серверах запись уже сменилась, а хостинг отдал ему отрицательный ответ - он был закеширован и, как следствие, сайт доступен отовсюду, откуда к нему не обращались когда его небыло на DNS хостера. Хостер отдаёт REFUSED, не разрешая рекурсивные запросы, поэтому зона обновляется по SOA EXPIRE. В любом другом случае сработал бы TTL. Другой ситуации я представить так и не могу (Я ознакомился со всеми RFC на этот счет).
Я опираюсь на rfc2308
SOA EXPIRE tells servers how long to wait before dumping their cached DNS info, in the case the they can't refresh. This has nothing to do with making DNS changes, and doesn't affect how long changes take to propagate.---------- Добавлено 19.02.2012 в 23:22 ----------Вообще говоря, данное жесткое ограничение (наличие 0 в поле ttl) было снято в 1997 году (RFC 2181). Связано это было с тем, что реально требование наличия нуля в поле ttl записи SOA нигде не использовалось и не проверялось. С тех пор записи SOA могут содержать значения в поле ttl.
Поле ttl в записи SOA всегда пустое. Дело в том, что время кэширования для записей описания зоны задается либо последним аргументом данных записи SOA (версии BIND до 8.2.), либо директивой управления $TTL. Запрет на кэширование SOA определен в RFC 1035.---------- Добавлено 20.02.2012 в 00:31 ----------Т.е. я ещё разверну мысль, так как выше не корректно выразился. Негативный ответ тоже может быть закеширован и, насколько мне помнится, кеширован может быть как раз по экспайру, так как TTL в этом случае может быть не отдан вообще.
Так и на платном своровать могут за 1-2 у.е.
p1uton, Кешируется.
hvosting, Сорри, не увидел апдейта.
Некоторые на бесплатные хостинги свои скрипты заливают... А что, тоже вариант.
Я о ДНС-серверах интернет-провайдера. А не о хостеровских. Там бывает плевать на ttl и прочие прелести (в т.ч. и полное игнорирование rfc на этот счет бывает.
